32bit Graphics Development
/File/en/Outdated content.png
Out of Date
This article or section is outdated. Some of its content may no longer be accurate due to changes in the latest release. Please update this article.
References outdated forum threads etc. The 32bpp project referred to in this section is, as of 2017, dead

« Back to NewGRF

Since late 2004 there has been an effort to modernize OpenTTD graphics by giving them more color and detail. This effort goes by the name of 32bpp graphics development, after the bit depth of our new sprites.


Development process in a nutshell

Gameplay scene in 8bpp, at normal zoom level.

Gameplay scene in 32bpp, at normal zoom level.

Gameplay scene in 32bpp, at "zi4" zoom level, aka. extra-zoom.

A 32bpp graphics artist develops their graphics mostly in 3D modeling software, which at the end of the creative process is set to render the 3D model into a 2D sprite, which is then shown in game. Getting these Network Graphics png sprites to show in game has required major revisions into the game's graphics engine.

For some, the process is a little different; for example, ground tiles are usually worked as bitmaps, not modeled. For the artist the software may only consist of a single photo editing suite like GIMP.

"Drawing" the item and making it a sprite is only part of the process. After this comes the "coding". The sprite has to be given some metadata in order to get it working in game. It is up to the artist whether to do this themselves, or have some other contributor do it.

At the end of the day, the finished contribution ends up on a central place for 32bit graphics contributions. From there it is appended to our base graphics set, or if it's a standalone package, it can be made into a NewGRF which players can download off the ingame content delivery system.

For more information on creating 32bpp graphics, see 32bit Graphics Development Documentation.

Normal zoom and full zoom

There used to be a gap between zoom levels when it comes to graphics development. People would render extra-zoom or normal zoom only. These days OpenTTD supports all of it out of the box, so it makes sense for an artist to render distinct sprites for the three closest levels of zoom.

Full zoom level allows for much greater detail in the finished product, but the artist must take care not to make the sprite look busy or unclear at normal zoom levels.

Project organization

Artists are free to work on whatever item they desire, but it is recommended that they first check the normal and full zoom progress trackers here at the wiki for items that haven't been rendered in 32bpp.

Every time an artist works on any 32bpp graphics item, it is requested that the files in question are uploaded to the 32bit Graphics Development File Repository under the GPLv2 license. This is mostly to avoid loss of material in case development of the file ceases for technical, personal or other reasons.

New graphics, engine features, bug reports, suggestions and other discussion take place at the 32bpp graphics development section at tt-forums. There are general threads for 32bpp normal zoom and 32bpp full zoom graphics. Administrative matters are discussed in the "Organizing 32bpp sprites" thread.

Sprites can also be downloaded individually via links at the progress trackers.

When an item is completed, it is primarily the artist's responsibility to keep progress trackers up to date and notify distributors of the existence of their new content. There are volunteers working these administrative tasks but it is in the best interest of the project for the artist to do this themselves if they can.

Not a 3D modeler? You can still contribute

There are a few of ways to contribute to the project besides making 3D models and rendering them. Namely, administrative tasks here at the wiki (progress trackers, etc.), testing graphics and giving feedback, improving the 32bpp graphics engine by means of programming and "coding graphics".

Coding graphics means inputting correct pixel offsets for the sprites so that they line up properly in the game world. This is not difficult, nml can be used like for 8bpp newgrfs. It is a slightly time consuming and repetitive business, which is why we need contributions there every now and then.