Questions for OpenTTD Developers

[schitzn]

Hey Guys/Gals (if any),

Firstly, thanks to all the developers for their efforts in OpenTTD. Ive been a Chris Sawyer fan since I got TTDLX back in I think 96ish, and have been using OpenTTD since the 0.4 days, but I've never engaged in these forums, so now I am, my first words are Thanks!

Im a long time programmer, although mostly application programmer, and have been working on my own 2D Isometric gaming engine on and off for a number of years. Ive really been nailing into it over the last few months and my aim is to replicate the main game engine of Rollercoaster Tycoon/Locomotion. So far, its coming along very well, I have completed the Window and Interface system and is looking/functioning exactly as RCT. Im currently recoding (again) the actual mapping renderer and look forward to polishing it up and dumping a release for any other Sawyer interested fans to look at. Im not sure where Im going with it, hence why Im purely designing the core mapping/ui/window/blitting/game logic system which offers the ability to take the project in different directions.

I have a few questions of how implementations are done in OpenTTD for things I will be implementing but not entirely sure the best strategy...

1. Character Sets for fonts / Language Character sets

Ive noticed there are two font sets used in OpenTTD by looking at the Wiki (big & small), my system at this stage converts strings into their ASCII character code (ie. 31-127 range) to determine the actual font character to print. Hence each character is a byte (0-255) in range. In OpenTTD, Im assuming you have non english style characters and possibly support for non-english characters (ie. Kanji/Chinese). Im assuming all characters are pre-rendered sprites, if so, how many different font characters are used by each font set?

2. Colour overlays for sprites

Okay, so your company colours are moulded into a train, or in Loco (two sets of colours) and in RCT (guests have a shirt/pant colour) (im aussie hence the colour not color). In terms of minimal CPU overhead, whats the best way to do something like this... Currently I have four bytes for each sprite pixel.

Byte 1: Red Channel [0-255]
Byte 2: Blue Channel [0-255]
Byte 3: Green Channel [0-255]
Byte 4: BitMask for Transparency [0 transparent / 1 Paint using Byte1/2/3]

Im assuming the way its done is like this:

[Set of Colours] ie. Dark Red, Light Red, Dark Blue, Light Blue]

Each Set has a number of shades of that colour in brightness (Im assuming say 8 )

Each Pixel would then need to specify if it (1) uses a colour set and (2) if true what shade that color is for that color set

Im assuming a lookup table utilizing the value of Byte 4 if not equal to 0/1 allowing for 254 independant predefined RGB values


Feedback from Genuises welcome!

[Zuu]

I'm not an OpenTTD dev, but I have also written my window system + isometric landscape engine. The conclusion I draw about 4-5 years ago was that when I was trying to make a junction simulator out of that I was approaching it all from the wrong way. Instead I started a new project with zero lines of code, and built up nodes, links etc. and then added simple 2d graphics etc. A bit later I added back the window engine code as I needed it for my user interface. The Iso engine could be added later when the core features are done. Or, a 3D engine if I find time to learn that. What I want to say, if you build an advanced window system, graphics engine etc. you may find yourself limited when you try to build the core logic.

My first try can be found at SF.net: http://junctioneer.sourceforge.net/screenshots.php (notice that the link to the old site is broken, I don't own that domain anymore)
Note that the source code there is quite old and broken on newer compilers.

The restarted project can be found here: http://www.junctioneer.net/ (currently closed source)

[schitzn]

Hey Zuu,

I had a look at your two links (old and new variant), looks different, although I didnt have a solid look. Is it more based around pathfinding?

My engines running fine, The Window and Viewport system (Tilemap renderer) work well together. The Window system is my first build and will be my final, its polished to a T and behaves/looks exactly as RCT's. The temporary game logic Ive got running off it has the merry-go-round and about 50 peeps roaming with PF and other things to trial core game logic/mechanics. Im just recoding the Viewport Renderer because the one Ive designed doesnt permit rotation and zooming, plus other things I want to add to the mapping system and I know theres room for optimization hence thats my next revision.

Hence, cause Im still lacking my Font and custom Colouring for sprites, and they play a role with where Im going with it, Im asking for feedback from OpenTTD developers on how OpenTTD's implementation is done.

Im not trying to hype anything my side, nor am I asking for programming direction, I just need some assistance before I started coding these components into the engine without needing to reattend to them lator because they didnt consider things that maybe needed lator on.

[Rubidium]

OpenTTD's base (sprite) font does not support all characters, only a small subset. For the rest we make use of just plain fonts from the operating system via freetype (and a platform dependant font discovery system). We have 3 different font sizes; small, normal and big. When a system font is used the user has control over the size of the fonts via the configuration file.

Using ASCII as "character set" (character encoding) is a bad choice if you want to properly support languages other than English. Basically for Europe the further you go away from England the more non-ASCII characters you need to properly display a translation in that language, with Cyrillic and Greek being the furthest away and not even displayable by ASCII. As reasonably simple solution for this is using UTF-8. Please note that for right-to-left languages, such as Arabic and Hebrew, you also need some (tricky) reordering/normalising/magic to display properly but (lib)icu will help with that. You need to make the user interface right-to-left aware though.


OpenTTD primarily uses 8 bits graphics where a specific range of colours is marked as recolour colours. Then when drawing we resolve which colour to draw exactly by a simple table lookup. With 32 bits graphics it gets more complicated and I'm not quite sure how it works there. Also given that there are (if I remember correctly) three different colour overlays for 32 bits graphics and OpenTTD... there is a lot of design choices to be made.

[schitzn]

Thanks Rubidium for taking the time to answer my questions,

Not really knowledgable of encoding, but from what I thought I know Windows has two String API's, the ASCII (0-255) and Unicode (2 byte Int16 Range). Just had a look at Wikipedia, UTF-8 is a 32bit encoding, using a sign-bit to represent ASCII or extended character set in the first byte, and the remaining 7 bits representational the first 127 values of the ASCII character set? The other three bytes are considered if the sign bit is flagged.

With Right to Left output, is that primarily visual alignment (left alignment should be right alignment) (ie. text in a caption bar should begin next to the right edge versus left edge), obviously the text is read reversed, which being a translation would be handled by the translator writing the applicable equivilant. If Im correct on this, is that the only main concern (ie. Centering of text is acceptable either way).

I thought OpenTTD used a 32bpp colouring scheme for the newer graphics (apologies for my ignorance). So the 8bit table reserves a certain number of the 256 palette lookup entries (how many? 8?) for this variant colour painting. Anyone know if RCT/Loco run as a 8BPP engine?

Thanks!

[Eddi]

Not really knowledgable of encoding, but from what I thought I know Windows has two String API's, the ASCII (0-255) and Unicode (2 byte Int16 Range). Just had a look at Wikipedia, UTF-8 is a 32bit encoding, using a sign-bit to represent ASCII or extended character set in the first byte, and the remaining 7 bits representational the first 127 values of the ASCII character set? The other three bytes are considered if the sign bit is flagged.

No, UTF-8 is byte (8 bit, hence the name) based. the first and the following bits (if set) define how many following bytes are consumed by this character (latin-derived letters like accents typically have 2 bytes, greek letters 3 bytes, etc.), if the first bit is not set, the rest of this character is identical to a 7-bit ASCII character, thus UTF-8 is backwards compatible with tools that can't handle unicode

[peter1138]

OpenTTD's 32bpp system cheats. For each sprite there is a 32bpp image for colours that don't change, and another 8bpp image for the remapped parts. The 8bpp image is overlaid over the 32bpp image. So with both 8bpp and 32bpp graphics sets, the same 256 entry palette lookup tables are used.

RCT and Locomotion are both 8bpp only games.

[Zephyris]

The extra zoom levels patch uses a different recolouring algorithm, which uses a base rgba png and a recolour "stencil". Anything within the stencil can be recoloured, preserving the saturation and value of the original sprite but setting the hue to the desired shade.

You can find the algorithm I wrote for this here: http://www.tt-forums.net/viewtopic.php?p=825935#p825935

[schitzn]

Thanks guys for taking the time to respond.

Zephyris, you actually bring up another thing that I havnt thought of yet. Zoom levels. Sprites say 64x32 (ie. the base tile on the background of this website lol), zoom up 1 level its now 32x16 and level 2 its 16x8 etc... What method does OpenTTD use for the zoomed sprite, are they generated on blitting or are there a actually sprite set in file or generated at game_init? If they are procedurally generated, is it done through a alpha blending method of the compressed pixels or does it blit skipping pixels retaining non-skipped pixel RGB values (which id assume would look like crap). Zephyris, are you saying that almost the entire original sprite (region defined by masked area) is tinted rather that addressing particular pixels for zoomed sprites with a custom colouring scheme?

btw, is the alpha channel actually used in 32BPP sprites for anything or do you have it there purely because of the performance benefit compared to 24BPP blitting.

[Zephyris]

What method does OpenTTD use for the zoomed sprite, are they generated on blitting or are there a actually sprite set in file or generated at game_init?

AFAIK the 8bpp sprites are shrunk by ommitting every 2nd pixel (etc.) on blitting. I don't know about in 32bpp.

Zephyris, are you saying that almost the entire original sprite (region defined by masked area) is tinted rather that addressing particular pixels for zoomed sprites with a custom colouring scheme?

I'm not sure what you mean... The current implementation recolours everything on blitting. There are more efficient ways of doing this but due to the way the 32bpp sprites have been drawn this was the simplest way to do it.

is the alpha channel actually used in 32BPP sprites for anything or do you have it there purely because of the performance benefit compared to 24BPP blitting.

The alpha channel is used for alpha blending!

[prissi]

It is not entirely OpenTTD, but Simutrans has a 16 bit rendering (in reality 15 bit) with 32000 reserverd color, of which only 32 are used. Using 15 bits still allows for darkening via lookup tables, and transparencies do not look too crappy. For zooming sprites are rescaled before blitting, saves a lot of CPU time.

The window system is fully OO, with all windows derived from a base class, and all gui elements just added. You can look at the source one the svn or on sourceforge: http://sourceforge.net/projects/simutra ... p/download

(On a side note: I wonder, how many people reinvent the wheel ... I would rather start with something mature, and make over just the part I do not like.)

[GeekToo]

schnitz, there are significant differences between the 32bpp mechanisms used in the trunk version and in the extra zoom level patch (that not only implements the extra zoom levels, but also a lot of other improvements for 32bpp).

To start with the similarities:
both versions use rgbam pixel values as input for the blitter. rgba is provided by the 32bpp sprites, m (for mask) is provided by an 8bpp mask file, that will indicate where recolouration (like for company colour or random recolour) is needed, in with which colour.

What method does OpenTTD use for the zoomed sprite, are they generated on blitting or are there a actually sprite set in file or generated at game_init?

trunk: generated on blitting, sprite cache only contains the most zoomed in sprites
ezl: spritecache contains a spritecache for every zoom level, filled when the sprite needs to be loaded for the first time in game. Reason for this modification was that imho it does not make sense to recalculate the zoomed out sprite values for every screen refresh.

If they are procedurally generated, is it done through a alpha blending method of the compressed pixels or does it blit skipping pixels retaining non-skipped pixel RGB values (which id assume would look like crap).

trunk:skip pixels during blitting
ezl: alpha blend pixels by interpolation of neighboring pixels during filling of the spritecache. Reason for this modificaion was that skipping pixels indeed looks like crap.

Zephyris, are you saying that almost the entire original sprite (region defined by masked area) is tinted rather that addressing particular pixels for zoomed sprites with a custom colouring scheme?

Only for the pixels where the mask file is nonzero, recolouration is applied, other pixels show the original sprite

btw, is the alpha channel actually used in 32BPP sprites for anything or do you have it there purely because of the performance benefit compared to 24BPP blitting.

Alpha channel is used for blending in both versions
In ezl it is also used for: real transparency mode: it is possible in the game to make objects that block the view to eg staton transparent. In trunk this is not real transparency, but just darkening of the sprites behind the blocking object a bit and not showing the blocking object, in ezl it is real transparency. Personally I'm not sure whether this is an improvement, but at least it shows the possibility for real transparency.

More differences:
trunk does apply company colours by replacing the pixels of the 32bpp sprite completely with the colour of the 8bpp mask files (by using a LUT to convert to 24 bpp). Unfortunately, only 8 palette colours are available for CC, effectively making the pixels where recolouration is needed 3bpp.
The ezl-patch does colourize the original sprite pixels with the mask colour using the algorithm Zephyris pointed you to.

[schitzn]

Thanks guys (GeekToo; your explanations went beyond excellent, thanks).

prissi - Reinventing the wheel is not always a bad thing, especially when done independantly of each other, especially in open source, because it enables both parties to feed off idea's and improvements, hence moving the whole optimization/performance/productivity process faster for everyone overall.

Also, My project aims to be a skeleton of the RCT/Loco engine. OpenTTD (and similar remakes of TTDLX) are based on the Transport Tycoon engine, difference being no vertical faces, sprite placement on tiles, more than 8 (N,NE,E,SE,S,SW,W,NW) sprite animation angles, multi level sprite support (ie. stacking), plus heaps of other little things. I plan to focus primarily on the engine, without a direction of gameplay, but have the core mechanics in place that enable a world/mapping/window ui that similates that of RCT/Loco. Should a game concept come up, it would be a seperate project that uses this project as its engine (built upon it).

But at this stage, my project is all speculation to a third party and nothings more annoying than hype or vapourware games that fissle away into nothingness, I am making good progress and when I feel its at a stage which is ready and may create an interest based on something people can actually go, hey, this is pretty cool, that is when Ill start expanding on what Im doing and hoping to achieve. [Just wanted to clarify my stance because I feel like some ppl get annoyed with hey, Im making x and its going to be this next big thing, and never does].

[Eddi]

IMHO, if you want to have more than 8 angles, you're better off using 3D models instead of sprites.

[schitzn]

IMHO, if you want to have more than 8 angles, you're better off using 3D models instead of sprites.

hmmm, IMO Id say theres more benefits with sticking with pre-rendered sprites but feel free to argument my belief if you think Im overlooking something. The extra processing time to render the object vs using a pre-rendered sprite. Plus mixing 2D/3D objects tends to mix high quality pre-rendered graphics with lower polycount objects will affect the aesthetics of the game. The only benefit with 3D models would be less RAM to hold pre-rendered sprites and less work for the GFX artist. This could be countered by having a specialized tool to convert a 3D object to the required angles to generate these pre-rendered frames for the artist, and as for CPU/RAM, saving CPU cycles over RAM usage is the aim of the game.

And to explain why CPU time: Blitting a 2d sprite copies data from one area to another. Doing 3D may be low expense due to a 3D card, however in comparison, you need to render the object offscreen, and then do the blit just like a 2D sprite. You cant render a 3D sprite directly into the world because of positional issues against other sprites (Issue of Z axis which doesnt exist because the rest of the game is rendered in 2D and positioning is determined by the game blitter). Unless the whole game was done 3D, theres no gain in performance to the game engine specific to a 3d model being used.

[Lord Aro]

Entirely irrelevant i know but do tell us when you release anything, do let us know.
many people on this forum will be happy to try/test/debug anything (me included)