I'm starting to study game development but the concepts of how the SDL2 lib works are still a bit blurry to me.

I get that both Direct3D and OpenGL are two sides of the same coin. They both are used to draw vectors in the screen and are used as a graphics hardware abstraction layer.

From what I read about the SDL2 lib it seems to be a multi-purpose library that encapsulates some functionalities as user input, threading, networking, window creation, and so on [and also "graphics hardware via OpenGL and Direct3D"].

Now the questions:

  1. The SDL2 webpage states that it provides access to "graphics hardware via OpenGL and Direct3D". What exactly that means?
  2. If I'm making a 3D game do I need to decide beforehand which graphics API I want to use (Direct3D or OpenGL) and use it alongside with the SDL2? If not, does SDL2 completely encapsulates the graphics API so I could easily deploy my game targeting Direct3D or OpenGL without adapting too much code for each one?
  3. In the case SDL2 does not completely abstract the graphics API, what texts and terms should I search to learn how to implement such an abstraction layer using SDL2? I want to be able to easily build for Direct3D and OpenGL.

Thanks very much!

  • \$\begingroup\$ Does this (perhaps partially?) answer your question? gamedev.stackexchange.com/q/29692/35344 \$\endgroup\$
    – user35344
    Commented Oct 28, 2020 at 8:19
  • \$\begingroup\$ @Tyyppi_77 I have read that link already. It kinda answers some of my questions but it is from almost 10 years ago. As SDL seemed to change a lot in this time span I decided to create this question to have more updated answers. \$\endgroup\$ Commented Oct 28, 2020 at 8:23
  • \$\begingroup\$ There are some ambiguity around this SDL capability to encapsulate the graphics API too, some texts states SDL is meant to be used alongside a specific chosen target (Direct3D or OpenGL) and yet others suggests SDL could completely encapsulate the graphics API. \$\endgroup\$ Commented Oct 28, 2020 at 8:25

2 Answers 2


SDL is a library which hides the graphics API behind a more convenient abstraction layer.

When you want to draw a sprite using the SDL library, you would call the function SDL_RenderCopy(renderer, texture, srcRect, dstRect);.

This function will then internally call the respective function of the graphics API to accomplish this. Which function of which API? That depends on the platform you are compiling your game for. When you compile for Windows, it will use Direct3D. When you compile for Linux, it will use OpenGL.

The purpose of using a library like SDL is that you no longer need to care about what graphics API is used by your game, which target platforms support which APIs and what the unique peculiarities of those APIs are. SDL hides all this behind one unified API.

However, the SDL graphics functions only do 2d graphics. When you want 3d graphics, then SDL doesn't give you much for that. So you will have to find a different solution for putting your 3d models onto the screen. But there is still some functionality of the SDL library besides graphics which can be useful for a 3d game which doesn't do its rendering through SDL:

  • Loading and parsing asset files
  • Audio playback (although the SDL audio API is rather spartanic in this regard)
  • Input handling
  • Filesystem abstraction
  • \$\begingroup\$ Hmmm very interesting. So I can develop a complete 3D game calling only generic SDL functions and not specific Direct3D or OpenGL APIs? I read somewhere that would only be true if developing a 2D application; that when 3D comes to play one would need to specifically calls SDL's D3D or OpenGL interfaces. \$\endgroup\$ Commented Oct 28, 2020 at 9:21
  • \$\begingroup\$ @underthevoid The SDL graphics functions only do 2d graphics. When you want 3d graphics, then SDL doesn't give you much for that. You can still use SDL for asset file loading, audio and input, though. \$\endgroup\$
    – Philipp
    Commented Oct 28, 2020 at 9:24
  • \$\begingroup\$ I see... So in order to develop a 3D game I would need to specific use D3D or OpenGL functions, right? If I got it right, isn't there any project that encapsulate the most popular backends? It seems to be such a big decision that would impact directly in the development design/architecture. \$\endgroup\$ Commented Oct 28, 2020 at 9:36
  • \$\begingroup\$ @underthevoid When you want to create a 3d game without having to worry about graphic APIs, then I would recommend to use a game engine like Unity, Unreal or Godot. But we generally don't do technology recommendations on this website. \$\endgroup\$
    – Philipp
    Commented Oct 28, 2020 at 9:39
  • 1
    \$\begingroup\$ @underthevoid For what it's worth, I think BGFX is a fairly popular project that encapsulates a lot of rendering backends and platforms under a single API. \$\endgroup\$
    – user35344
    Commented Oct 28, 2020 at 9:50

You still need to use the actual API.

For OpenGL, SDL will handle the platform-specific parts, so for most use cases that involves creating a window, creating an OpenGL context, and issuing SwapBuffers calls. Once you have an OpenGL context up and running you just use the regular OpenGL API as normal.

SDL 1.2 documentation for OpenGL is here: https://www.libsdl.org/release/SDL-1.2.15/docs/html/guidevideoopengl.html

Apart from initialisation, using OpenGL within SDL is the same as using OpenGL with any other API.

For Direct3D there is no encapsulated initialization, so instead you must create your window using SDL, retrieve it's window handle, then initialize and use Direct3D as normal via standard Direct3D API calls.

  • \$\begingroup\$ I see. So if I want the graphic API to be encapsulated I would need to implement a lib myself? Do you know if such a project already exists as open source? Thank you very much for the answer! \$\endgroup\$ Commented Oct 28, 2020 at 8:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .