SDL2 Porting guide?

SDL Development
1

Hello!

So, long story short: I spent a lot of time thinking of a way to create GUI applications that could share code between devices. During the research, I ended up finding LittleVGL and someone even made a SDL2 port (albeit a little incomplete on the input side of things).

However, with this alone, I was able to run a LVGL example program on the Playstation Vita just fine with virtually no changes, other than splicing in the VitaSDK toolchain! Since then, I have been quite hyped, to be completely frank.

So, I went and have been looking for existing SDL2 ports, and I was surprised to find quite a few of them. There are some in the DevkitPRO repositories (Switch, Wii U), VitaSDK ships one by default and besides that, the existing SDL2 CMake is simple enough to read through to pick up what platforms are supported. In fact, big compliment on that CMake file; easily the least messy and most readable I have seen in quite a while.

But, out of curiosity: What would I need to do to port SDL2 to other platforms? For instance, take the PS3: It has a proprietary GPU API that the open-source ps3dev toolchain has but otherwise a lot of standard APIs (see github.com/ps3dev/PSL1GHT/blob/master/ppu/include/rsx/rsx.h, I can only post two links). So, how would I go about porting SDL2 to that - and, making sure that it does not interfere with the mainstream builds too much? Is there a “modular approach” that I can use to develop away without interrupting other ports, let alone the core, by just writing the required absractions/handlers?

So… yeah. I am curious and looking for a port, basically. If it’s not possible, that’s also fine. I was just hoping to not having to write a dozen of various LVGL drivers, but could instead implement a SDL2 port, that could potentially help others as well. Then again, if it was that easy someone would’ve already done it already, I guess… x)

Anyway! Thank you in advance and have a great day!

2

But, out of curiosity: What would I need to do to port SDL2 to other platforms? For instance, take the PS3:

I could have sworn someone did a homebrew PS3 port at some point, but I could be wrong.

I wrote this about porting SDL to new platforms: Port SDL 2.0 to BIOS - #2 by icculus

and, making sure that it does not interfere with the mainstream builds too much?

So we do this for the official console ports: we forked SDL into separate (private) repositories, did the various console ports there, and then as new SDL releases are done, we merge the main repo into the private ones. Since it’s git, it’s a literal merge: the two branches become one until more development is done instead of us manually gluing everything back together.

People with NDAs in place with the various console makers can be given access to the specific repositories they need. Each console port is in a separate repo, so if you just need, say, Switch and Stadia, you can get it without having to worry if you have a Sony NDA in place.

There are usually a handful of small places we have to resolve conflicts (there’s a list of #ifdefs for various audio drivers, inevitably one gets added in the new release to the same place the console’s driver is listed, etc), but overall, the merge isn’t difficult. At that point, we just have to implement new APIs that were added since the last merge, if it makes sense to do so.

And for the most part we try to keep the headers portable, so a project that has to target multiple consoles can just use the same public headers across all of them, even if they might need to build SDL from different forks for different targets, so they can theoretically compile for all their targets with the same headers and link a different, prebuilt SDL library for each platform.

3

Yes, someone most definitively did! :slight_smile:

$ find $PS3DEV -iname "SDL*" -type d
/usr/local/ps3dev/portlibs/ppu/include/SDL

I was just using it as an example.

I must admit, I am not all too versatile with git merge at all. But, this makes sense. And I bet the resulting merge conflicts should be minimal by this approach? i.e. platform specific initializers or other parts like the build scripts (CMake et cetera)?

I noticed that when I was reading through them and was looking at various bindings. Apart from the major version being 1.x or 2.x, API seems to have been consistent - which is really great!

I am mostly looking into homebrew development since I am just one dude fooling around with the possibilities and seing where it goes. Like using SDL as a means to load LVGL on many platforms and have a consistent GUI, for instance. So no NDA - or devkit - needed. But, should I ever have to, good to know those things. :slight_smile:

I’ll give this a read! I was considering to try and write a backend for LVGL based on EDK II to see if I could launch it in BIOS mode. One thing I wish there was, was a much prettier boot loader. GRUB gets the job done but looks… eh. ^^; I have been using rEFInd for most of the systems I installed multiple OSes on, but it’d be fun to see if there is potential for something more. But straight up SDL in the BIOS is gonna be a treat. Sounds overkill and if that doesn’t help me in understanding how SDL can be used/ported there, then I don’t know. I’d love to give porting SDL to the GBA a shot, for instance. Cute lil’ thing will probably not make it very far with that - but hey, it’d be fun even if it stayed a PoC forever.

Thank you for the information! Very much appreciated :slight_smile:

1 Like