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.
SDL 1.2.15 versus SDL 2.x
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.
- 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.
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.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.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
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.jamesbond wrote: 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.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.
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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
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.technosaurus wrote: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.
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.lmemsm wrote: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.
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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
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?technosaurus wrote: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.
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.