Author Topic: SDL 1.2 to 1.3 Migration Guide  (Read 6344 times)

Offline michal

  • Commander
  • *****
  • Posts: 636
    • View Profile
SDL 1.2 to 1.3 Migration Guide
« on: November 16, 2010, 02:18:41 pm »
Nice article (and fresh, from 2010-11-14):

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

Offline pmprog

  • Commander
  • *****
  • Posts: 652
  • Contributor
    • View Profile
    • Polymath Programming
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #1 on: November 19, 2010, 11:40:51 pm »
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

Offline michal

  • Commander
  • *****
  • Posts: 636
    • View Profile
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #2 on: November 20, 2010, 11:41:00 am »
Do you use allegro for your game project?

Offline pmprog

  • Commander
  • *****
  • Posts: 652
  • Contributor
    • View Profile
    • Polymath Programming
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #3 on: November 20, 2010, 02:32:37 pm »
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.

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2161
    • View Profile
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #4 on: November 20, 2010, 06:21:46 pm »
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.

Offline pmprog

  • Commander
  • *****
  • Posts: 652
  • Contributor
    • View Profile
    • Polymath Programming
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #5 on: November 20, 2010, 07:19:35 pm »
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

Offline michal

  • Commander
  • *****
  • Posts: 636
    • View Profile
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #6 on: November 20, 2010, 08:23:15 pm »
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:

Quote
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.

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2161
    • View Profile
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #7 on: November 21, 2010, 01:49:28 am »
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.

Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: SDL 1.2 to 1.3 Migration Guide
« Reply #8 on: November 21, 2010, 01:52:15 pm »
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?