Odd Display.sync timing issues

[Orangy Tang]

This is baffling me, to the point where I feel I must be missing something obvious - the following code works just dandy on my home pc, and on several other pcs, but my work pc runs at twice the framerate instead of the capped 60fps.

while (gameRunning)
		{
			Display.sync(FRAME_RATE);
			
			update();
				
			render();
			
			if (Display.isCloseRequested() || Keyboard.isKeyDown(Keyboard.KEY_ESCAPE))
				gameRunning = false;
			
			Display.update();
                                 }

sync() runs at ~120fps. sync2() gives 75fps, and sync3() gives ~220fps. On other machines these stick to 60fps as expected.

This is windowed, and I don't try and set vsync either. I don't understand how I could be seeing such different behaviours on this machine. Oddly, Cas' Titan Attacks seems to be normal speed, and the Space Invaders demo seems to be normal speed too. As far as I can see my loop is identical to the one in Space Invaders.

Has anyone any ideas as to what to try next? Cheers

Just from eyeballing the values from Sys.getTime(), they appear to be counting up twice as fast as they should be. Why would this be so?

[Orangy Tang]

Hmm. I upgraded to lwjgl beta 3 and it seems to be fixed, IIRC my previous version was beta 1.

Edit: and now it's broken again. Without actually changing any code. WTF?

[Fool Running]

Can you actually verify that Sys.getTime() is counting too fast?

Is it possible that the machine doesn't support 1ms time of the timers? We don't seem to be checking for errors in org_lwjgl_Sys.Java_org_lwjgl_NativeSysImplementation_getTime(). It might be possible that we are getting an error and ignoring it. We just spit out a hard-coded 1000 for the Java_org_lwjgl_NativeSysImplementation_getTimerResolution() as well, instead of actually checking to see if its possible

This might possibly be a bug in the way LWJGL handles the timers :cry:

EDIT: This was all assuming you are working on Windows I can't seem to find the Sys implementation code for the other platforms :?

[Orangy Tang]

Even System.currentTimeMillis is twice as fast as it should be.

[Orangy Tang]

Can you actually verify that Sys.getTime() is counting too fast?

How? At the moment I'm just printing it out, just watching it it's quite clear that it's counting faster than 1000 every second.

I was just about to verify it in code by comparing against System.currentTimeMillis, but that seems to be too fast too. The code is currently 1.4 so I can't easily check against the new nano timer, but I might look into it.

[Fool Running]

How? At the moment I'm just printing it out, just watching it it's quite clear that it's counting faster than 1000 every second.

That's good enough for me :lol:

I was just about to verify it in code by comparing against System.currentTimeMillis, but that seems to be too fast too.

That's really strange... :?

Well, I'm out of ideas. Anyone else can chime in here

[MarneusCalgarXP]

Just an question : did you overclock your CPU ?

[Orangy Tang]

No, no overclocking going on.

Oddly enough the problem seems to come and go. I'm starting to wonder whether particular other programs may be messing with the clock or something equally stupid.

[princec]

Same old problem: system changes its clock speed to cope with internal load. Probably because it's a cheapass heap of rubbish they gave you in the office, yes?

Cas

[Orangy Tang]

Well it's a dual Intel Xeon 3.0Ghz, so it's supposed to be quite good. However theres definately something funny going on. I'm going to have a poke around in the BIOS and see if I can spot anything to disable.

[Matzon]

try disabling HT if it has it