Grey Alien, actually I found that a Flip -1 still does that to me on my machine... it will give you a 60Hz refresh rate, for example, but it won't be sync'd to the vertical blank perfectly so you can get tearing. Flip 1 works perfectly though. It seems as though Flip -1 does some kind of artificial timer rather than wired into the display refresh, meaning it runs a the screen Hz rate but can be up to, for example 16 millseconds offset from when the screen actually flips. Flip 1 syncs to the vblank which is better.
MGE: "And then there's pitfalls to watch out for if vsync is locked on/off from the end user side. Logic rate should be something considered during design time not changed at run time, or am I wrong there?"
Well, I think if you are trying to choose one logic rate for all displays and framerates you are going to experience some out-of-sync logic updates, unless you do some tweening like GA does. What I'm suggesting is to make your logic Hz an exact multiple of the display Hz, e.g. 60hz display does logic at 60 or 120 or 180hz. Then you make darn sure that you do an exact integer number of logic updates per frame, ie 1 2 or 3. Of course, still decoupled from the framerate, but synchronized with the `Flip 1`. Then you ideally don't need to tween.
The only drawback then is that at *runtime* you have to adjust your logic hz rate, which means if you want to take advantage of designing your physics/logic based on a known timerate, that goes out the window. This is why I `invented` the idea of having a `design rate`, some fictional hz rate that I design for, and then this is tweened to the exact position it would be at the logic rate. Then the logic can run at an exact multiple of the display hz which I am guessing is ideal, compared to trying to make your logic hz so incredibly high that there's a reduced gap between the display hz and the logic moire. Also then you don't need a really high logic rate (although it helps with some collision detection).
Gabriel I agree although I would say it's possible to get your fixed rate to be smoothly in-sync with the display hz.
Czar, you can get really simple and just do a Flip -1 or Flip 1 and open a screen with 60 as the Hz rate and then just assume it will always run at full speed but it won't necessarily be able to all the time and when it doesn't your game will go into slow-motion. The idea of timing systems is to keep objects moving and animating at the same speed all the time regardless of whether the display can draw every step.
MGE: "And then there's pitfalls to watch out for if vsync is locked on/off from the end user side. Logic rate should be something considered during design time not changed at run time, or am I wrong there?"
Well, I think if you are trying to choose one logic rate for all displays and framerates you are going to experience some out-of-sync logic updates, unless you do some tweening like GA does. What I'm suggesting is to make your logic Hz an exact multiple of the display Hz, e.g. 60hz display does logic at 60 or 120 or 180hz. Then you make darn sure that you do an exact integer number of logic updates per frame, ie 1 2 or 3. Of course, still decoupled from the framerate, but synchronized with the `Flip 1`. Then you ideally don't need to tween.
The only drawback then is that at *runtime* you have to adjust your logic hz rate, which means if you want to take advantage of designing your physics/logic based on a known timerate, that goes out the window. This is why I `invented` the idea of having a `design rate`, some fictional hz rate that I design for, and then this is tweened to the exact position it would be at the logic rate. Then the logic can run at an exact multiple of the display hz which I am guessing is ideal, compared to trying to make your logic hz so incredibly high that there's a reduced gap between the display hz and the logic moire. Also then you don't need a really high logic rate (although it helps with some collision detection).
Gabriel I agree although I would say it's possible to get your fixed rate to be smoothly in-sync with the display hz.
Czar, you can get really simple and just do a Flip -1 or Flip 1 and open a screen with 60 as the Hz rate and then just assume it will always run at full speed but it won't necessarily be able to all the time and when it doesn't your game will go into slow-motion. The idea of timing systems is to keep objects moving and animating at the same speed all the time regardless of whether the display can draw every step.