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:
Code: Select all
replace spr3941(3941, "../opengfx/sprites/png/terrain/bare-03-temperate.png") { [1357, 1, 64, 31, -31, -8] }
alternative_sprites(spr3941, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "../zbase/terrain/terrain_temperate/64_0096.png") { [0, 0, 64, 64, -31, -32] }
alternative_sprites(spr3941, ZOOM_LEVEL_IN_2X, BIT_DEPTH_32BPP, "../zbase/terrain/terrain_temperate/128_0096.png") { [0, 0, 128, 128, -63, -64] }
alternative_sprites(spr3941, ZOOM_LEVEL_IN_4X, BIT_DEPTH_32BPP, "../zbase/terrain/terrain_temperate/256_0096.png") { [0, 0, 256, 256, -127, -128] }
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