New discovery about SDL hw acceleration.

[Jason Chong]

I was playing with libSDL till 6:30 am in the morning and i finally found out something.

I was testing the testblitspeed.c sample and I could never get sdl_hwsurface to work , the frame rate is always the same no matter which command line parameter I gave it. The stdout.txt logs keeps showig a sdl_swsurface instead of sdl_hwsurface.

Finally I decided to modify the code and force a fullscreen switch and there you have it, the root of the problem, and stdout.txt finally reflects the sdl_hwsurface switch i enabled. Frame rate went from 400 fps to over 3000. If i add the sdl_doublebuf flag it shot through the roof in hardware, over 20,000 fps ?!!

SDL will NEVER accelerate your blits in any way in a non-fullscreen app.

This is kinda unacceptable to me, as any 2D sdk or even ddraw will accelerate your blits in a window.

I had to drop it i guess. :(

Will now switch to popcap framework instead.

[Fabio]

Why don't you make your own before you get disappointed even by some PopCap's feature (or lack of)?

Ok, I think I know.. but OpenGL is not that hard to code at all, unlike DirectS*it, so you may at least give it a try..

[Savant]

but OpenGL is not that hard to code at all, unlike DirectS*it, so you may at least give it a try..
This is an out dated and irrelevant way of thinking. You should look at a version of DirectX higher than 7.0

They are on par with each other.

[mahlzeit]

Sometimes it helps to read the manual. ;) From the SDL docs:

"Be aware that you may request a hardware surface, but receive a software surface. Many platforms can only provide a hardware surface when using SDL_FULLSCREEN."

[Jason Chong]

Sometimes it helps to read the manual. ;) From the SDL docs:

"Be aware that you may request a hardware surface, but receive a software surface. Many platforms can only provide a hardware surface when using SDL_FULLSCREEN."


Pray tell which part of the documentation says that ?

I've read the docs and I didn't see any line of text saying THAT.

A grep on SDL_FULLSCREEN on the html docs returns only these:

C:\sdl\mingw\docs\html>grep -i+ "sdl_fullscreen" *.html
File guidevideoopengl.html:
flags = SDL_OPENGL | SDL_FULLSCREEN;
flags = SDL_OPENGL | SDL_FULLSCREEN;
File sdlenvvars.html:
>SDL_FULLSCREEN_UPDATE</TT
File sdlinitsubsystem.html:
SDL_SetVideoMode(640, 480, 16, SDL_DOUBLEBUF|SDL_FULLSCREEN);
File sdllistmodes.html:
modes=SDL_ListModes(NULL, SDL_FULLSCREEN|SDL_HWSURFACE);
File sdlsetvideomode.html:
>SDL_FULLSCREEN</TT
File sdlsurface.html:
>SDL_FULLSCREEN</TT

[Savant]

http://www.google.com/search?q=SDL_FULLSCREEN+acceleration

[Jason Chong]

http://www.google.com/search?q=SDL_FULLSCREEN+acceleration


The manual , the SDL dorkumentashyun.

Where in the manual does it say what Mahlzeit quoted ?

;)

[HairyTroll]

FYI: Here is an article that describes just this.

Animation in SDL: Hardware Surfaces (http://www.linuxdevcenter.com/pub/a/linux/2003/08/07/sdl_anim.html)

[mahlzeit]

The quote comes from: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSetVideoMode

[Jason Chong]

The quote comes from: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSetVideoMode


Thanks, didn't see that in the doc that came with my download. ;-)

[Savant]

Google is my manual. I've been coding in SDL/OpenGL for a few weeks now (learning, etc) and I'm not even aware that SDL comes with a manual...

[Jason Chong]

FYI: Here is an article that describes just this.

Animation in SDL: Hardware Surfaces (http://www.linuxdevcenter.com/pub/a/linux/2003/08/07/sdl_anim.html)


"The part that isn't obvious is that on my desktop system if I want a hardware surface, it has to be full screen. I can't get a hardware surface for a window. This is one of those things that is operating system and device driver specific. Some systems let you have a hardware surface for a window. Even if you can get a hardware surface for a window, you may not be able to get a double buffered hardware surface for a window."

Well I guess I found out a bit late but nevertheless, it was informative.

Even the old DirectDraw accelerates in a window.

I see no reason why SDL couldn't accelerate in a window if it's able to
use DirectDraw though.

"Some systems let you have a hardware surface for a window."

My system definitely allows hardware surface for windowed mode even in DirectDraw, and it's a pity libSDL doesn't take advantage of it.

[HairyTroll]

The quote comes from: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSetVideoMode


I missed this as well: "When you use hardware surfaces (SDL_HWSURFACE), SDL copies the surfaces from video memory to system memory when you lock them, and back when you unlock them."

Need to go back and verify that I'm not performing any unnecessary locks.

[cairnswm]

Remember also that SDL supports OpenGL within its windows allowing you full access to OpenGL functionality while using the simpler SDL wrappers.

[Fabio]

This is an out dated and irrelevant way of thinking. You should look at a version of DirectX higher than 7.0Didn't I?

They are on par with each other.Did you know that since DirectX 8.0, they tried more or less to clone OpenGL? :D :D :D
Why advocate the clone when you can code for the original? Lack of drivers support? Please...

[mr n00b]

Did you know that since DirectX 8.0, they tried more or less to clone OpenGL? :D :D :D

It's the other way around. Even though I don't think the OpenGL ARB (Architect Review Board) has been deliberately cloning DirectX, their effort to catch up with recent hardware changes has brought OpenGL much closer to DirectX.

OpenGL has historically been much slower at evolving with the underlying hardware. Take a look at the following two examples:

http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt

The first is the first convenient way of using 'render to texture' functionality in OpenGL and driver support for it came last summer. The second is the first convenient way of using the equivalent of DirectX vertex buffers and has been around for about 2 and half years. This functionality has been exposed in DirectX for a long time.

With vertex buffer object, frame buffer objects and fragment and vertex programs OpenGL and DirectX is indeed very similar. OpenGL has one big drawback and it's that it has no type safety, all objects are of type unsigned int (handles). Also the entire OpenGL state is hidden in an invisible state machine (the Rendering Context). In DirectX all of this is explicitly exposed through various objects.

(btw, at my current job we use OpenGL.)

/mr n00b

[Chozabu]

Last time i looked at Direct3D was in DirectX 8... and i didnt like it as much as opengl - to be fair i didnt look at it for very long, and was alredy bias against it, as one of my major requirments is cross platform compatability.
Though i dont know, im willing to accept D3D (and the rest of DX) may have improved alot, or even just suit other people better than my choices - though do doubt it, and being so tied to windows does kinda suck...

I think doing 2D games in 3D (OGL or perhaps even D3D) will normally give more advantages than problems - the Z dimension is great for effects, depth sorting and lots of other things, also means you can easily combine/switch to 3d graphics.