Nice template. However you'll save a bunch of bytes if you just use the nano timer instead of the rolling average implementation. I think oNyx used the rolling average because Java 1.5 was not allowed at that time.

I'm not sure I understand what you mean. Using nanoTime would give me more exact time, but if one removed the rolling average, the framerate would be more jumpy in either case. The advantage to having a sleep that varies in length, of course, that it'll stay around your desired FPS (in the case of the template, 62), while giving your calculations some freedom (they might not take the same amount of time each frame). Calculating the sleep time based on an average over the last few frames smooths it out.

I believe the rolling average was made to hide the inacuracy of currentTimeMillis. You don't have to do that with nanoTime. As long as you've got cycles to spare you can cap the framerate perfectly. Here is the code to cap the framerate to 60 fps:

I believe the rolling average was made to hide the inacuracy of currentTimeMillis. You don't have to do that with nanoTime. As long as you've got cycles to spare you can cap the framerate perfectly. Here is the code to cap the framerate to 60 fps:

Ye, the old timing code is pure voodoo. It even works reasonable well with a timer resolution of 250msec if the time per frame is pretty consistent (~changes slowly).

>I think oNyx used the rolling average because Java 1.5 was not allowed at that time.

I invented it because nanoTime didn't work on my old machine anymore after I installed an ATI graphics card. It caused a different bus load than the Nvidia card which in turn triggered QPC leaping. I really wish there were some 1msec timer (TGT) in Java. LWJGL for example uses TGT on Windows and currentMillis elsewhere (=1msec - except for Windows, of course).

With 1.5+ I'd use (now that I got a better machine haha) a simple min-cap loop such as the one tom posted. Just with sleep instead of yield. The RADYTT (rolling average damped yield throttling thingy ) only uses yield, because there can be so many of them. If 1% of them take 100 times longer than usual you won't notice it, because it would be averaged out in that gigantic pile of yield calls.

Sleep, however, is a different thing. There are only a few calls. If one takes a tad too long you gotta quit the loop right away, but with imprecise timing you wouldn't know and there is a fixed amount of iterations. So, that wasn't an option.

Would be great if sleeps for longer durations than 0 or 1 msec would be as accurate as calling 0 or 1 msec sleeps in a loop, but even that isn't the case. Otherwise sleeping the full amount in one go would have been a good solution.

edit: What's really bad about RADYTT is that the over-/under-steering effects get pretty big if two instances of it are running at the same time (e.g. having 2 games running which use this timing method).

If you have an image of, let's say a top down view of a car, then you can split that image in HALF, saving 50% of the bytes!

You simply cut it from the top-center and down through the bottom-center, throw away either half. Then you load up your half image and then you can recreate the full image by mirroring the half you kept!

Storing the image + flip would require accessing many different api calls, which will bloat up the constants pool with lots of class & method signatures - something you should always be aware of when trying to keep code size to a minimum.

In an Applet, is it most efficient to start your game loop from the init method, and stop it from the destroy method? I would like to save some bytes and not worry about the destroy method, however, if I do this, the game starts up multiple game loops if the page is refreshed.

Thanks!

There are several ways to make an applet run.How does your Applet look like? Which methods have you written?I never used the destroy method, but Applet needs more overhead than Frame, but maybe I am wrong?

I have overridden the init, destroy, processKeyEvent, and paint, methods. I have also implemented the run method from the Runnable interface. The init method starts my game loop thread. The destroy method sets a boolean flag to tell the run method to stop. It is a _lot_ of overhead, and I am hoping there is a more efficient way?

Mouse buttons states are in low k[]-values, keys in higher. This has some side effects, but it shouldn't be too bad (some obscure keys might act as mouse buttons).

Aren't the static ints x and y rather expensive? I'm doing something similar, but storing everything in one array of ints. Seems to save nearly 100 bytes.Keys go into the array based on keycode. Mouse coords go into [ 0 ] and [ 1 ], and the mouse button state into [ 2 ]. I'm not tracking the other mouse buttons, but that would be easy to add.

I have overridden the init, destroy, processKeyEvent, and paint, methods. I have also implemented the run method from the Runnable interface. The init method starts my game loop thread. The destroy method sets a boolean flag to tell the run method to stop. It is a _lot_ of overhead, and I am hoping there is a more efficient way?

for double-buffering use another Image (eg. J) and paint everythingto J and at the end draw J to I, this should work quite well.maybe you can replace the update-method too, by replacingrepaint() with getGraphics().drawImage(I,0,0,null), if so youdont need I to be global, but I have not tested this...

I think you'll find if the user refreshes the web page, the init method will be called again, kicking off another thread, and the old thread will continue to run.Also, I think you want to override the paint method, not the update method.Finally, you may like to look at using VolatileImages....but I could be wrong.

think you'll find if the user refreshes the web page, the init method will be called again, kicking off another thread, and the old thread will continue to run.Also, I think you want to override the paint method, not the update method.Finally, you may like to look at using VolatileImages....but I could be wrong.

You can override update-method to ensure repaint is only done when you call repaint().paint-method is called more often (when os calls the applet to repaint eg)

The template also says: t.enableEvents(AWTEvent.KEY_EVENT_MASK); However, aren't key events on by default?

I know when I override processKeyEvent(KeyEvent event) I do not have to enable key events. You might still need to enable them if you override processEvent(AWTEvent event) instead. Going with processKeyEvent will also save you the cast from AWTEvent to KeyEvent.

I know when I override processKeyEvent(KeyEvent event) I do not have to enable key events. You might still need to enable them if you override processEvent(AWTEvent event) instead. Going with processKeyEvent will also save you the cast from AWTEvent to KeyEvent.

Hmm, that's interesting - I wonder if that is a quirk of a particular implementation, or is a documented piece of functionality.What is your main Container subclassing? Applet, Frame or JFrame?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org