Pondering a Smoother Scroll (OpenGL)

[deathshadow]

Though I completely agree with that point of view. There is a single obstacle when you are enabling vsync. If you're game's main run cycle is frame based then you will be restricted to 60 game cycles. (or whatever else your monitor runs at)

Well, technically restricted by whatever refresh rate the user has it set to - which could be anywhere from 43hz to 120hz. (though I doubt anyone actually still runs 43hz interlaced...)

It's a bad timer to use because you have no idea what the users refresh rate is - and should your render time take LONGER than the refresh rate, your game will slow down not 'keeping up' with realtime.

Which is why most games scale their movement and responses to a system timer (WM_Timer good as always) independant of the rendering engine. You render where it is at the start of the rendering process - you don't update where it is at the same time, you use a separate timer event for that... therin if the frame rate drops because the scene is too complex, the game keeps going at the same speed

That and the fact you could make the physics/movement a separate thread, making better use of all these modern multi-core processors.

[WILL]

Darn I'm getting a memory error after adding it. :?

I've added glext to the uses clause and it compiled and ran fine. However once I start to run the game it crashes with a SIGSEG (memory) error.

Is there a specific order that I have to switch this on and off in? ie. before/after window creation or gl initialization...

[WILL]

Which is why most games scale their movement and responses to a system timer (WM_Timer good as always) independant of the rendering engine. You render where it is at the start of the rendering process - you don't update where it is at the same time, you use a separate timer event for that... therin if the frame rate drops because the scene is too complex, the game keeps going at the same speed

That and the fact you could make the physics/movement a separate thread, making better use of all these modern multi-core processors.

So in your honest opinion you think that the only way to break the game cycle limit past the monitor's refresh rate is to go multi-threaded?

[JSoftware]

SIGSEG? Isn't that the linux exception equivalent to an Access violation?

If so then it's because you try to use a windows gl(wgl) extension. If you are indeed using windows do you then remember to load the extension? Most glext units i've seen uses dynamic loading of dll's

[WILL]

SIGSEG? Isn't that the linux exception equivalent to an Access violation?

Sorry you caught me. It was 'SIGSEGV'.

If so then it's because you try to use a windows gl(wgl) extension. If you are indeed using windows do you then remember to load the extension? Most glext units i've seen uses dynamic loading of dll's

Hmm... good question. As far as I know, I've never had to dynamically load anything for JEDI-SDL's GL functions. But then I've never used any of the glext units till now either.

whats the filename I'm looking for?

[JSoftware]

Can you try calling something like Load_WGL_EXT_swap_control(); or glext_LoadExtension('WGL_EXT_swap_control');?

[deathshadow]

So in your honest opinion you think that the only way to break the game cycle limit past the monitor's refresh rate is to go multi-threaded?

Not what I meant - I meant to avoid wasting CPU time that could be better spent elsewhere on faster machines, and prevent the game from running slower on slower machines.

If the machine isn't fast enough to run the game at 60fps, you should be dropping frames but still have the game run as fast as on any other computer. This is how the big name 3d games all work - the game doesn't slow down just because it's not fast enough, it just starts dropping frames - likewise the game doesn't speed up just because it can render 120fps... you have to scale your movement to the time available.

Multithreading is a simple way to do it, and takes advantage of the new multi-core machines, or even older multi-processor machines, but it's certainly not the only way... You could set up a timer, then when you go to update your movement you scale it to the time elapsed since the last time your movement was done. Delphi's TTimer object is ideal for both approaches... If you set it to 60 times a second and handled all movement in the onTimer method, problem solved (I'd actually run 240 there so as to allow faster FPS to have something to draw). You could even set the timer to say... 512 times a second, just increment a byte timer in your ontimer method, and scale movement based on how many 'ticks' have gone by at render time.

The key is to make 100% sure the game runs at the same speed regardless of the hardware it's on or how complex a scene is... and refresh rate doesn't do that.