Wesnoth using OpenGL -- Request for Comments

[Dave]

I recently bought a new computer. While new, 3D commercial games run smoothly on it, Wesnoth runs embarassingly jerkily and slowly. I really don't think this is acceptable -- Wesnoth should run very smoothly on almost any computer made this millenium.

Further, simple features like zooming in run abominably slowly and look bad. Wesnoth runs an unreasonably large amount of memory.

I think this has to change. The reason things are like this is because we use SDL to do all our graphics, and that requires us to calculate all images in software. Further, because we support a wide range of different display settings, it's difficult for us to perform optimizations of image manipulation.

The way forward in my mind is to use the industry standard for real time graphics -- OpenGL. Almost all modern video cards support it. Any platform which one might expect to play any kind of decent game on should support OpenGL.

Now, a few platforms -- particularly older ones -- might not have good enough OpenGL support to play Wesnoth on. But, I don't think there are very many systems like that, and if there are, they probably can't play Wesnoth very well anyhow.

One problem is that on FLOSS platforms (GNU/Linux in particular), there is a lack of availability of Free accelerated drivers. However, I don't think this is a problem we can solve ourselves. If we want to make a modern, good quality game, we need to use the industry standard for graphics, and that is OpenGL.

If we don't use OpenGL, I think we are going to have a hard time adding all the graphical features we want to to Wesnoth. With OpenGL, we can make our current feature set run at a decent speed, and we can add new features (e.g. dynamic scaling and rotation of images, particle systems, lighting effects) that'll make the game look better and better.

Anyhow, the main purpose of this thread is to get feedback on what people think of using OpenGL. Which platforms are there that we'll use from using it? Which platforms are we sure has solid support for it?

I would like to note that I think an obvious response will be that we should support both SDL and OpenGL for rendering graphics. I think this option is an unrealistic fantasy -- the way to optimize SDL and OpenGL are completely different, and having to maintain support for SDL is a nightmare, as well as hindering future developments. (Note that I'm not suggesting getting rid of SDL altogether -- just rendering graphics using OpenGL. Image loading, event handling, input, music, sound, and so forth will still all be done by SDL).

I would also like to note that contrary to the misunderstanding of some people, OpenGL is a general graphics API for doing both 2D and 3D graphics. I am NOT suggesting making Wesnoth 3D. This thread has nothing to do with that. In fact, if you have no idea what OpenGL is, I suggest not posting in this thread.

Finally, this isn't all theoretical; I have a working (with some glitches) version of Wesnoth that uses OpenGL. On my particular system, this exhibits dramatic performance improvement over using SDL. And when I say dramatic, I mean that Wesnoth scrolls around the map at about 30 fps from the trunk, and scrolls around the map at over 100 fps with my version using OpenGL. The zooming feature also actually works at a 'normal' speed instead of being dog-slow.

My version still has some glitches (not all dialogs work properly, and the sidebar in the main game doesn't draw properly), and it'd probably take quite some work to get everything converted over to OpenGL properly. It also likely won't work on all systems (I use OpenGL textures which have dimensions that are not powers-of-2, forbidden by the OpenGL specs, though it happens to work on my system). However, in my mind it shows that OpenGL is viable and worthwhile for Wesnoth.

Thoughts? Comments? Concerns? Do other developers support this as the direction Wesnoth should go in?

David

[redvasily_]

Hello, Dave

First I'd like to thank you (and other developers, artists, etc.) for Wesnoth. The game is absolutely awesome. I played lot's of games and Wesnoth is definetly is the best turn-based strategy game ever. Despite the fact that this is my first forum post I have been playing Wesnoth since 1.0.

Back to topic.

In short words: I vote for OpenGL with my both hands.

I have some experience with SDL and OpenGL programming. SDL is dead slow (and you know that already). And I think that Wesnoth will benefit from using OpenGL for graphics. Using OpenGL with hardware support you will be able to reproduce current graphics with virtually 0% CPU load.

And OpenGL is hardware accelerated on majority of platforms. That is:

1. Linux, old ATI cards have a nice opensourced drivers

2. Linux, new NVidia cards have good enough closed source drivers

3. Linux, without HW OpenGL acceleration still has Mesa3d which IMHO will work good enough for Wesnoth, at least faster than SDL.

4. Most Windows (and that is the most popular OS anyway ) users will have HW OpenGL acceleration, but it's possible to have some crappy SiS integrated video without OpenGL acceleration (but I've seen this just once in my life)

Perhaps Windows users with SiS video cards will have the worst experience playing Wesnoth, but I think that will happen rarely. Most gamers have NVidia or ATI cards anyway.

Dave, how are you planning to implement text rendering with OpenGL?

Actually I've written scientific plotting library that uses OpenGL and I had problems with font-rendering. There's an article somewhere on the net (i don't remember the link ) that discusses font rendering and OpenGL issues. The best way, which is alse used in most games, as far as I know, is rendering font to texture, and drawing it as a quad with a texture. It work's very fast, gives good-looking results and you can cache produced bitmaps.

But there's a pitfall I'd like to warn you about:

You have to allign sprite pixels to screen raster, so that each pixel of a sprite must be placed accurately at corresponding pixel of a screen or your graphics will appear blurry. Of course you can set texture filter to GL_NEAREST and will work most of times, BUT NOT ALWAYS.

Sometimes it will produce strange looking grpahics. The textured quad consists of two textured triangles in HW, and texture one triangle will appear shifted one pixel along diagonal of a quad. It looks like [censored].

So please design it early in your new engine that SPRITES SHOULD BE ALIGNED TO SCREEN RASTER or your butiful hand-drawn pixel art will appear blurry or scissored in a half

About textures with a side not beeing a power of two, let me guess... you have a NVidia card, right? That won't work on ATI cards, and you shouldn't expect textures with a side not beeing a power of two to work.

I extended images with blank space so that each side was the power of two and set up texture coordinates so that they pointed to corners of original image.

So If you generate textures this way and align sprites to screen raster everything will look just as beatiful as it is now and will work like 100 times faster.

Also I experienced strange differencied with behaviour of OpenGL on Windows and Linux, but nothing that can't be sorted out. After you will have your engine set up I think OpenGL crossplatform issues won't show too often.

Another thought about OpenGL. OpenGL is quite low-level API, you can consider using some higher level drawing API. But such API are usually toolkit-dependent, like Java2d, Arthur/Qt4 they both works pretty fast. Slower than OpenGL anyway, but require less attention. Of course that will require more changes to Wesnoth then simple port of graphics engine to OpenGL.

Bottomline: OpenGL - Yes

[allefant]

On my particular system, this exhibits dramatic performance improvement over using SDL.

Where can we get the OpenGL version? This is the best news for Wesnoth since some time I think

It also likely won't work on all systems (I use OpenGL textures which have dimensions that are not powers-of-2, forbidden by the OpenGL specs, though it happens to work on my system).

It's not forbidden if you check for certain extensions (ARB_TEXTURE_NPOT or something like that), or if the OpenGL version is >= 2.0. But on older cards (like mine), performance dropped from like 80 FPS in my pyopengl test with POT textures to 1 FPS as soon as a single NPOT texture was used. Anyway, it's no problem at all, since you can either use 128x128 textures for 72x72 pictures and leave a border, and adjust the texture coodinates for the rendered primitives, or alternatively simply scale the 72x72 up to 128x128 when creating the texture (without changing texture coordinates later, compared to NPOT).

What the NPOT issue shows though is, we need to define what feature set of OpenGL to use. Cards bought in the last 1 or 2 years probably all can do NPOT textures, and have pixel and geometry shaders. Cards which are 4 or 5 years old can't do anything of that..

I would like to note that I think an obvious response will be that we should support both SDL and OpenGL for rendering graphics. I think this option is an unrealistic fantasy -- the way to optimize SDL and OpenGL are completely different, and having to maintain support for SDL is a nightmare, as well as hindering future developments.

Well, glob2 and pingus seemed to have achieved a way to let you either use OpenGL or SDL (with OpenGL performing much better even on my card..), so this means, well, while the SDL choice is rather pointless, it still might be not that hard to implement something like it also for Wesnoth. Maybe once the OpenGL version is working fully, the idea could be reviewed, if any developers want to.

[Gus]

I don't know if my post is he kind of feedback you want, so feel free to delete it if it's not: I just wanted to say that an OpenGL version of Wesnoth would be sweet indeed.
Like the previous poster, i would love you to release your working version, even though it is still somewhat buggy.

Oh, and thank you and the whole team of contributors for making this game =)

[torangan]

Well, glob2 and pingus seemed to have achieved a way to let you either use OpenGL or SDL (with OpenGL performing much better even on my card..), so this means, well, while the SDL choice is rather pointless, it still might be not that hard to implement something like it also for Wesnoth. Maybe once the OpenGL version is working fully, the idea could be reviewed, if any developers want to.

I guess the only realistic way to support both would be to find a library which does this abstraction and offers a powerfull enough API for Wesnoth. Pingus for example uses ClanLib (not really good). Unfortunately I don't know of any library doing this and most would most likely be a complete SDL replacement. I guess that would be a really major change and not really feasible.
If we do the switch, the most likely outcome is that people who can't use OpenGL because it's too slow for them will have to stick with 1.2.x and to continue maintaining it.

[Tomsik]

If you use OGL just for blitting it should not be hard to keep SDL support.
And yes, wesnoth using OGL would be great.

[Stilgar]

One thing that was mentioned in redvasily's post that I would like to emphasize:

If OpenGL is to be added, it must not blur the sprites. I have tried a few OpenGL ports of Doom which blur the sprites and HUD graphics, making them look smeared and indistinct. To me this is ugly and unacceptable. I would only support an OpenGL version of Wesnoth if it can avoid this flaw. However, if the sprites can retain their proper appearance, and the change will improve Wesnoth performance, then I would be willing to say it's worth a shot.

As to the question of my computer's GL capabilities, this laptop has an ATI Radeon Xpress 200M card, and my OS is Ubuntu Dapper Drake. I am unsure how good the drivers for this card are on my OS, as I haven't really played many games aside from Wesnoth recently.

[Eleazar]

If OpenGL is to be added, it must not blur the sprites.

I doubt there will be disagreement on that point.
In fact, i would express it: "Must Not!"*

But i'm confident that the majority of our coders feel the same way.

* except of course, zooming will neccesarily cause blurring. Which is why i never zoom.

[Dave]

Thanks to everyone for their responses.

allefant, thank you for pointing out the possibility to check if NPOT textures are supported. I suppose to start with we can use NPOT textures if they are supported, and use a POT texture with a border otherwise. Eventually on POT-only platforms, it'd probably be best for multiple sprites to share a single texture (e.g. you could have nine 72x72 sprites sharing a 256x256 texture, which wastes only 29% of memory, compared to the 69% wastage that one 72x72 sprite has on a 128x128 texture).

RE font rendering, this will be done by using SDL_ttf to render onto a texture and then using a quad to display the texture, as mentioned. (This is the only sane way I know to do it at all, in fact). This is already working fairly well, and I don't anticipate many problems with it other than potential performance.

RE OpenGL vs SDL: we are not 'just' blitting using OpenGL. We are changing the way everything is displayed, and caching important surfaces as OpenGL textures. OpenGL generally works by redrawing the entire screen for every frame. The way to do SDL efficiently is to only redraw what needs to be redrawn. These two approaches are largely conflicting, and using both would be quite difficult.

Yes, it would be relatively easy to make an option to use SDL, and have SDL redraw the entire screen every time too, but it'd run so slow, I don't see the point. In the case of a game like Pingus, this is what it has to do anyway, since it's almost always scrolling. Pingus is also much more playable than Wesnoth at a low resolution, making this acceptable.

Finally, RE blurring, I don't anticipate there being any blurring of sprites.

There might be a few changes in the way some graphical effects are done. I can't find any way to draw a color texture in grayscale using OpenGL, other than converting and storing the texture as grayscale, which I think uses memory unnecessarily, so I'm planning on displaying unreachable tiles as darkened, rather than grey.

Also, the day/night effects, rather than adding or subtracting amounts to different colors will multiply the colors by a scaling factor. E.g. whereas dawn might subtract 20 from the red and green channels at the moment, it might multiply the red and green channels by 90%.

I think this will look just as good, but we can test it, and if it's not, I'm sure we can come up with an effect that will create an acceptable alternative.

David

[Glowing Fish]

I don't know the technicalities behind this, but if it can be done, and won't cause any technical glitches, I think it is a good move.

The only thing I would have to say is, I have never noticed the graphical slowness being a problem. The biggest slow down problem I have noticed is with the AI, when it has a lot of units to move, and slowness in MP due to intercontinental lag. Am I the only person who hasn't noticed graphical slowness being a problem?

[turin]

I think the graphical slowness is Windows-specific.

[Dave]

The graphical slowness isn't Windows-specific. I am using GNU/Linux and despite having a new computer, can only achieve ~30fps when scrolling around the map.

There is no excuse for a game like Wesnoth doing under 60fps on a modern high-powered machine. In fact, it should be able to do 100+ fps.

David

[Eleazar]

There might be a few changes in the way some graphical effects are done. I can't find any way to draw a color texture in grayscale using OpenGL, other than converting and storing the texture as grayscale, which I think uses memory unnecessarily, so I'm planning on displaying unreachable tiles as darkened, rather than grey.

Currently it does darken rather than turn greyscale. The old greyscale-only method was nearly worthless in some situations. Though it's better now, i still stand by my recommendation that it also tint the unreachable hexes, for enhanced visibility. Though i would probably tweak the numbers, especially if the item at the bottom of this post can be implemented.

Also, the day/night effects, rather than adding or subtracting amounts to different colors will multiply the colors by a scaling factor. E.g. whereas dawn might subtract 20 from the red and green channels at the moment, it might multiply the red and green channels by 90%.

Given the right numbers that should work just as well, or better.


Also would automatic brightening/darkening according to sources of illumination on different parts of the map possibly be part of the conversion or at least made easier by the adoption of openGL?

Scrolling is laggy on my 3 yr old mac.

[Dave]

There might be a few changes in the way some graphical effects are done. I can't find any way to draw a color texture in grayscale using OpenGL, other than converting and storing the texture as grayscale, which I think uses memory unnecessarily, so I'm planning on displaying unreachable tiles as darkened, rather than grey.

Currently it does darken rather than turn greyscale. The old greyscale-only method was nearly worthless in some situations. Though it's better now, i still stand by my recommendation that it also tint the unreachable hexes, for enhanced visibility. Though i would probably tweak the numbers, especially if the item at the bottom of this post can be implemented.

Errr yeah...my mistake.

By 'tint' you mean favor a certain color? If so, this will be easy.

Also would automatic brightening/darkening according to sources of illumination on different parts of the map possibly be part of the conversion or at least made easier by the adoption of openGL?

Yes. OpenGL would make this trivial.

David

[redvasily_]

Eventually on POT-only platforms, it'd probably be best for multiple sprites to share a single texture (e.g. you could have nine 72x72 sprites sharing a 256x256 texture, which wastes only 29% of memory, compared to the 69% wastage that one 72x72 sprite has on a 128x128 texture).

Isn't that gonna be a premature optimisiation, wich as everyone knows is the root of all evil. (http://www.taylor.se/blog/2006/11/22/why-optimizing-without-profiling-is-inefficient/ for example)

Perhaps everything will work just fine without that optimisation, so why spend developer resources on that issue. We have (no-one knows)xAGP cards this day so OpenGL driver can upload whole a lot of megabytes of textures from RAM to video card. And even if new Wesnoth engine will be slow compared to Half-Life2 it will be faster than Wesnoth/SDL.

RE font rendering, this will be done by using SDL_ttf to render onto a texture and then using a quad to display the texture, as mentioned. (This is the only sane way I know to do it at all, in fact).

Well, that's the most commonly used method of font rendering using OpenGL. Other methods include outline drawing, ratster operations and some even more bizzare stuff that I don't remember.

The method you plan to use is most widely used in computer games, as far as I know and gives best performance and produces good looking fonts especially for small font size. So you made a good choice.

Finally, RE blurring, I don't anticipate there being any blurring of sprites.

That's certainly possible to avoid blurring of sprites. I just run once in that problem myself, so I wanted to warn you. That will probably will even never happen if you will use pixel-based coordinate systems, or will take specific actions to allign sprites to screen raster.