The official extensions SDL_image, SDL_ttf, SDL_mixer and SDL_net can be compiled with both 1.2 and 1.3. You may need to download them from the [[http://hg.libsdl.org/|mercurial repositories]] for the latest fixes.

The official extensions SDL_image, SDL_ttf, SDL_mixer and SDL_net have a version dedicated to SDL2.0 : SDL2_image, SDL2_ttf, SDL2_mixer and SDL2_net. You may need to download them from the [[http://hg.libsdl.org/|mercurial repositories]] for the latest fixes.

However, this multi-support can lead to delicate situations in the context of shared libraries (when using GNU/Linux distros package dependencies, or when using ms windows .dll's). For example, if your new 1.3 game links against {{{libSDL_image-1.2.so.0}}}, it will not be able to know whether SDL_image is itself linked against SDL 1.2 or SDL 1.3, especially if SDL_image is provided by the distro and not compiled by you.

However, this multi-support can lead to delicate situations in the context of shared libraries (when using GNU/Linux distros package dependencies, or when using ms windows .dll's). For example, if your new 2.0 game links against {{{libSDL_gfx.2.0.23.so.0}}}, it will not be able to know whether SDL_gfx is itself linked against SDL 1.2 or SDL 2.0, especially if SDL_gfx is provided by the distro and not compiled by you.

The !AlienBlaster code, in the Android port repository, uses a few additional functions on top of SDL, that will use either SDL 1.2 or 1.3 seemlessly, and minimise the amount of #ifdef. It's not completely fool-proof though, for instance blits between hardware surfaces will result in a no-op under 1.3. Check the C++ code at:

The !AlienBlaster code, in the Android port repository, uses a few additional functions on top of SDL, that will use either SDL 1.2 or 2.0 seemlessly, and minimise the amount of #ifdef. It's not completely fool-proof though, for instance blits between hardware surfaces will result in a no-op under 2.0. Check the C++ code at:

Textures are typically OpenGL textures or X11 pixmaps, stored as near to the graphics hardware as possible.

Textures cannot be blit on each others. They can be blit to the screen using SDL_RenderCopy.

Textures are created with a SDL_TextureAccessSDL_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.

Textures may be stored in unaccelerated memory, for instance if there's not enough memory in the graphics card.

Screen(s)

You now can create multiple screens (for instance: multiple windows). Each window has an associated Renderer. Each Renderer is managed by one of the built-in graphics drivers.

The renderer replaces your previous SDL_Surface *screen object. It has a few methods to draw points, lines, rectangles, blit textures, etc. It also has a few dedicated post-processors for alpha-blending, masks, as well as add/multiply mode, cf. SDL_BlendMode and SDL_SetRenderDrawBlendMode. Introspection can be achieved using SDL_RendererInfo.

Instead of passing around a pointer to the current screen everywhere in your code, you pass a pointer to the renderer.

You update the physical screen using SDL_RenderPresent, which replaces SDL_Flip and SDL_UpdateRects.

SDL_SetVideoMode from 1.2 is now just a compatibility function, you will not use it anymore. You can use SDL_GetWindowSurface to get a 1.2 style surface for a window if necessary.

Keys

You'll note that there are two kinds of key numbers:

SDL_Keycode: key codes, using SDL_Keycode's SDLK constants; note that SDLK_LAST disappeared, because new values cover most of 32bits. Keys associated with printable characters are compatible with Unicode UTF16.

There is now a dedicated API for textual input (e.g. to enter a small text, rather than combining keys); check Tutorials/TextInput for an introduction.

Audio

Audio is very similar to 1.2. The driver detection/priority changed, you may need to test again your target configurations.

CD-ROM

CD-ROM support was dropped in 2.0. There is no replacement.

Extensions compatibility

The official extensions SDL_image, SDL_ttf, SDL_mixer and SDL_net have a version dedicated to SDL2.0 : SDL2_image, SDL2_ttf, SDL2_mixer and SDL2_net. You may need to download them from the mercurial repositories for the latest fixes.

SDL_gfx can also be compiled with 2.0 starting since 2.0.21 (May 2010).

Changes related to software surfaces manipulation are usually trivial, so more extensions should be rebuildable.

However, this multi-support can lead to delicate situations in the context of shared libraries (when using GNU/Linux distros package dependencies, or when using ms windows .dll's). For example, if your new 2.0 game links against libSDL_gfx.2.0.23.so.0, it will not be able to know whether SDL_gfx is itself linked against SDL 1.2 or SDL 2.0, especially if SDL_gfx is provided by the distro and not compiled by you.

Rewrite

Backward-compatibility

There are good chances that your current 1.2 code will directly compile under 2.0. Check include/SDL_compat.h and SDL/src/SDL_compat.c to get an idea.

Your code will probably run slower though; in particular there will be no hardware surfaces.

Compatibility is not 100% correct though; for instance SDL_SetPalette flags are currently ignored.

Forward-compatibility

You may want to support both libraries, for instance because SDL 1.2 is currently better supported on your platform, or better packaged in GNU/Linux distros.

The AlienBlaster code, in the Android port repository, uses a few additional functions on top of SDL, that will use either SDL 1.2 or 2.0 seemlessly, and minimise the amount of #ifdef. It's not completely fool-proof though, for instance blits between hardware surfaces will result in a no-op under 2.0. Check the C++ code at: