The SDL2 transition

[Danfun64]

How is it going to affect Wesnoth's software renderer?

Is it going to be replaced with an opengl renderer? I hope not, since one of Wesnoth's strengths is its portability...

[Pentarctagon]

It was discussed on the mailing list actually.

[Danfun64]

Well, there goes support for the yeeloong 8101b (one of the few computers which is even close to being "free" hardware).

[iceiceice]

Hmm, so I can't tell you all the reasons why we are doing this, but for one, SDL 1 appears to have bugs with respect to window management. It often doesn't do full screen or other modes correctly on macs for instance, and also wesnoth currently doesn't work with tiling window managers, so none of our linux users can use Xmonad with wesnoth for instance. I think the upgrade is also expected to improve performance, I couldn't tell you any details though. (Mostly paraphrasing bugtracker and forum threads here...)

TBH I didn't know that there were any platforms that didn't have some software implementation of OpenGL -- even the Pandora supports both OpenGL and SDL (although for unrelated reasons it seems that we plan to stop distributing for the Pandora as well in v 1.14). As I understand, portability is not an issue for OpenGL, it is simply an API with a wide variety of implementations. Is there a good reason why the yeeloong 8101b doesn't have a vanilla software OpenGL implementation?

[Danfun64]

i'm not sure if it has a "vanilla software OpenGL implementation" or not, but if it does, it would be a lot slower than the software renderer you're using now...

[iceiceice]

I think maybe you should post on the SDL forums, and they can tell you why they think using OpenGL in SDL 2 was a good idea. Also they would probably know more than we do about what can be done to improve support on the Yeeloong. There's really only a tiny number of devs who actually know a lot about SDL and all that.

It doesn't seem reasonable to ask us to stay on SDL version 1 forever, given that it is not going to be developed further.

[Groggy_Dice]

One point that hasn't been explicitly stated in this thread, though, is that we apparently aren't transitioning to plain SDL2, but a fork/extension called SDL_gpu. I can't really add to that, since I don't touch the graphics code (or anything else C++). In fact, the developers who seem to be really involved with the transition are lipkab and mordante, not any of the ones who have replied in this thread.

Here are some excerpted comments related to this decision (and the renderer):

20140617 18:05:34< lipkab> My last hope is that this software renderer is an internal engine in SDL2, and we can still rely on OpenGL's software renderer instead.
20140617 18:08:26< lipkab> Yes, SDL2's color modulating algorithm is completely senseless and unusable.
20140617 18:12:09< lipkab> To be honest, I'm starting to think that moving SDL2 is a bad idea :/
20140617 18:38:53< lipkab> I'll look around in SDL's bug tracker to see if they're aware of this.
20140617 19:01:12< mordante> lipkab, I'm not sure whether we should stick with plain SDL2 or have a look at SDL2 + OGL or even stick with SDL 1.2
20140617 19:04:49< mordante> I expected SDL2 to be more mature
20140617 19:08:50< lipkab> I think I'll leave alone coding for a bit now and spend the next week exploring our options with SDL and OGL.
20140621 11:20:13< lipkab> As for SDL2, I asked some questions on their forums, but no really usable answers yet.
20140621 11:29:12< lipkab> (Unless a miracle happens and it turns out that SDL2 is not that bad at all)
20140626 18:43:46< lipkab> - In general, SDL2 tries to be as basic as possible, even at the cost of uselessness. They probably wouldn't even accept patches if we tried to fix SDL2 ourselves.
20140626 18:44:07< lipkab> Long story short, SDL2 is a no-go in my opinion.
20140626 18:52:05< lipkab> From a technical viewpoint, SDL_gpu seems superior to plain OGL.
20140626 18:53:39< lipkab> Ah, one more thing, SDL_gpu doesn't have a software renderer.
20140626 18:58:08< mordante> yeah I'm somewhat surprised how much seems to be missing in SDL2, still their reference list seems to include a lot of games
20140628 11:58:39< lipkab> When SDL_gpu is enabled software-rendering simply stops working.
20140628 11:59:25< lipkab> It was the same with SDL2's accelerated renderer, so I tend to believe that this can't be helped.
20140628 12:02:03< mordante> also agreed with the software rendering issue, I also believe SDL_gpu inherits it from SDL

[Danfun64]

I have contacted the author of sdl_gpu. He said that he is willing to implament a software renderer, but not for a while and not until he has more people working on the project.
https://code.google.com/p/sdl-gpu/issues/detail?id=2

[iceiceice]

So, like I originally suggested, I think you would get more mileage out of posting on yeelong 8101b boards.

https://www.opengl.org/discussion_board ... -Rendering

Does OpenGL contain software rendering libraries which will get automatically invoked in absence of hardware accelerator? What is the extent of functionalities which can be simulated in software this way? OR are there any third party libraries have to be used instead?

For GL 2.1 the software pipe is complete. For 3.0 I'm not sure either and for 3.1+ there isn't any. Mesa and connected drivers lag behind quite severely.

OpenGL itself specifies absolutely nothing about what is or is not hardware accelerated. Hardware vendors implement the OpenGL specification in their drivers and they decide.

Software replacement of OpenGL functionality is something that comes up fairly often, and it's a definite case of "be careful what you wish for". Your GPU plays a far greater role in this than I suspect people asking for it realise (remember: OpenGL itself does not actually draw anything - all it does is tell your driver to pass commands on to your GPU, which is where all the work really happens). OpenGL is not software and it is not a software library, and software replacement of rendering functionality may run as slow as less than 1 frame per second.

I have no idea what version of OpenGL is required by SDL_GPU, but if 2.1 is sufficient, and these alleged software implementations exist and can be compiled on your hardware, then that should be all you need. (This thread is also two years old so there may be something better than 2.1 available now.) There will of course be the usual caveats about software rendering being much slower, but it seems likely that for wesnoth you could expect at least comparable performance to the current implementation.

https://www.opengl.org/wiki/FAQ#What_pl ... have_GL.3F