SDL_primitive_gfx question

[invchrist]

I'be been trying the SDL gfx functions and think I understand the basics, but have a practical question (code example):

Code:

For Teller = 1 to 250
  x1 = rnd * 800 : x2 = rnd * 800
  y1 = rnd * 600 : y2 = rnd * 600
  r = rnd *10 : g = rnd *10: b = rnd *10
LineRGBA Video, x1, y1, x2, y2, r, g, b, 255
SDL_Flip Video
Next Teller

Why is this so freaking slow?

I think the problem lies within the SDL_Flip Video, which refreshes the SDL_Surface, but there must probably be a faster way to update the "screen".

All comments & Help appreciated.

Only been here for a couple of days, but it seems like a great community. Will maybe post some newbie Freebasic-SDL-tutorials in the future, as there seems to be a "gap" there. That could take a while, as i'm only beginner level at SDL.
[/code]

[Z!re]

SDL_Flip has a "bug" that makes it eat 100% CPU...

Ig you call it many times in a short amount of time, your computer will slowdown...

Only call SDL_Flip when you need to update the screen...


SDL isnt made for drawing single pixels and showing them, it's made for drawing the entire game image, and then showing it.

[invchrist]

So there are no "fast" ways to write & refresh onto an SDL_Surface ?

Is this a FB-"implementation-bug" that could be adressed or a SDL-related issue ?

It's a pity, since it's trivial to load multiple graphics file formats onto those surfaces.

Guess then i'll have to search for, port or write a bmp-loader with "standard" FB-routines, as it seems you can't combine SDL & FB gfx routines.

On the net I haven't found any "native" FB BMP-loader yet, could that be correct ?

Thanx for the explanation !

[BastetFurry]

Erm, Meister, las das!!!!

Use this, its shorter and it works

surface = SDL_LoadBMP ( filename$ )

[Z!re]

It's a SDL thing...

Just make your code all SDL_flip at a delayed intervall.. I use once every 25th millisecond, it works great and gives 40fps.

The simplest way is to just add Sleep 10 (might need a higher value, try it)

Which will just delay your code for 10 milliseconds.. this can actually give you a higher framerate, as you dont call SDL_Flip as often, thus freeing CPU.

[invchrist]

Thanx for the tip !
I'll try it out tomorrow, and post the results here !

In the SDL docs i've also found a clue: I'll also try using SDL_Locksurface/UnlockSurface in combination with the Putpixel function (direct pixel writing) & see if that has a speed benefit, especially combined with SDL_UpdateRect for only updating the specific part of the screen which has been altered, instead of using SDL_Flip all the time.

EDIT: @BastetFurry: the problem is not the loading of graphics files like bmp onto the surfaces (which is fast), but the speed of graphics routines drawn onto those surfaces. Thanks anyway

[v3cz0r]

Every time you call flip() on any GFX library made for Windows, the whole off screen buffer will have to be copied to the visual one, and if the app is running in windowed mode, every pixel may need to be converted from the source format to the current desktop format, what takes a lot of time -- in full-screen the src/dst formats are the same (if supported), and flip() is done by the video accel, if the device supports that.

You usually don't do more than 60 calls to flip() every second. Using lock/unlock won't help much too, if you do that for every pixel drawn.

[Z!re]

v1c, it only copies the buffer if you've specified SDL_DOUBLEBUF (or whatever the constant is.. )

Otherwise it just performs a vsynched updaterect on the entire screen.


It the wait/detect of the vsynch that sucks up CPU.

Apparently they had a problem with sdl_flip missing frames on extreme end computers using high hertz rates on the monitor.

So they made the algo/function that finds the vsync more accurate, but also more CPU intensive, meaning on slower computers it will make your program slowdown, and a simple delay can fix it.

Although a delay is a bad idea, a better idea is:

Code:

Dim k as ubyte ptr
numT = SDL_GetTicks + 20
Do
k = SDL_GetKeyState(0)
If numT <= SDL_GetTicks Then
numT = SDL_GetTicks + 20
'draw stuff/update stuff

SDL_Flip video
End If
Loop until key[SDLK_ESCAPE]

That will give you 50constant FPS, it cannot go higher... although it can go lower

That way, even if drawing and updating takes 10milliseconds it will only delay for 10 more before updating again.

As opposed to the sleep method where it will always wait for 20ms, meaning, if you have a 10ms draw/update, and a 20ms sleep, you get a 30ms delay.. meaning lower framerate, which is a bad idea as it will be different from computer to computer.