Oolite Bulletins

Hi all,

I'm trying to learn OpenGL to see if I can do something about the text rendering in Oolite, which is the major impediment to localisation as far as I can tell.

Until yesterday I never managed to get anything to appear in an OpenGL window (well, aside from Oolite ;) but I finally started making progress.

The text drawing using SDL images rather than textures wasn't going too well so I thought I'd try a diversion and convert the Oolite .dat files to OpenGL calls and see if I could get the ships drawing.

This won't turn into another DryDock - I can't even understand the messages from F_C and Ahruman. But I'm pretty happy I finally wrote some OpenGL code that actually draws something other than a blank window!

A new text implementation would be nice. Again, the best base for it would probably be FTGL or possibly GLTT. If you want to play with OpenGL for the specific purpose of helping with Oolite, learning one of those libraries would probably be a good start. :-)

My current plan is to make the SDL version work for different languages, abstracting away the code so you Mac wizards can either keep what you have or implement something of your choosing in place of my SDL code.

I'm using SDL_ttf at present because it is really easy to use.

I've already looked at both of the libraries you mentioned and didn't think they were as easy to use as SDL_ttf.

Admittedly, one problem with SDL_ttf is users getting a TTF font that works for them. Windows users will have no trouble, but I don't know how *NIX users will go with that.

Perhaps if I get the first version going, someone else will come along and just replace my SDL code with something that works everywhere. At least then it is just the window dressing (pun intended) because all the strings will have been externalised and the logic sorted out where necessary.

Winston mentioned the planet descriptions and that might be tricky. The order of the stock phrases put together might have to change for different languages, and planet names might have to stay in English unless a native speaker can come up with a set of name fragments.

This has just prompted me to think of OXPs too. Many of them have planet names in their mission text. We'll need a way to specify the galaxy and planet number and have the pair expanded to the localised planet name.

I still think the game engine looks pretty good. This is only the second time I've said something nice about GNUstep, but NSString is unicode by default, and XML plists can be UTF-8 encoded, so that's all good. I've already tested getting Russian text in and displaying and it was no trouble.

The much bigger problem is font rendering in OpenGL and my inablility to program OpenGL with any degree of competence or success. It does my head in.

EDIT: Here is a shot of the game running with both Japanese and Russian characters in the descriptions.plist entries for the opening screen. The text isn't in the right place or the right size for various reasons, but it looks better than it used to now I'm switching to an othorogonal projection to draw it. But this stuffs up all the text coordinates and sizes Oolite wants to use, so it may not be the right answer.

Three languages at once

The way to solve the fonts-vs-platform issue is to package a freely redistributable font which fits the bill with the game (can you tell SDL_ttf to look in locations other than the OS standard?)

Other than that, there's a pretty standard set of fonts (you can bank on the Luxi fonts being available) with any GNOME-based Unix desktop.

You can tell it where to look. I was going to take the location of the font from the defaults file. I hadn't considered how to get it in there other the user editing the file though.

Ahruman has set me straight on releasing textures which has fixed the prodigous memory leak.

So now the big problems are (1) speed and (2) drawing text that looks nice at the location and of the size that Oolite wants. The textures I'm getting so far are not handling this well at all and I don't think my simple-minded way of using an orthogonal projection that maps nicely to screen coordinates is going to cut it.