zBaseBuild is just a repo for experiments in coding the zBase graphics. It started 2 days ago (one day at my local hard disk, and one day as zBaseBuild). So far, it's just doing some terrain sprites.
It assumes that ../opengfx is the OpenGFX repo, and ../zbase is the zBase repo, and pulls the 8bpp and 32bpp images from them.
Eventually, the build stuff will end up in either zBase or OpenGFX.
The first thing that I noticed is that the currently normal approach of using CPP for generating NML fails with zBase. Reason is that files like "64_0001.png" to "64_0024.png" contain 19 terrain sprites (yep, 5 are not used), but in CPP you cannot compute a file-number from a base+offset, and format it into a 4-digit number. (A pattern like "64_<type>_<number>.png" would have been much easier here.)
I can see two alternatives at this time:
- Python, a general purpose programming language, also highly usable for scripting. (Also used by NML, so no new dependencies.)
- m4, a dedicated macro processor.
Note that any solution MUST be cross-platform, Windows only, or Unix only is not going to work (although the latter is slightly less worse, as the servers for the nightlies all run Linux).
At this time, I opted for Python, as I am most familiar with it. Xotic750 has an m4 approach that I still have to look at.
My first attempt is to generate the right NML directly (basically a few 'print' statements with a table, and some start offsets and filenames), but it feels as being too low level, too many details to handle at the same time. On the other hand, it will be flexible, 'magic' like inserting a crop operation at some point will be easily possible.
'm4' is more like CPP, and may be easier to understand for non-programmers. On the other hand, the use of the right quotes at the right spot is critical, and m4 is not helping at all here, it happily produces horribly wrong output.
I am currently considering a more table driven approach, that is, you make a file with all the numbers, and a script produces the NML from it. Ideas are welcome, my experience in coding baseset-ish NewGRFs is about 2 days.
I am not doing any cropping at the moment, I let NML do that. the 'get_y_offset' was just for me finding a magic number
If you want to add cropping, please save the offsets in a file. It would be a huge waste of time having to find that information again. (This also fits nicely in a table driven approach
As for the backend, I currently generate NML, but it takes ages to compile. I have heard that grfcodec is orders of magnitude faster in processing. For something as simple as a bunch of real sprites, it might make sense to generate NFO directly. NFO does not do cropping afaik, so that needs to be inserted then.