hmm... vsync

[oNyx]

Window.isVSyncEnabled();

Since that method doesn't check if vsync is enabled, it shouldn't called that way imo, because that results only in confusion.

wasVSyncEnabled() would be a better name... and why not keep track of that flag on the java side?

1   2   3   4   5   6   7   8   9   10   11   12   13

JNIEXPORT jboolean JNICALL Java_org_lwjgl_opengl_Window_nSetVSyncEnabled   (JNIEnv * env, jclass clazz, jboolean sync) {       if (extgl_Extensions.WGL_EXT_swap_control) {             if (sync == JNI_TRUE) {                   wglSwapIntervalEXT(1);                   return JNI_TRUE;             } else {                   wglSwapIntervalEXT(0);             }       }       return JNI_FALSE; }

And then just keep the flag on the java side. I mean... it's no big deal and it's one jni thing less.

And² there is also this method:

1	int wglGetSwapIntervalEXT(void) // gets the update frequency

It would be interesting to know what that method returns if vsync is set to "always off" and wglSwapIntervalEXT(int) was called before (with something >0). Because that "always off" case is the thing wich makes the isVSyncEnabled() call pretty useless.

I already tried finding that out by myself...

Ok. Tried it again (*)

(* only with a nvidia board so far)

And wglGetSwapIntervalEXT() actually returns always 0 if vsync was set to "always off". Sweet

So... just a little change to the method, I posted above... like:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15

JNIEXPORT jboolean JNICALL Java_org_lwjgl_opengl_Window_nSetVSyncEnabled   (JNIEnv * env, jclass clazz, jboolean sync) {       if (extgl_Extensions.WGL_EXT_swap_control) {             if (sync == JNI_TRUE) {                   wglSwapIntervalEXT(1);                   if (wglGetSwapIntervalEXT()>0) {                         return JNI_TRUE;                   }             } else {                   wglSwapIntervalEXT(0);             }       }       return JNI_FALSE; }

And the vsync stuff should be actually relyable then

[sorry for the lack of structure/gramar/spellchecking - I'm really tired ]

[princec]

Only on newer Nvidia drivers I expect And even then it's not accurate if you're running in a window. Who knows whether it's synced? Bah.

Cas

[oNyx]

Framedrops are quite obvious in my current game, because it uses scrolling extensively. Right now I have the usual loop, which is backed up by a capping routine. The catch is - if vsync is actually enabled (which isn't a sure thing right now) I can "loose" some frames, because the capping prevents the machine from catching up (that works if tripple buffering is enabled).

So... being able to detect if vsync is really enabled or disabled is rather important for me (or basically every game with some kind of scrolling). I also figured out a scheme for capping wich allows to catch up (wouldn't work well for tickbased timing), but y'know... caring about the symptoms isn't the best option if you can do something about the cause.

Like everyone else I just want that my games run as smooth as possible and everything which prevents that needs to be sorted out. I hope my short story explained why a reliable vsync check is important.

Games published by our own members! Check 'em out!

[oNyx]

Only on newer Nvidia drivers I expect And even then it's not accurate if you're running in a window. Who knows whether it's synced? Bah.

Hm. Well, it worked in windowed mode.

I think I should try it over at that ati box

[oNyx]

Oh man... ati is for sure "teh suck" :-/

It always says that it's on... even if it was nuked with "always off"... gah

And on top of that with vsync enabled the sync was shifted in windowed mode (always teared at the same line).

So... Cas... you are right. ATI sucks big time and their drivers are cursed. And I was so happy just some minutes ago...

Catch up capping then.

[princec]

Everyone at ATI should be forced to print out the source code to their drivers and eat every page where a bug is identified. That'd soon change their working practises I bet

I'm not quite sure why you're missing frames now and again anyway. Occasional GC? Or is it the hires timer loop in Display that's a bit wrong?

Cas

[swpalmer]

The ATI building is just down the street... shall I arrange a road trip to go kick their butt?

[oNyx]

[...]
I'm not quite sure why you're missing frames now and again anyway. Occasional GC? Or is it the hires timer loop in Display that's a bit wrong?

It's that "catching up" with tripple buffering, which doesn't really happen anymore if the minimum time per frame is engraved in stone.

Let's say the average rendering time per frame is 5 msec and you want to cap at 100fps.

Without capping it can look like this:
10msec
14msec <- oh
6msec <- catching up
10msec
etc

No single frame were dropped, because we were able to catch up. However, with a specific minimum time per frame that part would have beeen like this:

10msec
14msec <- oh
6msec+4msec waiting
10msec

The third frame will be 4msecs late and thus we get a frame dropped.

Note: that doesn't happen if your average frametime is *way* lower. Eg 1msec per frame on average and 5msec in the worst case.

A catch up timing scheme is only slightly different:
10msec
14msec <- oh 4msecs late... I take a note
6msec + wait(gapTo - late) <- so no wait at all in this case
10msec

(gonna post the code after breakfast)

@swpalmer

Ye... some buttkicking would be in order

But y'know if even ATI didn't get that "right" (dunno if that behaviour is really specified) the other vendors like intel, matrox, s3 and the like will most likely also fail.

[oNyx]

>gonna post the code after breakfast

breakfast=coffee, food, taking a shower and lot's of testing on 3 different machines

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20

private static long timeNow, timeThen, timeLate=0; [...] public static void sync2(long fps) {       long gapTo = Sys.getTimerResolution() / fps + timeThen;       timeNow = Sys.getTime();       while(gapTo > timeNow+timeLate)       {             Thread.yield();             timeNow = Sys.getTime();       }       if(gapTo<timeNow)             timeLate = timeNow-gapTo;       else             timeLate = 0;       timeThen = timeNow; }

It works slightly better than the old one. "sync2-ing" to hz+1 works best (that hadn't helped much with the other one). That +1 just adds a little room for errors and well the timing of monitor+machine is always a bit off.

Since that beeing late thingy isn't accumulative it's just fine for tick based timing, too.

[princec]

Why not just use Display.sync(61)?

Cas

Games published by our own members! Check 'em out!

[oNyx]

Why not just use Display.sync(61)?

Uhm... because this one is a bit nicer

Instead of having a fixed minimum time per frame it checks how much the last frame was too late and adjusts the minimum time for the next frame accordingly.

Just take a look at the example, I posted previously.

The framerate is 100 - so we get a minimum time of 10 msec per frame.

-frame 1 takes 4msec to render - so we wait 6msec
-frame 2 takes 14msec to render - so we don't wait at all
-frame 3 takes 5 msec to render - so we wait 5msec
-frame 4 takes 8 msec to render - so we wait 2msec

With tripple buffering frame 3 arrives 4 msec too late - despite the fact that it didn't needed to... we even waited 5 msec.

So... if you just keep track of the amount of time, a frame is too late, you can subtract that time from your minimum time per frame (in the example 10 msecs).

The result would be look like this:
-frame 1 takes 4msec to render - so we wait 6msec
-frame 2 takes 14msec to render - so we don't wait at all
-frame 3 takes 5 msec to render - so we wait 5msec-4msec (=1 msec)
-frame 4 takes 8 msec to render - so we wait 2msec

[princec]

Does that technique only work with triple buffers? Should we adjust the LWJGL sync method to work like yours do you think?

Cas

[oNyx]

Hmm... I'm not sure.

It behaves very well especially in those border-cases (eg if the machine is good enough to render 75% of the frames in time). And it also behaves very well if vsync is disabled.

But I guess it's time to investigate a bit. Frame capping isn't that new and a kinda common task

Let's see what others think... and well it could be also implemented as an alternative capping method.

[oNyx]

>it's time to investigate a bit

Hadn't found anything useful.

Therefore I wrote a little test application this morning.

http://people.freenet.de/ki_onyx/SyncTest.zip (32kb)

java SyncTest <usual payload in msec> <spike payload in msec> <spike every x frames> [hz]

eg java -cp .;lwjgl.jar SyncTest 2 15 10 75
(2 msec are usually trashed, 15 msec occasionally [every 10 frames - uh uh heavy gc ] and hz is 75)

With those parameters you can simulate a wide spectrum of different machines. Vsync can be flipped on/off (needs to be set to anything than "always off" driver sided) and you can switch between the different sync modes (keys are displayed all the time).

"None" = as it says

"LWJGL default (FixedMin)" = the current default sync method (it's C&Ped into the programm itself, therefore it also works if you don't have the latest version from cvs)

"FixedMin no cast" = the same... just simpler and without casts. It performs equally (as expected).

"FixedMin no cast + catch up" = the new one with "catch up"

---

Well, that sync2 (catch up) method behaves either equally well (if the machine hasn't much to do) or better (if the machine is kinda busy)

But take a look for yourself. It's pretty neat and you can add other sync methods easily if you like.

[oNyx]

SyncTest.java:158

That line is BS (doh ), but it hasn't any effect anyways.

edit... oh and...

wouldn't work well for tickbased timing

That's also BS. It works also well for that, because it isn't more wrong than the other timing scheme (actually it's a bit less wrong on average)

[oNyx]

Uhm...

The print methods create a s-load of garbage. Hadn't noticed that before, because my machine was under rather heavy network load at the time (when I added the "help" text).

It's ok-ish if that block is commented out. Hadn't tought that it's that extreme :-/

[oNyx]

Updated.
http://people.freenet.de/ki_onyx/SyncTest.zip (32kb)

Just re-using the ByteBuffer fixed it