Qbasicnews.com

Full Version: SDL_Flip extremely slow?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Quote:04:48:20 - Program Started
04:48:20 - Memory avilable:8114176
04:48:20 - SDL Init called: 0
04:48:20 - SDL SetVideoMode called: 7735648
04:48:20 - Entering main loop
04:48:21 - FPS: 26
04:48:22 - FPS: 27
04:48:23 - FPS: 23541
04:48:24 - FPS: 18784
04:48:25 - FPS: 24653
04:48:26 - FPS: 25366
04:48:27 - FPS: 18486
04:48:28 - FPS: 19277
04:48:29 - FPS: 25181
04:48:30 - FPS: 16545
04:48:31 - FPS: 22165
04:48:32 - FPS: 24031
04:48:33 - FPS: 24885
04:48:34 - FPS: 21955
04:48:35 - FPS: 19964
04:48:36 - FPS: 23781
04:48:37 - FPS: 19216
04:48:38 - FPS: 20002
04:48:39 - FPS: 2421
04:48:40 - FPS: 24
04:48:41 - FPS: 27
04:48:42 - FPS: 28
04:48:43 - FPS: 27
04:48:44 - FPS: 26
04:48:44 - Average FPS: 14602
04:48:44 - LOOP Exited
04:48:44 - SDL Quit

The extreme FPS is from when i minimized, or had the window in the background (cowered by other stuff)

The loop code:
Code:
timec = timer+1
do
    keys= SDL_GetKeystate(0)
    
    SDL_GetMouseState(x, y)
    
    if  SDL_LockSurface (screen) <> 0 then debug "LockSurface failed": sdl_quit: end -1
    SDL_UnLockSurface screen
    
    SDL_Flip screen
    
    SDL_PumpEvents
    
    
    
    
    
    fps=fps+1
    if timer >= timec then
        debug "FPS: "+str$(fps)
        allfps=allfps+fps
        allfpsdiv = allfpsdiv + 1
        fps=0
        timec = timer+1
    end if
loop until Peek(Keys + SDLK_ESCAPE)
debug "Average FPS: "+str$(allfps/allfpsdiv)
debug is a sub that dumps the string to a file, FPS is the same without it.

Without SDL_Flip i get:
Quote:04:56:32 - Program Started
04:56:32 - Memory avilable:2531328
04:56:32 - SDL Init called: 0
04:56:32 - SDL SetVideoMode called: 7735648
04:56:32 - Entering main loop
04:56:33 - FPS: 516017
04:56:34 - FPS: 530706
04:56:35 - FPS: 545079
04:56:36 - FPS: 541333
04:56:36 - Average FPS: 533284
04:56:36 - LOOP Exited
04:56:36 - SDL Quit


Is it supposed to be that slow?, and is there some other way to do double buffering?
yeah, i get very similiar results with Sterling's qb gfx. When you flip right after every single pixel, it's slower than qb's pset itelf. (much) Whatever though, not like your going to have to flip right after every single pixel in an application. I did two small tests, one in screen 13 and one in screen 12. In screen 13, i drew 64000 pixels (320 * 200) and then flipped it to the screen, to simulate redrawing the entire screen. I got over 1 million psets in during this time. I did the same thing in screen 12, this time drawing 640*480 pixels before flipping it to the screen. I almost faired as well, getting in 900,000+ psets in a second. Then again, that averages out to a little over 15 frames a second...

I just took out the flip, and the increase in speed was barely over 100,000 pixels more... one more frame.

::EDIT::

Out of curiosity, i did a relpset test with qb. I ended up with less than 400,000 pixels a second. (around 350,000 to 380,000) using the same technique, drawing 64000 pixels then relpcopying them to the screen.
on some cards there's no such thing as hardware flipping for certain modes.

you can either flip, or create a seperate offscreen surface with SDL_CreateSurfaceRGB(A) draw to that surface and then blit it to the onscreen buffer...
Only eight megabytes of video memory?! What video card are you using? :o
it's not about how much memory you got but wheter or not the address mapping can be changed in certain modes..

try the blitting thing...
The memory available is what FRE reports, it's free pshysical memory.

I have 32MB vmem.


I'll try the blit




But really, from 500'000FPS to 25... thats just insane.
I did a blit test with 20x20 sprites... I can get 33,000 sprites a sec, flipping them every 160 sprites.
ehm, only flip when everything is drawn for the frame, that's the way its ment to be. it can't get any faster....
Could someone give me a working example on creating a surface and draw to it.

Then blit that surface to screen?


I cant work it out, my program just bail out whn I try to plot pixels to the buffer surface.
See Optimus's demos.

What you do is(Assuming this is 32 bit):


InitSDLvideo
Init the screen surface via SDL_Surface
Make a pointer to buffer like:
dim p_buff as uinteger ' Uint32

then for every loop:

Set the p_buffer to the screen->pixel

then

*p_buffer = color

Haven't done this in FB(mainly because of the header probs) yet, but this works on C so by all intents and purposes, it should work.
Pages: 1 2