Faster Graphics with OpenGL?

[Dave]

Looking at what other game projects do, it seems to me that the fastest portable way to do 2D graphics is to use OpenGL.

I'm wondering: would it be worth modifying Wesnoth to allow a compile-time option that would make it use OpenGL to render graphics instead of using SDL? SDL would still be supported, since some platforms might not have OpenGL support, but platforms that have OpenGL could use it.

For instance, SuperTux does this, and I believe it's substantially faster with OpenGL instead of SDL.

Doing this would likely require abstracting drawing routines behind an interface that can back-end onto either OpenGL or SDL. It'd be a reasonably large amount of work, but would be worth it if we could get a big speed increase, and would probably make our code better quality (more modularized) anyway.

As an added bonus, OpenGL contains very nice and fast scaling and rotation routines that we could use. (Of course, versions compiled without OpenGL would have to use our own inferior algorithms for this, or not support scaling).

Would anyone be interested in investigating the feasibility and benefits of this further? Or even implementing a sample? I've only programmed OpenGL a very little bit, so I don't know that much about it -- please let me know if there's anything I'm missing.

Just to avoid any confusion: this entire post has NOTHING to do with 3D graphics. OpenGL is a graphics library that has both 2D and 3D routines. The intent is only to use the 2D routines from the library. Please do NOT discuss anything about 3D graphics rendering in this thread. This is mainly a technical discussion. If you don't understand what this thread is about at all, then please don't post in it.

David

[Woodwizzle]

I think this would be a huge step forward for wesnoth as a game engine! Tough I'm not a dev, my experience has been opengl accelerated 2D games are usually very noticably accelerated. Improved scaling is one of many benefits More halo effects and better halo behaviour would be possible. For instance overlapping halos could have an additive graphical effect. Day/Night transitions would look much nicer etc.

Again, I'm not a dev, so I can't really help in that department, but I do know that this is one of the biggest Opengl resources online:
http://nehe.gamedev.net/

[silene]

I'm wondering: would it be worth modifying Wesnoth to allow a compile-time option that would make it use OpenGL to render graphics instead of using SDL? SDL would still be supported, since some platforms might not have OpenGL support, but platforms that have OpenGL could use it.

For instance, SuperTux does this, and I believe it's substantially faster with OpenGL instead of SDL.

Supertux has OpenGL support, but it is not enabled by default. And it is fortunate: once I enable it, the game goes from a steady 50 fps to an unusable 3 fps. OpenGL is fine when all the functions you use can be hardware-accelerated, but once there is a function that must be done in software, the program becomes unusable (the processor has to get the data back from video memory, utterly slow).

So, in addition to what you said, there is also a need to have SDL support, even on platforms that have OpenGL. For example, if the graphic card is not top of the line. Or if it is not completely supported by the OpenGL implementation. Or if the administrator disabled hardware rendering (since it allows for local root exploits).

"Funny" anecdote: Crack-attack (a game kind of like Tetris-attack that uses OpenGL to provide nice lighting effects) just got a "--really" option in its last version. Why? So that the user can run the game in "--really --low" quality (I'm not joking). No more lighting effect nor texture nor even score display, and it is still slow as hell...

But other than that, I don't mind if somebody does a refactoring of the graphic layer so that it allows to switch from a SDL support to an OpenGL support for those who can afford it. It may be a bit hard though, since we are actually quite clever in doing as few operations as possible: only parts of the display are updated. And I may remember incorrectly, but it seems to me this goes against the OpenGL way: full update of the whole display at each frame?

[Dave]

For instance overlapping halos could have an additive graphical effect.

Overlapping haloes already do have an additive graphical effect.

David

[DemonSax]

I don't know that it's really far to say that OpenGL is faster than SDL, since so much depends on a given system's graphics card, driver, bus speed, etc. As such I would not recommend adding OpenGL support merely in an effort to make Wesnoth faster.

However, OpenGL is certainly far more feature rich than SDL, and could go a long ways towards making Wesnoth a more 'powerful' engine, especially if you decided to add some of the cooler effects. So if you wanted to stretch you muscles adding OpenGL support would probably be good exercise and tends to look much better on a resume.

[xtifr]

I've found that on my system (Debian, G400), 2D GL can be a bit flakey. There are occasional minor problems with parts of the screen not getting refreshed properly. In general, I would say that the 3D features of OpenGL are much better tested and debugged than the 2D.

With X.org moving towards the use of GL, this will probably change. The drivers will almost certainly improve rapidly as GL is increasingly used for basic window decorations and whatnot. In the long term, I think moving Wesnoth to GL would be a great idea, but in the short term, I think it might be a mistake. :shrug:

[Invisible Philosopher]

And I may remember incorrectly, but it seems to me this goes against the OpenGL way: full update of the whole display at each frame?

That is the usual way, since it is both simple and for many games necessary, but it is quite possible to avoid doing that. Just don't clear the color buffer every frame. I don't know if it still sends the whole thing to the display every frame, but that should not be a terribly slow part of what it does, considering that it's the most used feature.

I've found that on my system (Debian, G400), 2D GL can be a bit flakey. There are occasional minor problems with parts of the screen not getting refreshed properly. In general, I would say that the 3D features of OpenGL are much better tested and debugged than the 2D.

I believe many of the 2D parts of OpenGL are (or can be) achieved through use of the 3D commands, with values like 1 or 0 as appropriate for the third dimension.

In the long term, I think moving Wesnoth to GL would be a great idea, but in the short term, I think it might be a mistake. :shrug:

The proposal was for an alternative, not a replacement, I believe. In theory it seems good. In practice the only slow Wesnoth graphics I have seen that have not turned out to be caused by bugs (yet!) are large halos (especially full-screen color adjusts and large [time_area]s that have a different time-color from the rest of the map). Also zooming in or out is incredibly ugly (it even was before the normal graphics were so good) and significantly slow to zoom even one step, although a decent speed once you're there.

[Dave]

In practice the only slow Wesnoth graphics I have seen

How about simply scrolling around the map? Few people seem to be able to get this happening at much above 20 fps, and on many seemingly reasonable setups, it can drop to 10 fps or less.

I think it'd be a nice improvement if Wesnoth could scroll around at 30+fps on modern machines.

David

[Invisible Philosopher]

How about simply scrolling around the map? Few people seem to be able to get this happening at much above 20 fps, and on many seemingly reasonable setups, it can drop to 10 fps or less.

I think it'd be a nice improvement if Wesnoth could scroll around at 30+fps on modern machines.

So true. The more it happens, the less I think of it.

[entropomorphic]

I think it's a great idea, especially since it could improve scaling and scrolling performance (and quality) a great deal. It might also be possible to add 3D elements incrementally in the future, like 3D terrain, castles, and villages. Nifty particle effects (currently implemented with prerendered halo animations) might be eaiser too.

Given SDL's ability to encapsulate OpenGL surfaces, you might even be able to migrate slowly to a GL engine. For example, you could render the game map in GL but still draw the GUI with SDL.

Whatever you decide to do, I'd suggest getting Wesnoth to 1.0 first before worrying about moving to OpenGL. As you said, it could require a reasonably large amount of work, and that kind of back-end migration tends to accumulate many complications, quickly. The performance limitations of the current engine are noticeable, but don't make the game unplayable even on older machines.

[entropomorphic]

Oops, sorry to bring up 3D rendering there. Couldn't help myself - was just throwing out ideas of other neat things you could do with an OpenGL backend. I guess if the plan is to support GL and SDL in parallel, we shouldn't be considering things you can't do well in plain SDL.

I think you should also allow compilation with both GL and SDL backends simultaneously, and add a selection in the Graphics prefs dialog to use one or the other. The reason for this is for binary distributions. Not everybody who's going to be playing it will have an accelerated OpenGL environment, so they would fall back to software MesaGL libraries, almost surely slower than just plain SDL. This way, you could run it fine by default, and (for people who had GL compiled in AND accellerated GL hardware) turn on GL rendering in the preferences for a nice speed-up. Hopefully, it would also prevent development from going in a direction where GL is the only playable backend, and the SDL version is too slow.

[elanthis]

It makes a lot more sense to me to instead modify SDL itself to use OpenGL for drawing as an option. Then Wesnoth could get accelerated 2D rendering with no modifications as would all other SDL-using games.

[freecraft]

Funny i was always thinking sdl is the best lib for 2d gfx.

However, if you are really up to increasing performances of the game, check out plib. I heared it has been used for some comercial games etc ...

Using OpenGL for 2d drawing sounds funny I have never tryed that

What about allegro

[grzywacz]

There's a project called glSDL out there, which implements SDL interface on top of OpenGL (a wrapper). It has some pitfalls, but still might be a better solution in terms of developement time compared to writing software/OGL backends for Wesnoth. The problem is - you have to patch SDL. Check it out:

http://icps.u-strasbg.fr/~marchesin/sdl/glsdl.html
http://icps.u-strasbg.fr/~marchesin/sdl/

And no, I haven't used it.

[Almindor]

OpenGL will most probably be faster if the user has a 3d card(99% of desktops nowadays because 2d with opengl is really easy for the cards so older ones are OK) and drivers (90% of windows users, 10% of unix users [I'm talking REAL drivers from the manufacturer not opensource ones]).

I'm a game developer(2d game too) and the problem of opengl vs pure SDL came to me too. I've mad an abstraction layer to provide possible switching between any backend(only 2d, doing 3d abstraction layer is a suicide). I've managed to get opengl working more or less but the fun ended when I needed to "recolorize" a sprite. In my case players can choose colours of their "heroes" and the single animations I have which are in one color already take 8 megs (on disk) so multiplying would be rather stupid. I decided to simply recolor them in memory before blit (as slow as it may sound the actual difference is not big). Doing something like this with openGL is virtualy impossible.(or SDL with hwsurface/hwaccel in windblows)

I'm pretty sure Wesnoth has many such cases of similar approach.