Dynamic Vsync

Guardian (623)

26-03-2009, 10:15

Could someone explain to me the principles of dynamic vsync as used in the recent Konami games patches ?

I suppose that while static vsync forces to update the frame on a given vsync interruption, dynamic vsync waits for a certain event before updating the frame at the next vsync interruption, but I would like to know more ...

Por ro

Prophet (3650)

26-03-2009, 11:16

me too, tho there's some info @ the "salamande patch" newpost, I'd like to see some more (specs) info on that.

By Google

Por erikd

Master (156)

26-03-2009, 11:30

With full vsync (or 'static vsync' if you will), the game will always wait for vsync for framebuffer updates. With dynamic vsync, it will only stay vsync-ed while it can keep up: When it misses a frame, it won't wait for the next vsync signal, but update as soon as it can (trading a framerate hit with screen tearing) and will enable vsync again as soon as it can.
I'm not sure it's the same thing as the recent Konami patches, but it's a well known technique in main stream game development.

Por Metalion

Guardian (623)

26-03-2009, 11:44

With full vsync (or 'static vsync' if you will), the game will always wait for vsync for framebuffer updates. With dynamic vsync, it will only stay vsync-ed while it can keep up: When it misses a frame, it won't wait for the next vsync signal, but update as soon as it can (trading a framerate hit with screen tearing) and will enable vsync again as soon as it can.
I don't see how that technique can speed up the framerate, on the contrary, it has a down effect on it.

But reading your post got me thinking ... Maybe that the technique used is the other way around : if the framebuffer update takes less time than the wait between two vblank marked for scrolling timing, than the CPU can use that waiting time to update the next frame in advance, and gain time when the given vblank occurs.

If that's what we're talking about, then that technique is called triple-buffering.

Por Metalion

Guardian (623)

26-03-2009, 11:55

there's some info @ the "salamande patch" newpost
I just read that post and found some info I did not have before, but I still have to understand it !
But it looks a little bit different than triple-buffering

Por erikd

Master (156)

26-03-2009, 12:03

I don't see how that technique can speed up the framerate, on the contrary, it has a down effect on it.

No:
Say, you're running 50Hz. That means there's a vblank every 20ms.
If a game takes 21ms for a frame to process, it would miss one vblank and would therefor have to wait another 19ms for the next frame (if you were to keep synchronizing with vblank).
Therefor it would only render 25 fps instead of ~47.6 fps (with tearing).
Temporarily turning off vsync then WILL gain you speed then (at the cost of tearing).

If that's what we're talking about, then that technique is called triple-buffering.
Except that there's no 3 frame buffers here, so I don't think that idea flies

But again, I'm not really sure what they did with the Konami patch, so I also don't know if they did the same thing I described.

Por Metalion

Guardian (623)

26-03-2009, 13:08

Say, you're running 50Hz. That means there's a vblank every 20ms.
If a game takes 21ms for a frame to process, it would miss one vblank and would therefor have to wait another 19ms for the next frame (if you were to keep synchronizing with vblank).
Therefor it would only render 25 fps instead of ~47.6 fps (with tearing).
Temporarily turning off vsync then WILL gain you speed then (at the cost of tearing).
Yes, reading those newspost reactions led me to conclude to the same thing.
So in a nutshell, dynamic vsync trades speed for frame tearing.

But it is also said that that patch avoids overclocked CPU to run the game too fast.
It means that it has to synchronize framerate with something else ...

Por erikd

Master (156)

26-03-2009, 13:36

But it is also said that that patch avoids overclocked CPU to run the game too fast.
It means that it has to synchronize framerate with something else ...

I think it will still synchronize to vblank. With a fast CPU, it just doesn't have to temporarily disable vsync because it can always keep up, so it will always run nicely vsync'ed with no tearing.

Por ARTRAG

Enlighted (4258)

27-03-2009, 11:10

I'm interested in dynamic vsync and i need to understand if I have some margins to improve my code.

Here as I do now:

In my code, in the ISR, I update the SAT, the PNT, and the definition of some tiles and sprites.
The ISR, at each execution, increases a counter, "tic".
The main() works at half rate, i.e. in the odd frames I do some tasks, in the even, other tasks,
but the ISR is called at any frame as SAT update is needed by sprite multiplexing and the animation of some tiles and sprites (changing their definition) has to go at full rate.

this is my main code

  tic = 0;

  while (mcphase != dead)
    {
      if (!(tic & 1))
        asm ("halt");

      di ();
      mcmain ();       // animate the main character
      npctmain ();      //animate the enemies based on tiles 
      ei ();

      {
        uchar kb6 = checkkbd (6);
        if (!(kb6 & 64))        //keyF2
            menu();
      }

      if ((tic & 1))
        asm ("halt");
  
      di ();
      npcsmain ();      //animate the enemies based on sprites
      memcpy (sat_main + N_main, sat_main, N_main);  // Used for sprite rotation
      memcpy (sat_det + N_det, sat_det, N_det);
      ei ();
      collisiontest ();      //verify collisions of any kind

    }

As you can see I already do not wait the halt s the code is late, and I delay the ISR until the previous code has ended updating the RAM copy of the SAT and of the PNT.

Is there more in the dynamic vsync?

Maybe, instead of delaying the ISR, its execution is totally avoided ?
This saves same CPU time, but causes a true frame loss instead of frame tearing.

Is it?

Por ARTRAG

Enlighted (4258)

27-03-2009, 14:41

As you can see I already do not wait the halt s the code is late, and I delay the ISR until the previous code has ended updating the RAM copy of the SAT and of the PNT.

Is there more in the dynamic vsync?

Maybe, instead of delaying the ISR, its execution is totally avoided ?
This saves same CPU time, but causes a true frame loss instead of frame tearing.

Is it?

Better if I explain a bit what I mean:

As you can see, if the code is late, it does not wait the halt: due to DI/EI, the ISR is delayed until the code has ended updating the copy in RAM of SAT and PNT.

Note that in this way the IRS routine can be executed outside the Vblanc, causing occasionally loss of data on slow VDPs.
Moreover this leads to occasional frame tearing, as the screen is updated when the raster is in the middle of the work.

Is there more in the dynamic vsync?

Does it avoid to execute the ISR when the CPU is late?
This saves same CPU time, but causes a true frame loss instead of frame tearing.

ps
ISR = interrupt service routine