JavaFX 1.2: Charts

Courtesy Scott Adams

JavaFX 1.2 was released quite recently as of this blog post. One of the latest new features to the JavaFX scene-graph are charts!

Despite the humorous commentary in the cartoon, charts really are useful to businesses because they make it easier to visualize and therefore analyse trends in data.

Memory Monitor Program
Here is a demonstration of a program designed to track memory usage:
Here is the source code for the program.

This program calculates memory usage from the java.lang.Runtime class's getMaxMemory(), getTotalMemory(), and getFreeMemory() methods, converting them to Megabytes due to the sheer number of bytes. It then outputs it to the graph:

1. //Load total memory into the chart.
2. insert LineChart.Data {
3. xValue: time
4. yValue: runtime.totalMemory() / 1000000
5. } into memoryChartSeries[0].data;
6. //Load the used memory into the chart.
7. insert LineChart.Data {
8. xValue: time
9. yValue: (runtime.totalMemory() - runtime.freeMemory()) / 1000000
10. } into memoryChartSeries[1].data;

and puts the proportions to the Pie Chart once every ten seconds:

1. pieChart.data[0].value = (runtime.totalMemory() - runtime.freeMemory()) / 1000000;
2. pieChart.data[1].value = runtime.freeMemory() / 1000000;
3. pieChart.data[2].value = (runtime.maxMemory() - runtime.totalMemory()) / 1000000;

Additionally, you can add ImageView objects to see how much memory use increases.

Though the program's layout isn't very pretty, you could theoretically use this program to check for memory leaks. For instance, it's obvious that each time this program updates the pie chart, more and more memory is consumed, which is why I wrote it to refresh only every 10 seconds (it still uses up all memory available to it if you run it long enough). Ah, the irony!

JavaFX 1.2
Overall, JavaFX 1.2 is a great improvement over the previous versions. There are still a few features I would like to see in the future.

For instance, it would be helpful to be able to access media and video through streams. At the present time, they can only be loaded into JavaFX by means of a URL, which decreases flexibility quite a bit. It would be very convenient to be able to store media and images with the Storage class, as these files tend to be too large to efficiently save inside the program's jar file, and the file structure of different operating systems can vary. But alas, the Storage class can only be correctly accessed by streams (a "hack" to work around this limitation would make it system-specific).


It would also be nice if a more advanced collision detection and response system could be added. At the moment, one can detect collisions through a node's bounds. However, these bounds are based upon rectangles, thereby decreasing accuracy as one can infer from the figure to the left.

It is also a bit difficult to replicate the appearance of an old fashioned swing GUI, though that is mainly due to the lack of a visual designer, which thankfully is due to arrive in the near future.

The good news is that this version now includes Linux support, and other features I am eagerly awaiting are due to arrive in the near future.

Starfighter: Part 1

Introduction

I am eventually hoping to start up a commercial website dedicated to entertainment. I have decided to use Java due to its relative platform independence and the fact that I have spent a lot of time on it as a hobby.

Towards this effort, I have been working on a number of games. I am currently focusing on a game I have titled: Starfighter.

When I first tried to write games, I spent plenty of spare time trying to develop a Java based scene graph, or else find an effective open source solution. However, I found both options to be difficult and time consuming.

Which is why I became excited when I first learned about JavaFX, a scripting language dedicated to graphics.

Handicaps

One of the largest handicaps I have had, is JavaFX's current incompatibility with Linux. After finally getting tired of viruses getting past my firewall and ruining my computer, I ended up switching to Linux. My computer has not demonstrated any virus problems since, but this is problematic when programming in JavaFX, because it is officially unavailable for Linux and Solaris. According to this article, it is because of difficulty in implementing graphics acceleration and video.

I have managed to get around this using a popular hack, but I have thus far been unable to get video to work and I have had to develop a large number of typing habits to compensate for the buggy code editor.

Curiously, all of the samples on the JavaFX website seem to work on my computer, even video. The only setback is that they are slower on Linux than they are on a Windows computer (and in one case unmanageably so).

It is rather nice not having to write my own scene graph, but JavaFX still seems to lack a major component for graphics design: Collision Detection.

Collision Detection

Collision detection refers to when a program checks to see if any of the sprites overlap. Then of course, it presumably calls a function to respond to the stimuli appropriately.

I received major headaches when trying to implement this in Java. Fortunately, I have a better idea of what I am doing this time.

The simplest form of collision detection would be rectangle based and use the brute force method. Basically, a rectangle would bound each sprite, with its minimum and maximum x and y points corresponding to those of the sprite. Then, the program would mathematically calculate one sprite against every other sprite to see if any of their rectangles overlap.

The problem with the rectangular bounds method is that the rectangles cannot accurately indicate whether or not various shapes, such as a circle or a line intersects with another object. I will be unable to work around this problem for now.

The problem with the brute force detection method is that for every sprite I add to the scene graph, the amount of collision checks increases exponentially, as every sprite must be checked against every other sprite.

There are two methods I am aware of that can take care of this problem: Quadtrees and Cells.

Both are ways of dividing the space the sprites exist in into sections. That way, each sprite is only matched against sprites in the same section.

Since I do not know very much about Quadtrees, and I am hoping that the JavaFX team will eventually resolve this, I am implementing a variation of the Cell method.