Thin "framework" for cross-platform SDL

SDL Development
1

I am considering adopting SDL2 as a framework to port some existing C++ 2d iOS and Android games.

The games were created in the Marmalade system, which is a bit like SDL, but more heavyweight.

My impression is that a bit of work needs to be done go from SDL out-of-the-box to a system that’s ready for game-specific code. Things like:

  • Setting up projects/solutions for Windows (where I’d like to do must of the development), iOS/macOS, Android.

  • Integrating the sound mixer library.

  • Creating a system for drawing sprites from multiple sprite sheet textures.

In short, I could start with SDL out of the box, but I’m hoping someone (LazyFoo?) has put together some starter code/projects that handle some of these things. What I’d like is a “Hello World” 2D game that just plain builds and runs as-is on Windows, iOS/MacOs, and Android, and does some basic game functionality like moving a bunch of sprites (taken from multiple sprite sheet textures) around on the screen while playing some sound effects and a background music loop. I imagine this is something that a huge percentage of people want SDL to do right away, and as I say my impression is that it takes a bit of work to get it there? (If I’m wrong, please let me know.)

Also I want to clarify that I am not looking for a 2d “game engine” like cocos2dx or the Rose system I saw a post about here. I don’t want a scene graph or animation system or any of that higher level stuff. (And similarly I can get networking from curl, and database from sqlite, etc.). I just want to a bare bones graphics/sound system where I can start writing low-level game-specific code in C++, ideally without having to do a lot of boiler plate setup.

Thanks.

2

You are correct that SDL is somewhat hands off in setting up a native
build environment for each platform. While SDL does come with various
native projects to build SDL itself, they are not necessarily geared
towards providing a way to manage all the other libraries you might
use nor help you manage all the separate platform projects.

So, that said, I have been developing Blurrr SDK, which seems to be
exactly what you described. It is a modular, decoupled SDK which
contains prebuilt libraries for SDL and some of the satellites, and
other useful libraries. (It also comes with libcurl.) Blurrr will
eventually provide some add-in libraries for features (e.g. particle
library, Zeroconf service discovery, etc.), but Blurrr does not force
opt-in. You can control which libraries you want to use and which you
don’t. And Blurrr tries to avoid hard framework/API coupling where you
are forced into designing your entire app in a certain way (such as
with the “engines” and “scene graphs” you expressed you didn’t want).

Blurrr contains a cross-platform build system built on CMake which
allows you to specify a singular & central build description, and
Blurrr will generate ready-to-go native projects for you for each
platform (Visual Studio, Xcode, Android Studio, Makefiles). Dynamic
libraries and your game resources are part of this system, so Blurrr
will package up everything correctly for you following each system’s
conventions so you don’t have to micro-manage this yourself.

I ship a few examples, but since this is all based on direct SDL and
friends, any SDL tutorial is still relevant. My examples do contain
what I consider some best practices for cross-platform though (e.g.
how to deal with where to put cross-platform assets, how to deal with
different screen sizes and aspect ratios, etc.). SDL traditionally
comes from a desktop heritage, and

Please check out Blurrr at:
https://blurrrsdk.com
It is free to try.

There are some videos you will find there.
Part 3 of the Blurrr SDK Quick Introduction shows the native
cross-platform project generation stuff.

This is not on the site (yet), but I just made this to help somebody
else on this list the other day. It contains a close/slow look on
getting Android Studio going.

Thanks,
Eric

3

Thanks for the detailed reply. Sounds like Blurrr might be just what I was hoping for. I’ll be happy to give it a try, and also to report on my experience.

The licensing terms are not clear on the website. Are you planning for it always to be free to use?

4

My plan is to keep the free unlimited trial and free for
non-commercial use. But I need to fund it, so I’m still trying to find
the right model. So for commercial use, there is currently a
introductory flat license model for $99 which should easily pay for
itself in saved time for any commercial situtation. The last two
companies I was involved with had subscription models, but I hated
that…it kept creating perverse incentives on our end to cripple
functionality that would be useful to users. I would love a donation
model, like Pateron, but I don’t believe that’s realistic right now.

Thanks,
Eric

5

$99 one time forever?

6

I think some GUI would be necessary, some games like RPG need GUI and some others too, like for a video dialog or such. And it’s not easy to write ones own from scratch. Please consider kiss_sdl https://github.com/actsl/kiss_sdl and the thread here Kiss_sdl - Simple universal GUI widget toolkit for SDL . Because it’s the smallest, yet generic. This GUI will never be other than some files added to the project, to give the user the ability to change it the way one wants. It is entirely made using SDL2, so like who knows the LazyFoo tutorials, knows how to change this. This is my principle of Principal GUI, which is an Immediate GUI, but goes further in that it is easily changeable and extendable, enabling the user to adopt the GUI to ones needs by changing it, yet it provides enough functionality for simple generic GUI that is enough for most users. This enables to make a very small GUI, with some 10 times less code than even in the small Immediate GUI-s. The smaller code is important because it is more easily understandable for the user, making it easier for the user to change it if necessary. But it is also made easily changeable by its structure, like with drawing and general functions abstracted away from the widget functions and with the principles of making even a very advanced GUI built in. When adding a simple GUI, your software may have an advantage which the other similar ones don’t have. Thank you for considering it.