Transport Tycoon Forums

the offsets will be constant for every sprite of a given zoom level (i may be wrong in this assumption but this is what i got from the discussion so far, would be great if someone can clarify this further)

I think the majority of sprites do follow this rule but I think there will always some sprites which are exceptions. Sprites that immediately jump to mind are the rail and field hedges and fences...

regarding size, the average sprite size with a decent compression (80%+) is around 20KB the worst offenders are around 100KB
worst case scenario is 7000 x 100 x 2 aprox 1.3GB

as for blender files, use the compress file under the file preference, this reduced the Road_Stations blend file from 691KB to 116KB, as for the blend1 and blend2, these are version files, under same file preference turn save version to 0 and they wont save any old versions. I noticed that your blend files are directory dependent for texture, you could probably eliminate this by baking the textures into the models themselves (though that would increase file size but allow you to eliminate the need to distribute the textures, the same process can be used to create high contrast models by baking the textures with a different light setup then the one used for final render)

(im actually an artist who very handy at coding too, though i prefer the phrase workflow optimization, but an artist by nature)

*edit

we can use a different process for these sprites that have different placement values for the same image, probably give them their own GRF to make life easier too, i believe with NML you can reference one GRF into another, so this can be later reference into the Base grf

Something to remember is that if you need to re-render any or all of the blends, when you commit to the repo then it keeps a history. So for example if you re-render all the 7000 files again due to a light or material change, your repo now becomes 2.6Gb and so on.

im just wondering how useful it is to keep history of all the image files, these are after all a by product of the blender rendering, in reality you could probably recreate the files using the blend file (yes time consuming), it make more sense to just keep history of blend files, any NML, ini and the texture files, the PNGs are just be kept as snapshot of the current blender renderings

CargoLiner wrote:forgive my ignorance, i understand the usefulness of such a setup when using spritesets or sprite templates, but from what i understand, all the sprites and variation of will be rendered to their own individual PNG file at full frame, the offsets will be constant for every sprite of a given zoom level (i may be wrong in this assumption but this is what i got from the discussion so far, would be great if someone can clarify this further)

You are completely correct here. That saves 18 lines (the {064,128,256}-{xsize,ysize,xoffset,yoffset} variantions) in the [root] section at the cost of less transparency in what the code does in that case. I prefer explicit code, so I added them (at the cost of some code to handle them). In addition, it makes life eaiser when you want to code single sprites if the need arises.

CargoLiner wrote:so for all intent and purposes there will not be 19 different blocks to define terrain, as all definitions will be identical so a single definition would be used

Nope, this holds for zBase graphics (mostly), but not for 8bpp OpenGFX graphics.

'xpos', 'ypos', 'ysize', and 'yoffset' change there with every sprite (at least xpos, the others seem to change more in blocks).
Obviously, opengfx and zbase have no nice relation, they each change independently.

CargoLiner wrote:in fact we could take this a step further and say that there is generally speaking only 3 major definitions one for each zoom level for all sprites.

8bpp is also a definition, so you have 4 major definitions.

I think I do have single definitions (unless I don't understand what you mean by that); [temperate_grass_0] is one type of terrain (namely no grass at all) and it defines the all parameters of all 4 sprite sizes. The 5 other temperate terrain types are basically the same, and will re-use the [terrain] section. Terrain types of other climates will also re-use the [terrain].

I think the biggest difference is that my alternative makes it explicit (and quite transparent) how you get from that single definition to a set of real sprite definitions. It will cost some code to implement it, but your expansion code also costs code, and you then have to write expansion code for every type of feature (eg sea-coast has 9 sprites, depots have 6 sprites). In my case, you just add some more INI sections and you're done.

Another consideration is that somewhere along the project we may find things are not so nicely organized as you'd want. With some more INI sections, you can work your way around it easily. If you hard-code the expansion, you need to change program code for that special case without breaking everything else that uses the same code. This is mainly why I switched from programming Python code to defining stuff in a data file format. It's mostly transparent, and almost everybody can understand how it works, and write new definitions.

I picked feature as elementary value as that's how things are organized usually, eg the sprite-sheet of OpenGFX goes per feature.
For maintenance it is also easier to group things in this way.


To give you (and others) an idea of what to generate: This is sprite 3941. The final 3 lines are zBase graphics (with the major things changing for each sprite: the sprite label 'spr3941', and the '0096' number of the .png file), the first one is the OpenGFX sprite (where almost anything can change between sprites, except the filename since it uses sprite sheets). The numbers between [ and ] have been copied from its repo (manually).
The code in OpenGFX is not directly usable, as it defines sprites as 'baseset' rather than 'replace', and the name "spr3941" does not exist there.

So I see currently no other alternative than to add OpenGFX sprites into the equation, rescue the magic values like "1357, 1, 64, 31, -31, -8" from its source and insert them into the generation process.

CargoLiner wrote:the biggest hurdle would be to itemize and group them into replace and alternative graphics blocks (along with if statements for different climates)

Yep, but there are no 'if' statements though, everything is one big blob of sprites; the game knows which sprites to use in which climate.

CargoLiner wrote:if we are doing more than just replace graphics in the NML then that's a different kettle of fish, but i was lead to believe this is a base graphics replacement project

I think so too

OK i forgot about the 8bpp stuff

need some time to chew through this, i understand the need for data-centric system, but it seems an awful lot of work required for just the 8bpp stuff, i was hoping someone could just dump the info into a file we can cross reference (after all this information should be static and not changing) otherwise your decentralizing this information across a variety of sources

New approach, just extend the opengfx nml sources.

It seems that having a file format for storing the real sprite numbers/names was a bridge too far. Only a 1 time generation step is needed, which obviously makes all effort for generation useless.

Alberth wrote:New approach, just extend the opengfx nml sources.

Maybe that would be simplest!

Simplest? sure.

Let's just hope you want to keep the opengfx sprites, or else I have to do it all again

Alberth wrote:Let's just hope you want to keep the opengfx sprites, or else I have to do it all again

I think opengfx sprites are the right choice

I have made a few buildings and tested out a render template for taller objects. All seems good! .blend1 and .blend2s are now removed from the repo, should help a lot with storage usage.

I also tested out a render template for multi tile objects... Seems ok too.

When toying with the code, I noticed that some of the ground sprites are slightly mis-aligned in their file, giving gaps between tiles (one pixel too high in 1x view).

Merge OpenGFX and zBase and apply this hacky patch and build to see (I'll try to identify the proper offsets and sprites later). It's not a principle problem (could be solved by making the sprite template more lengthy, but... )

EDIT: I actually created a screenshot...

Hmm, looks like I miscalculated the slope height I'll give it a look.

All these graphics look awesome! Great work everyone!

Zephyris wrote:

Alberth wrote:Let's just hope you want to keep the opengfx sprites, or else I have to do it all again

I think opengfx sprites are the right choice

Moving doors and windows are right too then?

An oil well, graphics by Zephyris of course. The base plate is still 8bpp

@Zephyris: FYI: I am throwing problems that I find in the zbase issue tracker.

Alberth wrote:@Zephyris: FYI: I am throwing problems that I find in the zbase issue tracker.

Perfect.

Zephyris wrote:Hmm, looks like I miscalculated the slope height I'll give it a look.

I am struggling on the maths to work out the height slopes should be, can anyone give me a hand? If I am working with a 1x1 ground tile how high should the top of the slopes be?

ok if i understand this correctly

each tile is defined as 16 units by 16 units and each height step is 8 units, if we use the wiki definition that each ground tile is 12.5m x 12.5m in size then the top should be at the 6.25m mark, just off the top of my head....

Zephyris wrote:I am struggling on the maths to work out the height slopes should be, can anyone give me a hand? If I am working with a 1x1 ground tile how high should the top of the slopes be?

A flat ground tile at normal zoom has 64 pixels across and 31 pixels from top to bottom. A raised/lowered corner has an offset of +/- 8 pixels compared to the flat corner.

-- Michael Lutz

CargoLiner wrote:ok if i understand this correctly

each tile is defined as 16 units by 16 units and each height step is 8 units, if we use the wiki definition that each ground tile is 12.5m x 12.5m in size then the top should be at the 6.25m mark, just off the top of my head....

Please forget any scale in real-life dimensions quickly - whatever value you attribute there, it will always be more wrong than right (the wiki does a very bad job here, it seems)