SDL 1.2.15 versus SDL 2.x

[lmemsm]

Does anyone know if most of the Puppy derivatives/projects have switched to SDL version 2 or if they're still using the older SDL 1.2.15?

I'm looking into updating some programs that used SDL 1.2.15 so they'll work with SDL version 2. I'm also investigating backporting some of the SDL 2 library functionality (like svg support from sdl2_image or better Unicode support from sdl2_ttf) to SDL libraries that work with SDL 1.2.15.

Would be curious to hear which way projects are going. Are they continuing to use SDL 1.2.15 or upgrading to SDL 2 or supporting both? Does anyone have a pressing reason to continue using SDL 1.2.15 over SDL 2 (such as memory concerns, need for Linux framebuffer support, etc.)?

Thanks.

[jamesbond]

I think the answer depends on the application projects themselves, not Puppy.

- qemu has moved to SDL2, after a few years of co-existence (I held onto SDL1 until they finally gave it up).
- dosbox still uses SDL1

Fatdog carries both SDL1 and SDL2 in its base.

I'm also investigating backporting some of the SDL 2 library functionality (like svg support from sdl2_image or better Unicode support from sdl2_ttf) to SDL libraries that work with SDL 1.2.15.

This is fun but other than your own program, I doubt that existing SDL1 programs will ever be updated to make use of those interesting features.

[lmemsm]

This is fun but other than your own program, I doubt that existing SDL1 programs will ever be updated to make use of those interesting features.

Actually, it works fine with any program that can use the new features. For instance, when I backported SDL2_image to sdl, the SDL based graphics programs I use (like picaxo) can now display svg format. No code changes were needed to picaxo for the change.

[technosaurus]

The biggest difference for SDL2 is that the new more permissive license allows static builds. With musl libc and tinyx, that allows you to build apps with no dependencies that are sometimes smaller than the shared lib versions with dynamic gnu libc and xlib. This is because the compiler and linker can better optimize and remove more code.

GNU licenses are not free licenses - they restrict what you can do with them in many ways - static builds are just one. As far as I am concerned, SDL is dead, long live SDL2.

[lmemsm]

The biggest difference for SDL2 is that the new more permissive license allows static builds. With musl libc and tinyx, that allows you to build apps with no dependencies that are sometimes smaller than the shared lib versions with dynamic gnu libc and xlib. This is because the compiler and linker can better optimize and remove more code.

GNU licenses are not free licenses - they restrict what you can do with them in many ways - static builds are just one. As far as I am concerned, SDL is dead, long live SDL2.

I like the new SDL 2 licenses better as well. That's one of the reasons I'm trying to port some of the older SDL 1.2.x software I use to SDL 2.

Do you have a pointer to the tinyx code you referenced? I've seen several different versions of X that are supposed to be more lightweight than standard X. Which one are you using?

Have you tried building SDL programs with DirectFB or nano-x backends? They don't require you to have X Windows on your system. SDL 1.2.15 had good support for Linux framebuffer as well, but SDL 2.x doesn't have that option.

[technosaurus]

Have you tried building SDL programs with DirectFB or nano-x backends? They don't require you to have X Windows on your system. SDL 1.2.15 had good support for Linux framebuffer as well, but SDL 2.x doesn't have that option.

I used to maintain a fork of SDL2 for the linux framebuffer, until the kmsdrm backend became stable - it can run on the console with optional EGL acceleration.

For tinyX I use idunham's and dimkr's (iguleder) forks from github or my own alternative method that implements the X protocol in a more direct way using C99. I think Kim (goingnuts) may have more thorough versions of the tinyx stuff, but I don't think its on github.

[lmemsm]

I used to maintain a fork of SDL2 for the linux framebuffer, until the kmsdrm backend became stable - it can run on the console with optional EGL acceleration.

For tinyX I use idunham's and dimkr's (iguleder) forks from github or my own alternative method that implements the X protocol in a more direct way using C99. I think Kim (goingnuts) may have more thorough versions of the tinyx stuff, but I don't think its on github.

Have you tried TinyCore Linux's TinyX ( https://github.com/tinycorelinux/tinyx )? Anyone have a comparison between it and the tinyX forks by idunham and/or dimkr?

Do you have any tips on how you built/setup SDL2 for kmsdrm? I'd really like to give that a try. Will it work on a standard desktop system (with VESA but no SVGA support) or do you need to run it on a device like a Raspberry Pie that has EGL support to get decent results. Appreciate any help or suggestions you can offer on this. Would really like to eliminate X or downsize it on my system.