Breaking Out with JavaFX
Sunday, August 24th, 2008
For the first in a series of posts exploring the JavaFX (Script) language, I decided to write a simple clone of the classic game Break-Out. This little play test looks at the following aspects of the language:
- Animation
- The scenegraph (drawing) coexisting with Swing widgets
- Some of the built-in effects (lighting, reflections and so forth)
- Performance
For those not familiar with Break-Out, the object of the game is to hit all of the “bricks” at the top of the screen with the ball by hitting the ball with the paddle at the bottom of the screen. In this version the paddle simply tracks the mouse’s “x” location, so the learning curve is thankfully minimal. To call this a game, of course, would be quite generous; it really just serves as a test bed for trying out the language and some of its effects.
Here’s a screenshot with simple ambient lighting and reflections enabled:
Note the reflections of the paddle and the ball on the “ground”. The reflection of the ball will grow or shrink depending on how far the ball is from the ground. Also shown in this screenshot is a “combo” which is triggered by hitting the next brick in under one second. If a player can pull this feat off, they will be rewarded with text flying at them reporting the number of combos.
Here’s a screenshot of a light attached to the ball, giving neat lighting effects on the bricks as the ball moves around. It’s a really neat effect that is fun to see in action, however the impact is somewhat lost in a static screenshot. There is also motion blur on the ball, but the shot is so dark it’s hard to tell.
For those interested in compiling and running it, or just looking at the source code, it’s available here. As a bit of a warning, there are a number of experiments in the code, so it’s quality and “best practices” are lacking.
In terms of the actually coding, I found the declarative syntax quite natural to use. People are saying that it is “fun” to code in JavaFX Script, and I have to agree with them. There is something very satisfying about the intense order and terseness of the code.
I wrote this in Netbeans (as a JavaFX project), so I had the benefit of many of the IDE niceties including a “real-time” preview which would show me how the application was shaping up as I wrote it. Once I started using animation, however, the preview stopped being correct and useful.
Speaking of animation, this was probably this single biggest gain over straight Java. There was no managing of multiple threads, no manual updating of state — JavaFX hid all of this from me.
Although this may also have been the biggest downfall, as there were a number of cryptic performance issues that crept in once I started implementing the collision detection. I assume that JavaFX was keeping all of my data access thread-safe for me, but since I wasn’t sure where this was happening, or what it was managing for me, tracking down the performance bottleneck was an unfortunate hassle.
I’m still not sure what exactly where the problem was, but I suspect that data tied to binders must carry a higher than average overhead. Once I cached some of the values (the ball position for example), performance improved, which is to say that it went from “completely unusable” to “more usable”.
To that point though, I’m not sure why I had to roll my own (quite poor, I might add) collision detection. It seems that such an animation-heavy language like JavaFX should provide some 2D collision detection for me (like Java2D does).
Also the drawing canvas did not play well with the Swing widgets. I originally had the Swing panel on the bottom, but it would resize the panel to fit the area being drawn, which was not at all what I was going for. I have read that the JFX team is working on moving the Swing components over to the scenegraph “node” model, so hopefully that will clear some of that up.
I also experienced unfortunate performance issues when running via the game from a jar file with lighting enabled. “Unfortunate” meaning that the framerate would drop to an unplayable level. I was planning on deploying a webstart version of this, but the performance of the deployed app was so unplayable that it didn’t seem worth it. Why is running a jfx app through a jar file different than with the “javafx” command? I can’t imagine performance gaffes like the ones I experienced making their way into even a preview release, so I’m willing to concede that my environment and/or coding practices are likely suspect.
So the score sheet so far looks like:
Things that made me happy:
- Declarative syntax with liberal data binding makes for fun programming.
- Effects were easy to plug in and try out (lighting, reflections, motion blur)
- When it was all working, the performance was pretty good.
Things that made me sad:
- Inconsistent (or rather, unexpected) results when combining Swing Components with the scene graph
- No built in collision detection
- The lighting effects were easy to enable, but difficult to do anything useful with (e.i. pointing a light somewhere seems much easier in straight OpenGL).
- Odd performance mismatch between running with “javafx.exe” and out of a jar file.
Tags: JavaFX
2 Responses to “Breaking Out with JavaFX”
Leave a Reply
Recent Posts
Archives
I’m Literate!
'to-read':
Tags
Categories
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
[...] a previous post on JavaFX, we explored some of the 2D animation and drawing features of the language by [...]
[...] Break out Demo (demos dynamic effects) [...]