So, how do I imagine this PNG graphics stuff? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note that this is a very early sketch. I did not really look deeply inside to this and to the implementation side as I'm busy with making TTDPatch GRF codec now. Also note that the original idea of using user chunks in PNG files is not mine - IIRC Vurlix suggested that but I'm not really sure. Please tell me if it was you. So, as I imagine this, we need to divide the problem a little. First, please raise above the current way of how things work a little and clean your mind. So, what are we going to talk about? It is not solely graphics, although it's one of the main parts. But I want these files to keep all the other relevant gameplay data - ranging from vehicles info through info about all the buildings (industries as well as town houses) to user-defined airports. So let's call it "CGD files" for now, CGD standing for "combined game data". First let us concern with how the CGD is distributed amongst users and used by OTTD. In order to have all the data easily distributable and compact, we should keep it all in a single file, much like GRF. And to make it easy to build tools for working with these files, the underlying format will be pure PNG. This PNG file will contain graphics chunks containing the sprites and user chunks containing the relevant game data (usually but not necessarily associated with a particular sprite). However, such a CGD file would be a PITA to create or modify. Therefore, there must be a tool like grfcodec, which will uncompress and compress a CGD file to/from a more friendly form. This form should consist from a set of PNG files (coming from the graphics chunks) and a set of GPD files (GPD standing for "gameplay data") (coming from the user chunks). Such GPD files should be directly modifiable of a text format. Maybe XML, but I would personally favour something less controversial; simple INI-style format could do. PNG files on their own would be meaningless - each PNG file would be referened from one or more of these GPD files. Therefore, imagine ie. this: Small Arctic Set.cgd : Dm3.png A40.png Maple tree.png Paper mill.png HAirport.png Dm3.gpd defines a new rail engine Dm3, sprites in Dm3.png Dm3-alt.gpd defines a new rail engine Dm3 with slightly different attributes, sprites in Dm3.png as well A40.gpd defines a new rail engine A40, sprites in A40.png Maple tree.gpd defines a new tree, sprite in Maple tree.png Paper mill.gpd defines a new industry, sprites in Paper mill.png HAirport.gpd defines a new type of airport, sprites in HAirport.png Of course a PNG file could contain multiple logically connected sprites just like in GRF files, ie. a sprite superset for a coal wagon - 8 sprites per direction make a spriteset, 4 spritesets per loading state make a sprite superset (the numbers are just examples). While in the PNG file we could put each single sprite to a separate chunk and then group those chunks somehow, in the extracted PNG files we have to use a different technique. Either we go the way of GRF files and record coordinates and size of each of the sprites, or we could number the sprites 1,2,3,4,5,... (by the position of the upper left corner of the sprite box, counting from the upper left corner of the image) and then bound each sprite by a box from some special color, say a purple with non-zero (but low) alpha value. This could be more friendly to the artists. Then the other question is of course how to encode "special" colors from the GRF files - transparency, company livery, flashing lights... Regarding transparency, we can make use of PNG's alpha channel. Regarding the other stuff, we could again take advantage of some special RGBA combination - I would personally suggest a certain shade of purple with varying alpha value (keep alpha value 0, max/2, max for the artists, though). It should be possible to redefine certain special colors to use some other RGBA combination for a given sprite, though. -- Petr Baudis