Chapter 24 ■ Optimizing game assets and COde, and game prOfiling Using netBeansMemory usage at 60MB is also pretty good, considering that this includes image data, CD-quality audio
effects, and JavaFX Animation (Transition) classes, as well as AudioClip, Images, StackPane, Buttons, 3D
Primitives, Text, (SceneGraph) Node, and utility (Inset, Color, Pos, etc.) usage, and all of these utilize these
JavaFX classes that we have used to build this i3D professional-level Java 9 game.
Very little of this memory overhead can be directly attributed to the 1,700 lines of Java code that you
wrote to put this game together; 99 percent of this memory use can be attributed to loading new media
assets and to many JavaFX 9 classes, which access and run these new media assets.
As you can see in Figure 24-23, once you are finished profiling your Java 9 game, you will get an
Information dialog that says “The profiled application has finished execution.” Click OK to terminate the
VM, and you’ll get a summary square (in black) showing the allocated memory heap size (71MB) and the
total amount of memory used (66MB) to run the profiling session. If you think 66MB is a lot of memory,
consider that this machine has 4,096MB of memory and that 66MB represents 1.6 percent of this memory.
Many modern smartphones, iTV sets, tablets, and laptops have 8GB of system memory, so this entire game
ecosystem and infrastructure would represent less than 1 percent of system resources. On a 2GB smartphone
or (ancient) computer system, this would represent around 3 percent of system resources. This is pretty good
for an animated, interactive 3D board game, so Java is doing a darned good job!
Figure 24-23. Once you are finished profiling, NetBeans will give you a memory used summary and
Information dialog
Next, let’s take a look at optimizing our Java code, as the code I used to write this book is what I would
term “prototyping” code. It is technically correct but does not (yet) leverage any of the Java coding structures
that might implement advanced Java language syntax or features such as Arrays or Hash Tables. The reason
for this is that I am trying to help new game developers and programmers to “visualize” what the Java game
logic (code) is doing inside of their heads, and the easiest way to do this is to code it visually in a way that
shows what this code is attempting to do.
Note that the Java 9 compile, build, and execute processes will do quite a lot to optimize this code
“under the hood” as well, as the previous section on profiling will show how optimal this Java 9 code is
without being specifically “programmer optimized” in any way. Additionally, there are so many different
ways to do this, from one programmer to the next, that I wanted to focus more on JavaFX game APIs,
game design and development work process, and game asset development than on standard Java code
optimization, which is well covered in hundreds of other Apress books.