Is smooth animation in an applet possible?

Java 2D
#1

Please help. This is the first 2D game I have made that needed animation. I was just trying to make a java game that could be played without having to download any additional plugins like j3d or GL4Java. I have tried various things, such as…

System.currentTimeMillis()
->is widely known as innacurate

sun.misc.Perf
->won’t run in an applet due to the security manager

com.sun.j3d.utils.timer.J3DTimer
->I gave up on avoiding additional downloads in my latest attempt, and I thought it would work out just fine, except on my system I am always getting 0 returned from J3DTimer.getValue() and .getResolution().

The J3DTimer problem is not just my stupid little test code either, the TimerTest.java included in the J3DFlythrough does the same thing on my machine. Does this have to be initialized in some strange way?

If you guys have some suggestions and/or examples that you could point me at that do accurate timing in an applet, I would greately appreceate it.

(added June 2nd)
I thought that there might be at least one person with experience in this area, am I wrong? So, I guess I should just try to cap my framerate at a low value using Thread.sleep(), and give up? I hope there is something left that I havn’t tried yet.

#2

If it’s Java 1.1 you’re using, maybe I can help.

First, if your applet has a lot of moving objects, don’t even try to go above a 550x400 res. This is about the bleeding edge for an applet that wants to do large graphics updates and still maintain 20 fps. Of course, smaller always runs faster.

Also, for maximal graphics performance, you’ll need to implement your own ImageProducer. All you do with this is duplicate functionality of MemoryImageSource, but it will run 20% faster, and should only take an hour or so to implement.

Anyway, I guess your real question is timing? Yes, this is tricky, but not impossible. First, recognize that different platforms have different timing resolutions, but they’re consistent: that is, win98 will only return System.currentTimeMillis() in multiples of 50ms, WinNT/2000 returns in multiples of 10ms, etc.
So 50ms resolution would normally hose your chance of getting robust 20fps, right? Here’s the trick: don’t sample the time every frame. Sample it, say, every 10 frames and then compare the current time to where you expected to be. How you work with this is up to you. TheLorax posted code a while back that takes advantage of this, and many people here use it (someone else repost it plz?). That code attempts to keep a fixed framerate by estimating the amount of time you spend sleeping each frame, and then adjusting that time every 10 frames or so based on whether you’ve slept too much or too little over the past 10 frames. The problem with this is that your applet must have a relatively constant CPU use or time will be noticably inconsistent. I’d recommend writing your own class which governs your applet’s sleep time based on this principle.
Good luck.

#3

Thanks :slight_smile:

I am not planning on using 1.1 specifically, so I don’t think that the rendering speed is going to be as much of a problem. I have tried a bunch of stuff and I can keep the speed up without much trouble.

I guess that the best I can hope for is the framerate adjusting that you mentioned. This wouldn’t smooth out the small spurts unfortunately, but life ain’t perfect.

I really appreciate the response, and I guess I’ll have to wait and see if I get a noticable problem or not. I’m just a picky guy, and want everything to be perfect. At least now I am fairly confident that there wasn’t something obvious in the timing department that I missed.

I still don’t understand why the Java3D timer class always returns 0 on my machine though.