New To 32bit Graphics? Read This First! [updated 27-06-2012]

[Jupix]

A collection of links follows:


The most important link, the
What Is This About? link -> Wiki: 32bit Graphics Development


Links for Players

Confused? READ THE FAQ

Want to see it in action? Well, it's currently complicated. I would recommend waiting till we get it fixed.

Still determined and want to see what the engine is capable of? Grab a legacy version of the game (pre-1.2.0), the dev version of my nightly bundle, and play away. Instructions here: http://wiki.openttd.org/Playing_with_32bpp_graphics

No artistic skills? You can still contribute to the project!

There are a few of ways to contribute to the project besides making 3D models and rendering them. Namely, administrative tasks at the wiki (progress trackers, etc.) and at the repository, 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 and we use a tool called PNGCodec for the coding. It is a slightly time consuming and repetitive business, which is why we need contributions there every now and then.

Links for Developers

Project Documentation with rules & regs

Graphics Development Documentation

How to Create 32bit Extra Zoom Graphics

File Repository

Progress Tracker

My 32bit Graphics Developer Tools

• Look Up Repo Entry By Sprite#
• Run Diff Between Repo Entries

32bpp_extra project: http://www.tt-forums.net/viewtopic.php?f=36&t=47288


Links for Administrators

To Do



Post additions please!

[luk3Z]

I found nice video on youtube, so alternatively you can watch this first

http://www.youtube.com/watch?v=4qWM9ggF ... h_response

[Herr]

Hi guys, I would very much appreciate some clarity on how installing the 32 bit mode is to be done.

Firstly, is it possible to use the standard OpenTTD 1.2.0 version?

Secondly, as the version 1.2.0 and beyond include the extra zoom levels, how does the installation procedure differ? (installing new zoom level presumably is not required - however the 32 bit sprites are not included?)



When I follow all the instructions, i get the following: The main OpenTTD menu screen runs extremely slowly, however it looks the same as in the standard 8 bit version. When generating a stand alone single player offline game it runs smooth, however the graphics have not changed at all. Nothing is different from the 8 bit version. I have changed the "blitter = 32-simple", and I have copied all the necessary .tar megapack and .grf files into the correct locations. I also have also correctly added the new newgrf extra zoom in the newgrf settings. I have tried different combinations of all of these factors without success.

Could you please supply an instruction to the installation process for someone that is using the 1.2.0 version and apply 32 bit mode to it.

I would very much appreciate any input, as I would really like to play in 32 bit mode and enjoy the benefits of all the work that has gone into it. It seems as shame that it is not possible to be used.

[Lord Aro]

the existing instructions can basically be completely ignored.
Now, you have to use a 32bpp grf (i'm not sure if any are on bananas yet, but you can search the forums for a couple that are hiding ) which you put (the grf) in the normal place

[FooBar]

I think the most notable 32bpp grf is OpenGFX+Trains. Other 32bpp grfs are pretty much nonexistent. Seems nobody really cares about re-releasing the previous work in grf format.

[Xotic750]

I think the most notable 32bpp grf is OpenGFX+Trains. Other 32bpp grfs are pretty much nonexistent. Seems nobody really cares about re-releasing the previous work in grf format.

I think that it's more that not all artists have the knowledge to create a NewGRF for their work. It was much easier in the EZ project as you just had to name your sprites correctly and then tar them up.

[FooBar]

I wasn't specifically speaking of artists. There should be plenty of people with less artistic skills who could lend a hand with that. As it isn't particularly difficult to code simple graphics replacements in NML, which is what's needed for most 32bpp graphics anyways. Probably no more than half an hour studying is needed to understand what needs to be done. If one were to invent a naming scheme for the sprites that encodes sprite number to replace, zoom level and offsets, it's fairly trivial to write a script that generates the NML/NFO for you. That's a one evening job for a single person, really. It needs a bit more knowledge than coding sprites manually though.

Myself? I'm not really interested in having 32bpp graphics in my game. They look great, but I like the feel of 8bpp better.

[Xotic750]

There should be plenty of people with less artistic skills who could lend a hand with that. As it isn't particularly difficult to code simple graphics replacements in NML, which is what's needed for most 32bpp graphics anyways. Probably no more than half an hour studying is needed to understand what needs to be done. If one were to invent a naming scheme for the sprites that encodes sprite number to replace, zoom level and offsets, it's fairly trivial to write a script that generates the NML/NFO for you. That's a one evening job for a single person, really. It needs a bit more knowledge than coding sprites manually though.

... and the offers of help come flooding in

[FooBar]

I wasn't offering to help, although I wouldn't mind writing a script whenever I have time. Don't wait for it though.

[maquinista]

I think the most notable 32bpp grf is OpenGFX+Trains. Other 32bpp grfs are pretty much nonexistent. Seems nobody really cares about re-releasing the previous work in grf format.

The problem is that Nobody knows if the 32bppGRF format will be forever or if It will be changed soon.

[FooBar]

Never say never, but it's highly unlikely that it will change any time soon. I think it will only change if the complete NewGRF format is replaced by something else, which is also highly unlikely.

[thphwh]

In my opinion, I would have the 32bpp graphics bundled with 8bpp which means that you can switch them on start up of OTTD. Once the 32bpp faff is all over with and completed, surely this idea could be implemented into the game?

[Herr]

I'm sorry for being a little persistent here... so is the conclusion that it is not possible at all to view 32 bit graphics? I do not understand this, why did anyone bother making new textures if there is no way of using them. And why were two extra zoom levels introduced since version 1.2.0 if they serve no purpose. The only way OpenTTD can be played is in 8 bit mode, and the two extra zoom levels are a handicap - not a benefit.

Am I missing something obvious, like there is in fact a way of using 32 bit graphics? Or will a new OpenTTD version come out soon that includes the 32bit as an alternate option from 8bit mode, hence the 1.2.0 release was in preparation for this. Does any of this make sense?

[FooBar]

It's just that the format how to supply them to the game has changed. And nobody has had the time to put the existing graphics in the new format so that they can be used again.

So there certainly is a way to use 32 bit graphics, but simply not a lot of graphics have been released in the new format. If you want the graphics that worked previously in your new game, the only way currently is to put them in the new format yourself. Or wait for somebody else to do it.

Also no new game version is needed. The current version has fully functioning ways of loading 32 bit graphics, no need to change that (again).

[Rubidium]

nobody has had the time to put the existing graphics in the new format so that they can be used again.

I wrote a script for that. I will not release the results of that script because the copyright and license of many of the graphics is totally unclear to me. As such I am unable to (legally) distribute the resulting files. The script has been released on this forum.

[FooBar]

I'm aware of your script, and that is greatly appreciated.

But as you correctly observe, having "time to put everything in the new format" includes gathering sources, license permissions, etc. Which takes far more time than running the script.

Running the script for personal used is unfortunately too far fetched for most regular windows users. So we are again where we were: people who know what needs to be done don't have the time to do it. And people who don't know either don't have time or do not want the 32 bit graphics badly enough.

[Rubidium]

Even so, I made the script so people can use it to convert the old files, or even make the replacement in the old format like half a year ago. However, since then it seems like nobody cares about 32bits graphics (or at least a partial base set) enough to actually do something. Okay, that's hard to prove as there could be people secretly doing stuff, though then surprise us by that Black Swan. Until then it's rather safe to assume that if you want 32 bits graphics you have to make/assemble them yourself.

The only significant work I've seen lately are those trains for ogfx+trains which could, eventually, end up in OpenGFX proper. But for the rest it seems to be severly lacking in progress.

[FooBar]

Yes, I agree. Those who want 32 bit graphics right now should do the conversion themselves. The script is there, so most of the work is actually already done for a personal-use conversion.

[GeekToo]

Scripting really isn't that hard, esp. when the Rubidium script is used as base.

Ben Robbins temperate ground with lines in newgrf format:
http://dev.openttdcoop.org/projects/32bpp/files

GPL 2, sources http://jupix.info/openttd/gfxdev-repo/i ... file&id=67

Generated nml attached, but I am not very experienced in nml, error may be present, but the newgrf seems to work.

Uploading the file took longer than the actual conversion script.

NB: only works for 32bpp bliiter, 8bpp only contains empty.pcx!

[knuckles88]

But as you correctly observe, having "time to put everything in the new format" includes gathering sources, license permissions, etc. Which takes far more time than running the script.

N00b question, but most of the 32bpp graphics were already available in the form of the nightly .tar's (32bpp base and 32bpp extra, I believe?). How is bundling them in a .grf different from bundling them in a .tar?

Is there a roadmap for how the source and license collection would go? It seems to me like one would start with the last version of the nightly .tar's, list off all the components, and then contact the authors/artists for each component seeking permission or clarification of the licensing status. It seems to me that sources aren't necessary, since all the images which were displated in-game are available in .png format if you un-tar the bundles. Is the information on who submitted what to the bundles readily available, or would one have to go back through the forums looking for individual posts? I'm trying to get a handle on exactly how manageable/impossible this task is.