Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  hmm... vsync  (Read 1640 times)
0 Members and 1 Guest are viewing this topic.
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Posted 2004-06-16 11:20:59 »

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 (*) Grin

(* only with a nvidia board so far)

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

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 Smiley

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

弾幕 ☆ @mahonnaiseblog
Offline princec

JGO Kernel


Medals: 364
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2004-06-16 12:16:20 »

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

Cas Smiley

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #2 - Posted 2004-06-16 12:18:13 »

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.

弾幕 ☆ @mahonnaiseblog
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #3 - Posted 2004-06-16 12:20:46 »

Quote
Only on newer Nvidia drivers I expect Sad 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 Roll Eyes

弾幕 ☆ @mahonnaiseblog
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #4 - Posted 2004-06-16 12:35:18 »

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

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

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... Cry

Catch up capping then.

弾幕 ☆ @mahonnaiseblog
Offline princec

JGO Kernel


Medals: 364
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2004-06-16 13:58:12 »

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 Cheesy

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 Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #6 - Posted 2004-06-16 19:18:59 »

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

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #7 - Posted 2004-06-17 02:31:31 »

Quote
[...]
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 Smiley

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.

弾幕 ☆ @mahonnaiseblog
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #8 - Posted 2004-06-17 08:58:44 »

>gonna post the code after breakfast

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

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.

弾幕 ☆ @mahonnaiseblog
Offline princec

JGO Kernel


Medals: 364
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2004-06-17 09:18:39 »

Why not just use Display.sync(61)?

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #10 - Posted 2004-06-17 09:45:05 »

Quote
Why not just use Display.sync(61)?


Uhm... because this one is a bit nicer Wink

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

弾幕 ☆ @mahonnaiseblog
Offline princec

JGO Kernel


Medals: 364
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2004-06-17 10:24:03 »

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

Cas Smiley

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #12 - Posted 2004-06-17 11:08:19 »

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 Wink

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

弾幕 ☆ @mahonnaiseblog
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #13 - Posted 2004-06-18 08:53:59 »

>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 Grin] 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) Smiley

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

弾幕 ☆ @mahonnaiseblog
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #14 - Posted 2004-06-18 10:16:45 »

SyncTest.java:158

That line is BS (doh Tongue), 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) Wink

弾幕 ☆ @mahonnaiseblog
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #15 - Posted 2004-06-18 15:21:50 »

Uhm... Embarrassed

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 :-/

弾幕 ☆ @mahonnaiseblog
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #16 - Posted 2004-06-18 16:22:37 »

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

Just re-using the ByteBuffer fixed it Smiley

弾幕 ☆ @mahonnaiseblog
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (12 views)
2014-08-28 18:26:30

CopyableCougar4 (24 views)
2014-08-22 19:31:30

atombrot (37 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (29 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (28 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (33 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!