Chapter 24 ■ Optimizing game assets and COde, and game prOfiling Using netBeans
The next thing that you will see, as shown in Figure 24-17, is the Output Pane executing your game’s
Java code.
Close the Output Pane to again show the Profiler Telemetry UI. Both the game and the profiler should
now be sharing the screen. Anything you do in the game will be reflected in real time in these NetBeans
Profiler Telemetry panels shown in Figure 24-18. I am annotating each of the next five figures using red Arial
text to clarify which of the five major stages of gameplay I am testing, and you can see from your profiler UI
data what the 3D animations, audio playback, texture map loading (or unloading), event processing, and
Java code processing are taking regarding the CPU processing (percentage) overhead, system memory use
(most of which will be utilized for loading digital images or for holding and playing digital audio, as well
as for holding the JavaFX API classes we are using to do the 3D modeling, 3D texturing, 3D animation, and
audio), garbage collection, thread usage, and (one single game prototyping) class use.
Figure 24-18. The Animation object moving a rotating 3D spinner UI onto the screen uses 0 to 5 percent of the
CPU’s capacity
As you can see in Figure 24-18, moving your i3D spinner UI onto the screen uses only a few percent of
the CPU, for only a second or two, so this seems to be well coded. Clicking the i3D spinner UI once it has
“landed” on the screen, the profiling data for which is shown in Figure 24-19, also looks highly optimized
as far as the CPU usage is concerned. Notice that the population of the landed game board quadrant (five)
square images can be seen in the Garbage Collection pane and Threads and Classes pane. This activity
spikes as your random number is generated, and the five game squares are loaded with the randomly
selected image assets, which are then placed in system memory.