GP32 Gp32 Sdl: Sdl_flip Waits For Vsync?

[kialzzz]

I started programming on the GP32 with SDL recently and the framerate with a very basic program is capped suggesting vsync is enabled. I checked the SDL source code etc but I can't find where it's waiting for the vertical retrace.

The test program I wrote simply calculates and prints the framerate then calls SDL_Flip and the result is that it's capped at 62.5 fps but when I remove the call to SDL_Flip the framerate goes incredibly high.

Can anyone shed some light on this?

 

[Nmn]

First: I'm no professional, but i'm pretty sure your saying that when you don't update the screen, it goes faster. Thats self explanatory, i think. But if your saying that without flipping you still see the screen, then somebody tell me what the hell i've been missing in all of those documents about using SDL on the gp2x...

Second: What Dev-Kit are you using? What SDL is included? This could reveal the problem easily.

 

[JonHolland]

SDL_Flip waits for Vsync, read here on the SDL wiki

On hardware that supports double-buffering, this function sets up a flip and returns. The hardware will wait for vertical retrace, and then swap video buffers before the next video surface blit or lock will return. On hardware that doesn't support double-buffering, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0)

If you don't want it to wait for vsync, then just blit your double buffer surface directly to video memory.

However, by using SDL_Flip, you impose a nice throttle on your frame rate, and a self-imposed slowdown on the program itself.

You also eliminate any flickering or tearing of the image.

--Jon

 

[kialzzz]

First: I'm no professional, but i'm pretty sure your saying that when you don't update the screen, it goes faster. Thats self explanatory, i think. But if your saying that without flipping you still see the screen, then somebody tell me what the hell i've been missing in all of those documents about using SDL on the gp2x...

Second: What Dev-Kit are you using? What SDL is included? This could reveal the problem easily.

Well with vsync disabled it tears a lot so it's useless except for testing. I wanted to know where in the code it does the vsync so I can disable it for a test I want to do.

SDL_Flip waits for Vsync, read here on the SDL wiki

On hardware that supports double-buffering, this function sets up a flip and returns. The hardware will wait for vertical retrace, and then swap video buffers before the next video surface blit or lock will return. On hardware that doesn't support double-buffering, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0)

If you don't want it to wait for vsync, then just blit your double buffer surface directly to video memory.

However, by using SDL_Flip, you impose a nice throttle on your frame rate, and a self-imposed slowdown on the program itself.

You also eliminate any flickering or tearing of the image.

--Jon

Yeah I read the SDL docs too. I want to do a test without vsync enabled which is why I'm looking for the vsync code so I can disable it.

 

[sa666666]

First: I'm no professional, but i'm pretty sure your saying that when you don't update the screen, it goes faster. Thats self explanatory, i think. But if your saying that without flipping you still see the screen, then somebody tell me what the hell i've been missing in all of those documents about using SDL on the gp2x...

Second: What Dev-Kit are you using? What SDL is included? This could reveal the problem easily.

Well with vsync disabled it tears a lot so it's useless except for testing. I wanted to know where in the code it does the vsync so I can disable it for a test I want to do.

SDL_Flip waits for Vsync, read here on the SDL wiki

On hardware that supports double-buffering, this function sets up a flip and returns. The hardware will wait for vertical retrace, and then swap video buffers before the next video surface blit or lock will return. On hardware that doesn't support double-buffering, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0)

If you don't want it to wait for vsync, then just blit your double buffer surface directly to video memory.

However, by using SDL_Flip, you impose a nice throttle on your frame rate, and a self-imposed slowdown on the program itself.

You also eliminate any flickering or tearing of the image.

--Jon

Yeah I read the SDL docs too. I want to do a test without vsync enabled which is why I'm looking for the vsync code so I can disable it.

Change the call to SDL_Flip() to SDL_UpdateRect(screen, 0, 0, 0, 0), which is what SDL_Flip() does if it doesn't have a hardware surface (which it does on the GP2X). This is in the SDL_Flip() manpage.

 

[kialzzz]

I'm using SDL for the GP32.

I've read the GP32 SDL source and it doesn't look like it is doing vsync anywhere.

I haven't yet been able to compile the GP32 SDL source (lots of errors) so I can't be sure the final version precompiled binaries I've been using are using the x_gp32 lib which is a newer version of mirko's SDK although the Makefile.gp32 does specify it's usage. If it was doing vsync it would likely be calling x_gp32_setFramebuffer since it's the only place where GP32 specific code actually does a vsync but it's not being called.

Guess I need to waste some time getting it to compile so I know what's going on with it.

Btw, I'm not interested in fixing or working around anything related to flipping or blitting etc I'm actually looking to compare SDL, GPSDK and mirkoSDK with vsync disabled.

EDIT: Pffft I know what's going on now. I've been using SDL_GetTicks and it's resolution is 16ms when using the x_gp32 lib so the 62.5 fps makes sense now.