At ‘Press space to start’:
J2D: 430-440 FPS
OGL: 475-480 FPS
OGL and j2d both at 50 FPS almost all the time, occasionally rise to 51 for a few moments, or drop to 49 for a few moments (less than a second).
This is on an LCD monitor running I believe at 60 Hz - certainly, the XF86 config allows X to choose a range of anything in “60 - 60” which is pretty unambigious ;).
J2D starts off at 90-91,
once I kill a few enemies the fps goes crazy 300-400-500fps.
It stop around 500-600 ish, though its very erratic and the game is very jerky.
the ogl version runs at a constants 60fps, vsync’ed i guess.
blah^3 - LCD monitors claim to refresh at 60Hz but in fact sync at 50-52Hz. Don’t know why. One of the reasons AF was so hard to begin with was because my Inspiron synced at 52Hz when I thought it was 60Hz - so everyone else got a game that ran 20% faster!
Cas 
[quote]Fantastic news, thanks for the retest!
Any news on when Apple are going to sort out their graphics pipeline and make Java2D accelerated? Its the only thing stopping me buying a PowerBook.
[/quote]
Apple NEVER tells what they are doing… they only announce it when it is done… but there have been strong hints that they want to get the openGL pipeline from 1.5 and use it. I think that if their Java team is a bit small that is probably the best use of their resources.
They are well aware of the graphics performance issues so I really think they will have a great 1.5 implementation. They have been addressing performance to some degree in their 1.4 updates.
I forgot to mention that the OpenGL version played much smoother in general on the Mac… but that is to be expected.
Looks like I either have to bring in a high res timer or just give it up… I didn’t really want to bring in a high res timer as it adds complexity when writing the assocaited tutorial.
I supposes I could do the 4k contest thing and go fullscreen and rely on vsync to slow the world down…
Ok, one more test, replace the sleep all together with Thread.yield(). I guess currentTimeMillis() is still not going to be good enough on some systems.
Kev
PS: Source is updated also.
/**
* Get the closest greater power of 2 to the fold number
*
* @param fold The target number
* @return The power of 2
*/
private int get2Fold(int fold) {
int ret = 2;
while (ret < fold) {
ret *= 2;
}
return ret;
}
The smallest power of two value is 1(2^0) and not 2(2^1)
Yeah, fair point 
A 1 pixel height or width texture would be scary, but I spose you pixel twiddlers do that sort of thing… I’ll update it, and the german->english documentation at the same time (grabbed this code from an old project)
Kev
A 1 pixel height or width texture would be scary, but I
spose you pixel twiddlers do that sort of thing
Well, there was a weird way doing cel shading with a 1D texture (without doubling the poly count) and something else, I’ve forgotten. But, y’know, with one 1x4096 (extreme unlikely) texture you would waste as much space as a big fat ultra huge 64x64 texture 
;D
Hmm… in the texture loader there is a comment at the very beginning, stating that it’s from the wiki, but I coudn’t find it there.
Oh great I have to login in order to be allowed using the search function ._.
Oh and the search on the left side doesn’t do anything. Awesome! Now I have 3 ways to reload the page :-/
Think I’m going to have to give up, I’ve personally tested on 2 Linux installs, and 4 Windows boxes and can’t see the stuttering people are talking about. However, I’m perfectly willing to accept its there. My gut feeling is its to do with the lack of the high resolution timer but without having a box that shows the symptoms I can’t really prove this either way.
I also don’t want to confuse people by including a high-res timer in the tutorial. On the flip side, I don’t want to be advocating bad practice or simply making java look bad.
Kev
PS. The texture loader in the Wiki, http://wiki.java.net/bin/view/Games/TextureLoadingExample
Thanks for the link
Searched for it under opengl… duh.
Well, you could work around the timing limitation, by averaging the time deltas across several frames or a specific timespan (thus assuming the framerate is quite stable).
However, you would end up with rather weird and complicated code. So… just using a proper timer and time deltas would be much easier. I also think that that concept is pretty straightforward and rather important for game programming in general. It’s also one of the things most newbie’s are interested in.
Think about it - JOGL is about 100 times scarier than timing
Get the time fraction and move everything units_per_second * time_fraction and that’s it. No one would be scared away by that.
On a second thought… you could introduce the timing seperatly in a mini tutorial wich just changes a handfull of lines of the original invaders tutorial. Thus you would end up with something like this:
- Space Invaders
- Space Invaders with correct timing
- Space Invaders with correct timing and JOGL
This way you would also get a nicer difficulty ramping imo
[quote]Well, you could work around the timing limitation, by averaging the time deltas across several frames or a specific timespan (thus assuming the framerate is quite stable).
However, you would end up with rather weird and complicated code.
[/quote]
I’ve done that several times before (back when I was stuck on win98 with its awful resolution timer) and avaraging the last 5 or so frame deltas works surprisingly well. The codes is quite clean as well, since you only need to do your avaraging once (start of a frame, instead of just calculating the frame time you avarage it as well and shuffle your prev 5 times back). The rest of the update code looks exactly the same.
It’d be simple to set the number of frames avaraged over via the command line, so you could actually see how much effect it was having.
“rather weird and complicated” was ment in comparsion with the usual (high res) way.
Averaging at the beginning could bypass hotspot and you would end up with a game wich runs too fast after warmup.
Either way it’s more complicated than the real thing and it feels like a hack… erm actually it’s one
[quote]Thanks for the link
On a second thought… you could introduce the timing seperatly in a mini tutorial wich just changes a handfull of lines of the original invaders tutorial. Thus you would end up with something like this:
- Space Invaders
- Space Invaders with correct timing
- Space Invaders with correct timing and JOGL
This way you would also get a nicer difficulty ramping imo
[/quote]
Sounds a good idea.
EDIT: Also an excellent way of making the point how important and yet easy-to-not-notice correct timing is; e.g. linux developers can write smooth games that run like **** on windows, through no fault of their own. But knowing the problem in advance, everyone can write games that are smooth everywhere :).
PS I don’t understand why there’s a timing issue on linux, but it may be a conincidental artifact of something else broken on this machine (which is quite buggered at the moment). If I still get problems after reformatting, I’ll look into it in more detail myself.
'course its a hack, it just happens to be one that works rather well if you’ve got an inadaquate system timer.
Timing is easy. With a timer. That’s all there is to it.
Long live the LWJGL!
Cas
[quote]Timing is easy. With a timer. That’s all there is to it.
Long live the LWJGL!
Cas
[/quote]
…my point is that it’s easy for a newbie to not realise the problem, and spend weeks trying to reproduce it on their own machine without a clue what’s going wrong :).
Ok, guess thats my evening sorted then…
Kev
Yep. That also happend to me at the beginning (~2000). I needed timing, searched for it and found that CurrentTimeMilis (or so) thingy and I though it would return milliseconds just like that old turboC 1.0 thingy did (from the late 80ies). So why should I expect getting less then milliseconds? I wouldn’t think, that a method like toString() would return an int
With that “nice” method I wrote an animation loop for a swirling double helix text scroller and I thought that I did everything correct. Well, infact I did, but it didn’t worked out as intended, since that crappy method returns 50-55msec “accurate” bull.
Later then I read somewere else that it’s only as accurate as the tick frequency of the underlying operating system. Now how useless is that please?
I. Was. So. Goddamn. . Off.
How good is a timer wich you even can’t use for measuring network latency?
I’m still quite annoyed by the fact, that sun took so long for including such a fundamental thing as a usable timer. It took somewhat like 4-5 years from the RFE until it was finally included. So writing a RFE seems to be totally useless especially for things wich are less basic. Look at that structs RFE it will take 3years to NEVER.