Results of GSoC project: SDL2 transition
Moderator: Forum Moderators
Results of GSoC project: SDL2 transition
Hi Wesnothians,
As you might or might not know I have spent the summer working on a GSoC project for Wesnoth. I was appointed with the task of porting parts of Wesnoth's code to the new SDL release, 2.0. More precisely, I was working on implementing hardware accelerated rendering. Unfortunately, a few weeks into the project we (I and my wise mentor mordante) concluded that SDL2 isn't good enough for our needs. So we looked for something better and decided to switch to SDL_gpu, a rather new, but promising SDL extension library.
So as things stand now, large portions of Wesnoth has converted to use hardware rendering through SDL_gpu. As of now, SDL_gpu support is absolutely experimental and optional. There's also quite some functionality still missing in this port. What we have is a working game display, panels and some GUI1 widgets. The rendering engine is not yet optimized so SDL_gpu builds are actually slower than the default one, obviously we expect that to change in the future.
So how you can see SDL_gpu in action (instructions for Linux):
1) Checkout the master branch.
2) Configure with cmake -DENABLE_SDL_GPU=1 . (scons is not yet supported). There's a strange (apparently compiler) bug that occasionally triggers a false unused variable warning in SDL_gpu's code, so you might also need to pass -DENABLE_STRICT=0 as well.
3) Build as normal (make)
4) Ready to go! The main screen isn't yet converted, though, so if you want to see something other than a black screen you'll need to boot into a campaign or scenario from the command line.
Again, this branch is absolutely unsuitable for playing. I just made this post to keep you updated about the project, it's not meant as a call for testers.
As you might or might not know I have spent the summer working on a GSoC project for Wesnoth. I was appointed with the task of porting parts of Wesnoth's code to the new SDL release, 2.0. More precisely, I was working on implementing hardware accelerated rendering. Unfortunately, a few weeks into the project we (I and my wise mentor mordante) concluded that SDL2 isn't good enough for our needs. So we looked for something better and decided to switch to SDL_gpu, a rather new, but promising SDL extension library.
So as things stand now, large portions of Wesnoth has converted to use hardware rendering through SDL_gpu. As of now, SDL_gpu support is absolutely experimental and optional. There's also quite some functionality still missing in this port. What we have is a working game display, panels and some GUI1 widgets. The rendering engine is not yet optimized so SDL_gpu builds are actually slower than the default one, obviously we expect that to change in the future.
So how you can see SDL_gpu in action (instructions for Linux):
1) Checkout the master branch.
2) Configure with cmake -DENABLE_SDL_GPU=1 . (scons is not yet supported). There's a strange (apparently compiler) bug that occasionally triggers a false unused variable warning in SDL_gpu's code, so you might also need to pass -DENABLE_STRICT=0 as well.
3) Build as normal (make)
4) Ready to go! The main screen isn't yet converted, though, so if you want to see something other than a black screen you'll need to boot into a campaign or scenario from the command line.
Again, this branch is absolutely unsuitable for playing. I just made this post to keep you updated about the project, it's not meant as a call for testers.
Re: Results of GSoC project: SDL2 transition
For me the most problems in OpenGL games (and hence in all libraries that promise to bring hardware acceleration including SDL2 and SDL_gpu) come from the hardware itself. It is quite hard to adapt to all bugs and incompatibilities that these GPUs and their drivers exhibit, so any attempt to go the GPU way should be linked to some kind of GPU bug/support database, tool for dump used OpenGL API to track version compatibility and some kind of compatibility layer for debug, such as https://github.com/p3/regal which greatly helps in debugging all this stuff.