Sprig Vs Sdl_gfx....... Wow.

[TrevorBradley]

Just a quick bit of knowledge to share.... The new SDL SpriG graphics primitives libraries are exceptionally fast. Switching from SDL_gfx's rotozoom's zoomSurface to SPG_Scale cut a pair of image surface zoom functions from about 35 milliseconds down to about 4ms. (rotozoom does all the work in software, SpriG uses the hardware).

Thought I'd share just in case others here were asking about graphics primitives. SpriG might be well worth looking into. (I'm sure there's something better out there, but at 2:30 in the morning, *I'm* impressed... Let's see how it does on other graphics primitives

 

[ledow]

Just a quick bit of knowledge to share.... The new SDL SpriG graphics primitives libraries are exceptionally fast. Switching from SDL_gfx's rotozoom's zoomSurface to SPG_Scale cut a pair of image surface zoom functions from about 35 milliseconds down to about 4ms. (rotozoom does all the work in software, SpriG uses the hardware).

Thought I'd share just in case others here were asking about graphics primitives. SpriG might be well worth looking into. (I'm sure there's something better out there, but at 2:30 in the morning, *I'm* impressed... Let's see how it does on other graphics primitives

Yeah, but are they fast on your home PC, or are they faster everywhere? Especially if they make heavy use of the hardware, it may well be that they zoom on the PC and then when you put them on certain devices (GP2X, Pandora, etc.) the thing is actually slowers than SDL_gfx.

Either way, it's an interesting find that I haven't seen before. I'm actually looking at SDL_gfx's rotozoom at the moment because I want to be able to zoom into and pan around a surface on the GP2X.

 

[PokeParadox]

Always good to know of alternatives.

 

[Svartalf]

Yeah, but are they fast on your home PC, or are they faster everywhere? Especially if they make heavy use of the hardware, it may well be that they zoom on the PC and then when you put them on certain devices (GP2X, Pandora, etc.) the thing is actually slowers than SDL_gfx.

I strongly suspect that it's more due to efficient algorithms for the primitives than he's using than hardware acceleration. Much of the SDL based stuff, unless you're talking an OpenGL powered piece, tends to be all software based...

QUOTE

Either way, it's an interesting find that I haven't seen before. I'm actually looking at SDL_gfx's rotozoom at the moment because I want to be able to zoom into and pan around a surface on the GP2X.



Same here. I'm curious about the thing. SPriG is a redo of SGE according to the author's site.

 

[TrevorBradley]

QUOTE

Either way, it's an interesting find that I haven't seen before. I'm actually looking at SDL_gfx's rotozoom at the moment because I want to be able to zoom into and pan around a surface on the GP2X.

Same here. I'm curious about the thing. SPriG is a redo of SGE according to the author's site.


The commands for rotozooming are nearly identical in parameters to SDL_gfx's. It's worth a shot.

Drawing primitives seems faster (twice as fast, perhaps), but SpriG appears to use the Uint32 colour differently than SDL_gfx. Makes all my stars look yellowish/purplish. Likely the alpha channel's first instead of last from what I read in the wee hours of the morning last night. Needs more testing...

Without a Pandora on hand, all I'm making is wild guesses as to what will work better in a few months. Lots of pieces to swap in and out later to find the best optimization.

 

[benjymous]

Ooh, that looks handy - I'm heavily using SDL_gfx's rotozoom, and have been trying to work my way around a bit of slowdown this causes - I'll have to switch to Sprig and see how it compares!

 

[ldesnogu]

I strongly suspect that it's more due to efficient algorithms for the primitives than he's using than hardware acceleration. Much of the SDL based stuff, unless you're talking an OpenGL powered piece, tends to be all software based...

That makes me wonder if that kind of library should be used when we'll have hardware acceleration...

 

[Svartalf]

That makes me wonder if that kind of library should be used when we'll have hardware acceleration...

SDL itself will support accel of things like blits and colorspace conversions- if you have a backend that supports it (It may/may not before release- but eventually it WILL...food for thought there, folks...). If we have ES available, one can re-implement these libraries with ES primitives, it's just that most of the devs doing these libraries aren't wiring it in to detect the presence of OpenGL/OpenGL ES and switching gears.

 

[benjymous]

That makes me wonder if that kind of library should be used when we'll have hardware acceleration...

SDL 2.0 (and 1.3) use DirectX and/or OpenGL acceleration, if possible, when you use the new interfaces ("textures" instead of "surfaces"), but it's still WIP at the moment - I keep meaning to download the current 1.3 sources and give it a build to see how easy it'd be to port my existing code over.

 

[Svartalf]

SDL 2.0 (and 1.3) use DirectX and/or OpenGL acceleration, if possible, when you use the new interfaces ("textures" instead of "surfaces"), but it's still WIP at the moment - I keep meaning to download the current 1.3 sources and give it a build to see how easy it'd be to port my existing code over.


I'd not checked up on the status of that stuff recently- been a bit busy with other things. Having said this, I'm curious why they changed the interface, myself. I guess I need to pull the latest repository code and see what they've done and why... As for the rest, if you've got a GL/ES acceleration layer, then all one would need is to make a version that supports these primitives in that same mode against the "texture" that you're rendering to.