SDL 1.2 to 1.3 Migration Guide

[michal]

Nice article (and fresh, from 2010-11-14):

https://wiki.libsdl.org/moin.cgi/MigrationGuide

[pmprog]

Yeah, nice of them to complicate things by having Textures *and* Surfaces 

I've just grabbed Allegro 5 RC1. It was a bit painful to setup the library from source code, but it has a much better feature set IMO

[michal]

Do you use allegro for your game project?

[pmprog]

Yes, I used v4.2 in The Collector, and will be using v5 RC1 in Werewolves.

v5 comes with a bunch of "plugins" to support multiple graphic and audio formats. The advantage to this is you don't have separate "LoadBMP" and "LoadPNG" functions, you just "al_load_bitmap" and it'll load it based on the file extension.

[SupSuper]

Looks nice, last I checked they still only had the SDL 1.2 wiki up. Still looks to be in development though, but at least I can get a glimpse of the improvements.

Yeah, nice of them to complicate things by having Textures *and* Surfaces 

That already happened before with the SDL_SWSURFACE and SDL_HWSURFACE flags. Textures are handled at the hardware-level (Graphics Card/OpenGL), surfaces are handled at the software-level (CPU/SDL). In general hardware is always faster, but pixel-level operations can only be done at software.

[pmprog]

Yeah, but they were only flags before, you didn't have to code any differently to use them. I used to try loading most surfaces in hardware, letting them fallback to software if it failed. Now they have separated them out, you're going to either have to abstract a new "Surface" or have two lots of functions based on if you created you them SW or HW.

"Batshit crazy" is what springs to mind

[michal]

In general hardware is always faster, but pixel-level operations can only be done at software.

Looks like there's possibility for pixel level access for textures:

Textures are created with a SDL_TextureAccess SDL_TEXTUREACCESS_STATIC or SDL_TEXTUREACCESS_STREAMING. Static means the texture doesn't change often, streaming means you can access its pixels using SDL_QueryTexturePixels. It's used by the SDL engine to manage memory.

[SupSuper]

Yeah but I think everytime you need to query the pixels it needs to be transferred or locked or some other thing that makes software more efficient for that in the long-run.

In any case the differences between hardware/software surfaces go a lot deeper than I could possibly keep track of, and even though SDL would just fallback (as pmprog said), different surface types wouldn't always lead to the same result.

[Daiky]

Yeah but I think everytime you need to query the pixels it needs to be transferred or locked or some other thing that makes software more efficient for that in the long-run.

That's true. If textures are stored in hardware memory, you can not randomly access pixel data whenever you want to like you want to in software memory.
You can use shaders if you want to modify pixel data every frame, and if want to do pixel editing that can't be done with shaders, you can't do it every frame I'm afraid.
Why would you want to use it for?