Well, here we go again 
Thanks to Matzon I’ve now got a version of spaceinvaders to run in LWJGL. Seeing as I’ve never deployed a LWJGL via webstart could you let me know if this works for you…
http://www.cokeandcode.com/spaceinvaders104/si104.jnlp
The article about the updates will be along soon, honest 
Thanks for any feedback,
Kev
It ran for me, was wondering why it said it was downloading jogl until I got to the choice asking for 2d jogl or lwjgl. I chose lwjgl and it worked fine (no sound though but I assume that’s normal).
Edit: Win98 (in case you needed to know by OS if it worked
all three work fine
fps:
2d 100, jogl 85, lwgl 85+no mouse cursor
LWJGL and JOGL work fine - somehow I only get 7-9 fps (!!) in the Java2D one… using 1.5 beta 1
ahhh, this exhibits the strange inconsistent framerate as Quix and Survivor do. This coincides with me using a hyperthreaded chip.
This means all three of you are doing it wrong somehow. I am trying to figure out what right now.
Cas
Strictly, thats only 2, since I did Survivor coding for timing too
Cheers for looking into this, it’d be great to know.
Kev
[quote]lwgl 85+no mouse cursor
[/quote]
Yeah - the code I sent disabled the mouse cursor - It was blocking my view
Framerate weirdness is… confusing. Did a bunch of tests with Cas’ HT machine and I can’t make sense of it.
With Quix, actual time between frames (when taking off all vsync and limiters) is in the region of 125fps. I’d expect spaceinvaders to be running faster than that, but probably not much difference. Either way its way over the desired 60fps that I’m vsync’ing to.
Equally, my game loop structure is identical to Cas’ for Super Elvis (after having swiped it from a post a while back). Super Elvis remains smooth, yet Quix goes weird - apparently from taking too long per frame.
Cas mentioned that spaceinvaders with a Display.sync inserted works smooth for 60, yet jerky at 100 (where it probably should be fine). In a similar vein, Quix is normal when forced to 30fps yet goes fruity at 60fps.
I’m totally confused. Anyone with any hints would be greatfully appreciated…
Either way its way over the desired 60fps that I’m vsync’ing to.
Well, y’know… vsync can also be actually disabled even if the driver tells you otherwise.
This happens for example on nvidia boards if vsync is turned to “always off”. The other two options (on by default and off by default) allow you to switch it on and off how you like.
So… even if it tells you it’s on, don’t believe that. Have the vsynced loop backed up by a frame capping routine. Take a look at the example lwjgl mainloop thread (it was updated several times and the latest version should reflect that).
Forgot to mention, even the LWJGL version is still using GageTimer.
Is there any chance of a LWJGL timer package that distributed seperately to the main bulk of LWJGL? If the LWJGL timer copes with all situations in a simple manner that’d be very useful
Kev
[quote] Have the vsynced loop backed up by a frame capping routine. Take a look at the example lwjgl mainloop thread (it was updated several times and the latest version should reflect that).
[/quote]
Its already in in the form of a Display.sync call, and my main loops was almost certainly snagged direct from that thread.
Mmmmmh :-/
Drawing the last 100 frame times (in msec) as lines might give a clue. You can easily see frame drops then.
Tried outputting the frame times, on Cas’ machine it was always above 60, and almost always above 100fps. Theres really not enough going on to tax a system.
Frame times at about 60?
Well, 75fps=13.33 msec per frame. That’s the thing I ment.
[url=http://people.freenet.de/ki_onyx/ftd.png]screenie/url
See that thing in the lower right? It displays the frame times graphically. One pixel for one msec.
It’s kinda interesting. See those rather big spikes followed by a pit? Rocksolid 75fps - despite the fact that I kinda “missed” some frames. That’s tripple buffering in action
package tools;
import org.lwjgl.Sys;
public class FrameCounter
{
private static long lastTime=0;
private static String fpsStr="";
private static long frameTime=0;
private static long lastFrameTime=0;
private static long timerRes;
private static long frameCount=0;
public FrameCounter()
{
timerRes = Sys.getTimerResolution();
}
public void tick()
{
frameCount++;
long currentTime = Sys.getTime();
frameTime = currentTime - lastFrameTime;
lastFrameTime = currentTime;
if(currentTime - lastTime > timerRes)
{
fpsStr=(int)((float)frameCount/(float)(currentTime - lastTime)*timerRes)+"fps";
frameCount=0;
lastTime=currentTime;
}
}
public String getStr()
{
return fpsStr;
}
public long getFrameTime()
{
return frameTime;
}
}
package tools;
import org.lwjgl.opengl.GL11;
public class FrameTimeDisplay
{
private final static int MAX=100;
private long[] ft;
private int ptr=0;
public FrameTimeDisplay()
{
ft=new long[MAX];
}
public void tick(long time)
{
ft[ptr]=time/1000;
++ptr;
if(ptr>=MAX)
ptr=0;
}
public void render(int xo, int yo)
{
GL11.glColor3f(0.0f,1.0f,0.0f);
GL11.glBegin(GL11.GL_LINES);
int x=xo;
for(int i=ptr;i<MAX;i++)
{
GL11.glVertex2i(x,yo);
GL11.glVertex2i(x,(int)(yo+ft[i]));
x++;
}
for(int i=0;i<ptr;i++)
{
GL11.glVertex2i(x,yo);
GL11.glVertex2i(x,(int)(yo+ft[i]));
x++;
}
GL11.glEnd();
GL11.glColor3f(1.0f,1.0f,1.0f);
}
}
logic add:
framecounter.tick();
frametimedisplay.tick(framecounter.getFrameTime());
render add (asumes default-ish 2d mode with textures disabled):
frametimedisplay.render(650,50);
How’d you get triple buffering in GL? Or is it just an under-the-hood-driver thing nowadays? (hope so!)
Cas
Yep, it’s an under-the-hood thing and (as far as I can tell) generally enabled by default, because it’s the fastest way (eg the framerate isn’t necessarly halfed if the card can’t render each frame in time).
However, it can be enabled/disabled with special tools even if the driver doesn’t support that by itself.
nVidia used to have it as an option in its driver panel, something like “Render up to n frames ahead”, but it doesn’t seem to be in the latest drivers. ???
Ye… don’t have that in my rather old (32.82) drivers, too. Well, tripple buffering + vsync makes the most sense anyways and there is no need to change that (and if you really want to do that you can do that with tools like riva tuner and the like).
On a side note: cokeandcode.com seems to be down right now. Hope it’s just a temporary dns problem.
Actually, no, the box its hosted on actually seems to be dead. Hopefully, it’ll get resolved today.
Kev
Oh :-/
Evil summer temps are to blame, I guess.