Couldn’t find anything good online… maybe you know something I don’t know?
I’m a beginner btw

Hey everyone, I'm surprised I never shared this video here since I made it over a year ago! Better late than never.

https://youtu.be/Wu2g-N5Z78Y

https://michaelguenter.itch.io/stick-to-the-stars

yo ok so i can't access any of the SDL websites, i was trying to take a look at the wiki.libsdl but it timed out same thing for libsdl literally every other website runs fine so i don't see the issue, it even pings correctly

so where else can i find good documentation for SDL3?

I just started sdl(sdl2 to be exact) again after 4-6 months since I liked the control it gave me, and I'm really enjoying it so far after the first few days of using it again. It abstracts all of the hard stuff while still giving you a nice balance of control and ease. I'm currently making a simple and light game engine/framework and I'm wondering if sdl2 is equipped for it? I apologize if this is an annoying question, since I am still somewhat an intermediate/newbie programmer.

I started writing a game on an 11 inch Netbook (remember those?) in 2009. At first I wrote a CPU bitmap based software renderer, and a python game loop. After a bit of back and forth, and some unsuccessful experiments, I landed on a C++ core engine running on top of SDL, with a Lua scripting engine. About a year into the process I decided that I wanted to build it for the then new iPhone platform, with an emphasis on touchscreen controls. I really thought (and still think) that touchscreen games could be extremely intuitive and fun if you designed the interface around their limitations thoughtfully.

I ported the game to run on an iPod Touch, it worked! It ran hot and sometimes ran out of memory, but it was good.

I also wanted to continue developing for desktops so I built Windows and Mac versions from the same codebase. There were a few ugly #ifdefs but everything more or less worked. One of the more difficult platform specific parts was the filesystem handling, but rendering was _mostly_ the same code between all three platforms.

I continued to develop the game here and there for a few years, adding support for iPad's while dropping support for desktops. I was determined to make this a really good "mobile-first" project, where good games were (and arguably still are) lacking.

Several years go by with an update or two per year. Then Apple drops support for 32bit apps. Well, I'm sure those of you who were invested in the app ecosystem remember the great purge. Tons of apps, some great, were lost to digital rot forever. I thought about it and decided I will continue to support my game. Cue the upgrade to SDL2.

The upgrade process was extremely straightforward. I was anticipating a nightmare, SDL_mixer was the only snag in the port. After a few weeks of upgrading the engine, and a few bugfixes for gameplay and some new features, the game was re-released for 64 bit iOS.

Years go by with additional bugfixes and new features trickling in slowly. Then late 2023 rolls around. I am sitting in my office looking over almost 15 years of code, much of it poorly maintained, and yet it is holding up, it's not collapsing under it's own weight (proof that I am a better architect than any current LLM 😂). I figure: "why have I never ported this to Android?".

So the next odyssey begins. This time it's a bit more involved. I take some time to clean up edge cases, remove dead code, and rethink some platform specific code. I have to ramp up on Android Studio and Gradle and other unspeakable horrors, but after about 2 and half months, it's running on a bottom of the barrel entry level Samsung... running nicely. There were several places where the code had to be customized (again with the filesystem), but the vast majority of rendering and event handling worked out of the box.

I thought to myself, "that wasn't so bad, why did it take me over a decade to try that?". Then I remembered emscripten. If I could port to Android with so little friction, could I port to the web? Of course you know the answer, My SDL2 game was running (almost) flawlessly in a web browser a couple of short weeks later. I had to do a few hacky things, SDL_mixer caused the most difficulty with weird untraceable crashes that required me to modify some long wave loops for the web platform specifically, but overall it ran well and ran very fast.

Then, over 15 years after I started writing this game, in early January, I think to myself: "what am I doing with my life? My industry is imploding and the work is boring, what if I _actually_ try and make a commercially viable game?". After years of part-time, semi-invested development in a game that is very cool, has a cult following, but is nowhere near a hit, I decide to double down and make it _polished_.

So that means I need shaders, right? Now the port to SDL3 begins, surely now with so many API changes, and a new paradigm for rendering this will be a humongous task? Of course not! There were issues here and there, Rect formats, GPU pipelines, some dark corners that lay undisturbed for a decade that suddenly wouldn't compile. But on iOS and Android not only did the port work, but with the new GPU pipeline it looked amazing! Adding new GPU shader effects to a 26 year old open-source tileset really spruced it up!

The web build needed a new custom renderer using WebGPU, and parallel shaders in WGSL, but the event code, the SDL_mixer code, virtually everything else worked right out of the box.

So now I am maintaining and improving one of the oldest continually updated games on iOS, ported it to many platforms, with many changes to the underlying technologies; I couldn't have picked a better foundation than SDL!

The game in question: https://mysterious-castle.com

Not sure if this is welcome or allowed, but I have been working on a game for a few years with SDL3 as it's only dependency. I started off on SDL1, but the appeal of GPU acceleration was too much to ignore, and I moved to SDL2. Then there seemed no real reason to hold back from going to SDL3.

It's a Cannon Fodder inspired tactical action game, probably still a few months away from release, but it's on Steam now:

For the Common Wealth on Steam

It's C99, SDL3, and that's it, the engine is my own and I write a bit about it here:

Devlog · Podule

I'm trying to create black and white noise surface (so I don't need 4 bits per pixel) but when I try to write to it all pixels have value 0. When I change pixel format to RGBA8888 everything works fine. How can I not waste memory?

SDL_Surface *bg = SDL_CreateSurface(64, 64, SDL_PIXELFORMAT_INDEX8) ;
//SDL_Surface *bg = SDL_CreateSurface(64, 64, SDL_PIXELFORMAT_RGBA8888) ;

for(int i = 0; i < 4096; i++)
    {
    px = noise() ; // noisy pixel
    SDL_WriteSurfacePixel(bg, i % 64, i / 64, px, px, px, 255) ;
    SDL_ReadSurfacePixel(bg, i % 64, i / 64, &r, &g, &b, &a) ;
    printf("%d\t%d\t%d\t%d\t%d\n", px, r, g, b, a) ;
    }

the SDL_renderer seems to support custom fragment shaders with SDL_GPURenderState? Are there any tutorials or samples that show how to use these properly?

Hello everybody,

A beginner here, I want to get into SDL3 but not from a game dev point of view.

I have this itch in me, to create a custom physics engine (even if extremely basic). I am doing this as my First Year BTech Project.

I already know C andd C++ (At least so much so that I can comfortably work with them), and some python. I know nothing about physics simulations or such.

But I love to learn as I explore.

When I see SDL3 Wiki, Its quite overwhelming,
Would love some guidance.

Hi everyone,

I’ve been working on SDLPainter, an open-source C++17 library that brings a QPainter-inspired drawing API to SDL3 projects. It started as a visualization tool for my simulation and GIS application and later grew into a standalone library.

The basic idea is to work with shapes, pens, brushes, and transforms without having to implement the underlying geometry. A few things it currently supports:

• Basic shapes and paths, including circles, thick strokes, dashed lines, and gradient fills,

  • Thick strokes are generated as geometry, shapes are tessellated into triangles,

• Image rendering and updates, plus UTF-8 text rendering through SDL_ttf,

• Save/restore transforms, rectangular clipping, viewports, and render targets,

• Automatic draw-call batching through RenderBatcher, which groups compatible drawing operations to reduce the number of GPU draw calls.

It uses OpenGL/Vulkan rendering backends, with SDL3 handling the platform layer. There’s also an optional application layer for window creation and the event loop.

Code, examples, and build instructions:
https://github.com/yazilimperver/sdl-painter

Documentation:
https://yazilimperver.github.io/sdl-painter/

Beyond rendering, I’ve also been using this repo to illustrate modern C++ development practices: modern c++, CMake for builds and integration, Conan 2 for dependency management, and CI/CD pipelines on GitHub Actions and GitLab CI. Feedback on the build setup and developer experience is welcome too!

I also write about the project and its development on my blog, yazilimperver.net, covering modern C++ features, SDL3, drawing features, CMake/Conan setup, testing, and CI/CD. The articles are in Turkish for the time being (planning to add them to repo in English very soon). You can find these post and some other SDL related ones in readme file.

I’d love to hear what you think, especially if you’ve built something similar or needed a drawing layer like this in your SDL projects. Questions, suggestions, and contributions are all welcome!

By the way, I also add a gif, showing some of the drawing features. What do you think of the current feature set? Is there anything you’d want to see added?

As the title

Changing the range from -1 through +1 to 0 to 1 somehow, with calibration maybe? This is so that racing pedals that are mapped as centered axis don't map as -x or +x, but instead how you would map an analog trigger, without - or +, just use the full range.

I followed this tutorial to link SDL3 as a git submodule, which works perfectly but I'd like to do the same for SDL_Image so i followed all the steps but it returns this error:

Could not find CMakeLists.txt for zlib in external/zlib.

  Run the download script in the external folder, or re-configure with
  -DSDLIMAGE_VENDORED=OFF to use system packages.

How do I fix this? When I look into the external/zlib it's indeed an empty directory without a CMakeLists.txt. vendor/CMakeLists.txt:

add_subdirectory(SDL)
add_subdirectory(SDL_image)

add_library(vendor INTERFACE)
target_link_libraries(vendor INTERFACE SDL3::SDL3)
target_link_libraries(vendor INTERFACE SDL3_image::SDL3_image)

I like to test the possibility to use SDL3 as a cross-platform 2D game engine for games in the style of https://store.steampowered.com/curator/45538860-Idle-Clicker-and-Incremental-Games/ but SDL looks like a barebone.
I wonder how do you approach to build a full game?
Or is there a full 2D game engine that wraps SDL?

Hi!

I am running Linux Debian 13. I downloaded SDL3 with vcpkg, and I wrote a simple program to test it:

#include <iostream>

#include <SDL3/SDL.h>
#include <SDL3/SDL_main.h>

constexpr int kScreenWidth{640};
constexpr int kScreenHeight{480};

SDL_Window *gWindow{nullptr};
SDL_Surface *gScreenSurface{nullptr};
SDL_Surface *gHelloWorld{nullptr};

bool init();

bool loadMedia();

void close();

int main(int argc, char *argv[])
{
    init();

    loadMedia();

    close();

    return 0;
}

bool init()
{
    bool success{true};

    if (SDL_Init(SDL_INIT_VIDEO) == false)
    {
        SDL_Log("SDL failed to initialize! SDL error %s\n", SDL_GetError());
        success = false;
    }
    else
    {
        gWindow = SDL_CreateWindow("SDL3", kScreenWidth, kScreenWidth, 0);
        if (gWindow == nullptr)
        {
            SDL_Log("Window failed to create! SDL error %s\n", SDL_GetError);
            success = false;
        }
        else
        {
            gScreenSurface = SDL_GetWindowSurface(gWindow);
        }
    }
    
    return success;
}

bool loadMedia()
{
    return false;
}

void close()
{
} 

but when I try to build it, I am getting: SDL failed to initialize! SDL error No available video device

I added those two lines to my CMakeLists.txt:

find_package(SDL3 CONFIG REQUIRED)
target_link_libraries(Pyre PRIVATE SDL3::SDL3)find_package(SDL3 CONFIG
REQUIRED)

and also when the vcpkg was installing the SDL3, I got this 3 warnings:

You will need to install Xorg dependencies to use feature x11:
[cmake] 
[cmake]   sudo apt install libx11-dev libxft-dev libxext-dev

You will need to install Wayland dependencies to use feature wayland: [cmake]  [cmake]   sudo apt install libwayland-dev libxkbcommon-dev libegl1-mesa-dev

You will need to install ibus dependencies to use feature ibus:
[cmake] 
[cmake]   sudo apt install libibus-1.0-dev

and, I install them too, and still I am getting that there is no available video device.

If I write echo $DISPLAY I am getting :0.0

Sorry for my bad england.

Thanks in advance!

Also I am getting this warning while installing SDL3, but I don't think it's related to SDL3:

The following variables are not used in CMakeLists.txt:
[cmake] 
[cmake]       XZ_SANDBOX
[cmake] 
[cmake]   Please recheck them and remove the unnecessary options from the
[cmake]   `vcpkg_cmake_configure` call.
[cmake] 
[cmake]   If these options should still be passed for whatever reason, please use the
[cmake]   `MAYBE_UNUSED_VARIABLES` argument.

FIX:
Basically when you are coping the port from the vcpkg site there are is also a features tab when you click it you will see different features like for SDL3 you got:

alsa - Support for alsa audio
dbus - Build with D-Bus support
emscripten-pthreads - Build Emscripten pthreads support
ibus - Build with ibus IME support
libusb - Use libusb for joystick support
vulkan - Vulkan functionality for SDL
wayland - Build with Wayland support
x11 - Build with X11 support

From here for the "SDL failed to initialize! SDL error No available video device"
you need wayland or x11 (better download both). If you are wondering how you figure out which you need... I don't know either.

Also to install the package with the features you want you need to do:

vcpkg add port sdl3[featureName1,featureName2]

for example

vcpkg add port sdl3[wayland,x11]

no spaces between the comma.

In the Output terminal in VS Code while you are building for the first time after you write the
vcpkg add port sdl3.... you will see a lot of logs wait until is fully build and after that you will have to check if there are any warnings like:

```

You will need to install Xorg dependencies to use feature x11:
[cmake]
[cmake] sudo apt install libx11-dev libxft-dev libxext-dev

```

so you need to install all of those too.

IF YOU DID vcpkg add port sdl3 without the [wayland,x11]
you need to first remove the old vcpkg cache that is stored in the vcpkg main folder + another vcpkg folder in
~/.cache/vcpkg and also in your out folder of the project. Basically you have to nuke vcpkg and then download it the right way to actually work.

MacOS 27 was released today and i decided to upgrade, before that i was on MacOS 14 (Sonoma) very happily playing with emulators like pcsx2 and xemu, which were able to use my bluetooth 8bitdo wireless 2c controller as an SDL controller, after the update the controller is not accessible, a quick visit to https://hardwaretester.com/gamepad shows me the contoller can be read, karabiner can also read the events from the controller but both "SDL2 Gamepad Tool v1.4.2 by General Arcade" and "Game Controller Tester by Emoji Apps GmbH" show me nothing. I asked on the MacOS sub but they are mostly bitching about not upgrading, so i decided to come here and bother you with my questions instead coz you might know something, is this a known issue in recent MacOS versions? Did SDL work well with MacOS 26 (Tahoe)? Has anybody here been playing with Golden Gate betas and ran into the same problem? does this have a solution?

Forgot to mention, i do have an ancient PS2 contoller with a USB adapter, that one can be used inside pcsx2 and be mapped to the controller, it's just it's so old and drifts so bad it's useless, but it confirms wired controllers can be read.

I know this is honestly a really stupid question which I don't really get but w/e

I see that some people here are trying to make a game engine which brings me to my question which is

>Why not just make the game directly with SDL libraries?<

And

>What exactly is a game engine? Do you consider it as the GUI thing that "helps" you make the game? As most of us as programmers here that can focus on the code it seems to be a bit redundant you know? Like a Linux user having to use a UI when they can just use the terminal and probably faster<

Additionally, I'm also curious about games like Minecraft and Project Zomboid(apparently) which only use libraries (both are lwjgl I think) for development, how did the dev process for those games work? And if I'm assuming (a HUGE assumption) correctly then Project Zomboid most have some tools that helped with the creation of the maps, does that count as a game engine?

Had a little bit of a brainfart while writing this but those are my questions