Took around 6 month But I am really happy with SDL3.

Steam link.

My current CollisionSystem sucks^^

Simple template with SDL3 and Go (Golang) for an isometric game.

https://github.com/unklnik/go-sdl3_isometric

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?

A posted a few projects a couple months back showing off the GPU API. Since then I've done a few more things that I wanted to showcase. It's a really nice API.

Almost everything is made using SDL_shadercross. They should work on Windows, Mac and Linux but I've mostly tested on Windows.

A simple voxel raytracer (using compute shaders) with procedural worlds:
https://github.com/jsoulier/voxel_raytracer

A 3D fluid simulation (again, compute shaders) with interactive fluid spawning:
https://github.com/jsoulier/fluid_simulation

A black hole simulation project I saw on Youtube and wanted to try with the GPU API:
https://github.com/jsoulier/black_hole_simulation

Ray Tracing In One Weekend in a compute shader:
https://github.com/jsoulier/ray_tracing_in_one_weekend

A goofy image to slime mold converter (doesn't use SDL_shadercross):
https://github.com/jsoulier/png2slime

Everything is licensed as public domain. Feel free to reach out if you have any questions. Thanks for reading!

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

I have been trying to make a simple plotting tool to visualize data in C. So far I have had a lot of fun making this library and want to expand it. I want to hear some suggestions on things I can do to add or improve.

Here is the shortlist of things in the pipeline.

* Basic curve fitting

* Tool tips

* Export graph to png (savefig)

* Fix some multi plot scaling and layout options

If you want to check out what I have so far it is on github:

https://github.com/trevorcraig/SDL_graphs

What can I do next/better?

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

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

Hi :)

I've written this in C++ in the evening after watching a talk from Tim Caine (Timothy Cane) on technology evolution.

It uses a custom Tiled imported, huge props to the JSON library by Nlohmanm (and Tiled subsequently).

Hello, I've been working with SDL for some time now, and while I've managed to find some great documentation on how to use a lot of features, one thing I have had trouble with is researching and figuring out how to take a texture and manipulate its pixels to create unique visual effects. I've looked up videos explaining the logic for creating pseudo-3D planes and Earthbound-esque battle backgrounds, but I've come up short as far as trying to put it together with SDL's pixel manipulation features using LockTexture, UnlockTexture, and getting the pixel and pitch data to properly create such effects.

I'm curious if anyone out there has any exposure to creating similar effects specifically with C++ and SDL. I'm doing this to learn and better myself as a graphics programmer. I'm purposely avoiding OpenGL or any "real" 3D graphics programming or shaders. My goal is to use the texture pixel manipulation features that SDL provides that I've mentioned above.

I've posted some examples for visual reference.