Pondering a Smoother Scroll (OpenGL)

[WILL]

Nope, I'm using OpenGL, but with SDL handling all the window management bits.

[dmantione]

Hmmm... The OpenGL version is super smooth for me.

[WILL]

This is my code to initialize video in my game.

[pascal] // Init Video Mode + Joysticks //
if (SDL_Init(SDL_INIT_VIDEO + SDL_INIT_JOYSTICK) <> 0) then
Halt;

// Set the title bar in environments that support it
SDL_WM_SetCaption('Garland''s Quest ' + EDITION_NAME + ' ' + VERSION_NUMBER, nil);

////////////////////////////////Some Extra Setup\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

//Get Video Info
videoInfo := SDL_GetVideoInfo;
flags := SDL_OPENGL; //Enable OpenGL in SDL
flags := flags or SDL_DOUBLEBUF; //Enable double buffering
flags := flags or SDL_HWPALETTE; //Store the palette in hardware
// flags := Flags or SDL_RESIZABLE; //Enable window resizing?
if (GO_FULLSCREEN) then
flags := flags + SDL_FULLSCREEN;

// This checks to see if surfaces can be stored in memory
if ( videoInfo.hw_available <> 0 ) then
flags := flags or SDL_HWSURFACE
else
flags := flags or SDL_SWSURFACE;

// This checks if hardware blits can be done
if ( videoInfo.blit_hw <> 0 ) then
flags := flags or SDL_HWACCEL;

SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );
// SDL_GL_SetAttribute( SDL_GL_SWAP_CONTROL, 1 ); // Needs SDL version 1.2.10.0 and up!

////////////////////////////////////////////////////////////////////////////////

GameScreen := SDL_SetVideoMode(ScreenWidth, ScreenHeight, 32, flags);[/pascal]

GameScreen is the surface of which resides as my primary screen buffer. (or secondary, depending on how you think about double buffering ) And I've obviously only just added the SDL_GL_SWAP_CONTROL line.

[dmantione]

The smoothscroll doesn't use the swap control flag. Lucky for me, since I'm using SDL 1.2.7. It basically does what you do and then after drawing a frame it calls SDL_GL_Swapbuffers.

[Wiering]

On my machine, OpenGL generally runs smoother than DirectX, especially for games running in a window on the desktop. With DirectX, you always loose a few frames once in a while and get some tearing, even with no other programs running. With OpenGL, after starting up (10-20 seconds) the game just runs perfectly smooth.

Unfortunately, many people don't seem to have the right drivers installed for OpenGL, so if you release a game, many people may have trouble running it. Also, for it to run perfectly smooth, people need to enable the vsync option in their driver settings. This is often disabled by default.

Anyway, the Delphi/OpenGL example for Tile Studio can scroll perfectly smooth (here at least). It uses sub-pixel scrolling too, like the smoothscroll example, but a little more advanced

In the smoothscroll demo, there are very few tiles and most are always used with the same surrounding tiles to prevent problems at the edges. But normally, if you make a game using a map of tiles, you'll want to be able to place any two tiles next to each other without running into problems. In the Tile Studio demo, this problem is solved by having separate edges and corners for combinations of neighboring tiles on your map(s). For example, if you have tiles of 32x32 pixels, TS will generate new tiles of them (with the most often occuring edges and corners, 34x34 pixels) and some extra strips for edges with other tiles (32x2 and 2x32) and other corners (2x2).

[WILL]

Hey Mike, thanks for the extra info. Though I'm not quite sure how that technique would get rid of the tearing issue. The only thing to do it seems is use vsync. :?

I went into my OpenGL settings on my system and set VSync to 'On Always'. [size=9px](it seems somehow JEDI-SDL forces it on in the software layer.)[/size] That did the trick. No more tearing and it looks a bit better.

As my game's code doesn't seem to run each frame past 60 FPS, it seems like a decent alternative. Though other than using SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1); how do I force VSync in my game? I seriously doubt that Dom would have released JEDI-SDL without the ability to put OpenGL into VSync mode. :roll:

[cragwolf]

WILL, get rid of these lines, you don't need them when using the SDL_OPENGL flag, and they might be screwing up the smoothness of your scrolling.

     flags := flags or SDL_DOUBLEBUF; //Enable double buffering
     flags := flags or SDL_HWPALETTE; //Store the palette in hardware

     // This checks to see if surfaces can be stored in memory
     if &#40; videoInfo.hw_available <> 0 &#41; then
       flags &#58;= flags or SDL_HWSURFACE
     else
       flags &#58;= flags or SDL_SWSURFACE;

     // This checks if hardware blits can be done
     if &#40; videoInfo.blit_hw <> 0 &#41; then
       flags &#58;= flags or SDL_HWACCEL;

[technomage]

Though other than using SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1); how do I force VSync in my game? I seriously doubt that Dom would have released JEDI-SDL without the ability to put OpenGL into VSync mode. :roll:

Under windows there is a wgl extension to handle swapcontrol. Under linux there is a glX extension,you will have to implement it manually for each platform.

[deathshadow]

My only issue with v-sync is that it limits you to the refresh rate of your monitor does it not?

It would be safe to say that in most cases that frame rate would be a mere 60 FPS, no?

You know, I see statements like that and I have to laugh...

Yes, it limits you to the refresh rate - and that's a GOOD thing! Why would you waste processor time rendering frames that will never even be SHOWN?

Literally, if you render 170fps and your refresh rate is only 85hz, you're only showing HALF of what you render... a total waste.

Refresh rate is how often the screen is redrawn - any 'tearing' you see is because you are trying to render a frame in the middle of the screen redraw - there is NO POINT to rendering faster than the refresh rate - EVER, unless of course you WANT it to look like crap when anything moves.

Just as there's little reason to ever doing anything higher than 60hz for the majority of people, since even then it's just a barely noticable flicker... and anything higher than 85hz is bragging, not fact since that's outside the realm of human vision (just as anything over 18khz is outside the realm of hearing)

[WILL]

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)

I think I'm asking for a time-based movement response just by mentioning it.

But how do you avoid your game from just sitting there after calling a flip when you've got more processing to do beyond just the graphics? And is there really only one way to do it?


I however do not need such things as 50 FPS suites my current game just fine. So I'm forcing vsync. [size=9px](unless those of you are truly hurting for it to be off have it set of always off)[/size]

However I believe I've found my function!
[pascal]wglSwapIntervalEXT(1);[/pascal]

This bad boy will turn on vsync for all you 60Hz fans out there. :thumbup: a 0 value however will turn it off.