Threads, games and running on all CPU's

General Discussions
#61

:emo:

You’ve kind of side-stepped the point there - that graphics object is not, never was and never will be accelerated! It would break the BufferedImage API. That offscreen image needs to be a VolatileImage if you want to speed up rendering to it.

And if you’re drawing into a BufferedImage every frame, then it’s never going to be promoted to a managed image either because you’re constantly invalidating any cached copy.

#62

I know… :stuck_out_tongue_winking_eye: I probably could have added a paragraph break in there somewhere. I’m advocating going all in with the VolatileImage API as it’s not too hard to support it and be absolutely certain things are accelerated.

@mike_bike_kite
When you move over to the VolatileImage API just implement the loading first as found in the tutorial (Code Example 5 / loadFromFile) and when making the OffscreenImage use createVolatileImage instead. Once you verify that things are working then figure out a way to do any stale image verification in your render loop.

For classpath stuff…

Try this…
javac -cp “.;tinysound-1.1.1.jar” neptune.java
jar -cfm neptune.jar Manifest.txt *.class *.png *.wav

java -cp “.;tinysound-1.1.1.jar” -jar neptune.jar
or
java -cp “.;neptune.jar;tinysound-1.1.1.jar” neptune

BTW as Cas and nSigma mentioned you don’t need “-Dsun.java2d.noddraw=true”. It actually crashes / prevents your game for running on my Windows box. I just get a white screen with this error:

Exception in thread “main” java.lang.InternalError: Could not set display mode
at sun.awt.Win32GraphicsDevice.configDisplayMode(Native Method)
at sun.awt.Win32GraphicsDevice.setDisplayMode(Unknown Source)
at test.main(test.java:418)

So something might be particularly wrong with your dev box.

#63

This has all been very helpful to me. Things I’ve learnt so far have been:

  • Do not create anything in the draw routines ie (new Color, new int[10] etc).
  • Fewer calls to draw routines the better - a single fillPolygon is much better than multiple smaller polygons.
  • Get as much processing out the draw loops as possible - the single call above meant I could build the polygon array elsewhere.
  • The standard java sound is useless for gaming. I quite liked TinySound when I tried it.

The end result is my game now runs smoothly on my cheap chromebook (converted to Linux) using only 25% CPU which is better than I expected. The threads I now need for the game are just the main game thread and one to handle IO from the web for high scores etc. I currently don’t need to speed the game up any more but I will look into using BufferedImages or VolatileImages. A few small questions remain though:

How do I change the volume or pan left to right with TinySound?

I currently call pain in my main run loop and record FPS as well as number of moves (of creatures/sea etc) per second (MPS). I limit the MPS to 30 to make the game playable but obviously with
my set up I also get 30 FPS as well. It’s not an issue for me but I was curious how you limit the number of moves but allow the FPS to climb on faster machines?

So far there seems to be lots of ways of calling the program to get it to work. I need the nodraw option otherwise I’m met with a blank screen but others don’t. If the user is on Linux then the java commands need to have a colons rather than semi colons in the path. Should I include a bat file (or many files) to run on Windows and a sh file to run on Linux?

I looked into JavaFX and some of it’s features are neat but perhaps a little complex (30 lines to say hello world!!) but I’ll try to persevere. It’s big advantage to me though is being able to produce an executable so I’ll continue to look into this.

I’ve uploaded the latest version to the web page now.

Mike

PS Has anybody actually played the game?