The attached patch fixes 2 things:
1)
Currently, images in pak file stores the x-offset, but the image data has not trimmed the left transparent pixels according to the x-offset (by trim, here just means reducing the length of the first clear run), which is somewhat inconsistent. Left-trimming is nevertheless done, but postponed to the reader, which has to go through the image data again to do the trimming, which is inefficient.
This patch moves the left-trimming function back to the writer, which is more efficient and make the pak file image consistent in itself.
2)
For each image line, if the last sequence of pixels are transparent before the line break, the lengths for the clear run and the colored run are still appended to the image data. However, they are actually superfluous and waste harddisk space, memory, and processing time, albeit the impact is rather small.
Anyway, waste is waste and we should avoid it, and this patch also eliminates such useless image data.
I have made 2 tests and here are the outcome :
Fabio's wholesale material warehouse => before : 535KB ; after : 522KB
Pak64 factories all in 1 pak file => before : 743KB ; after : 706KB
I have tested those output files and they work without problem in Simutrans.
May I know if the above patch is really incorporated in trunk? I can't see it in the repository at the moment.
Actually I want to add something to this patch (namely, to apply point 2 above to rezoom_img() as well), but since it has never been moved to the considered patch section, I thought it was rejected and thus didn't bother to do it.
Sorry, apparently moved to the wrong board .. should go to considered.
Never mind, Dwachs, and thanks for your clarification. :) I will issue a new patch then with the aforementioned addition.
Sounds like a good patch, thank you for cleaning up these parts of the code :)
Thanks, Hajo. :)
An updated patch as described above.
It looks like TileCutter (does that use the standard writer code?) can produce many identical 'squares' -- particularly blank ones, or when parts of a large image repeat in the various rotations.
Any thoughts on whether checking and re-using identical picture segments would be worthwhile in terms of space?
Identical pictures are checked by the register_image routine and will be merged in the program. That way is most effective, especially for empty asphalt/gr****/water (****uming standard water is used).
You may wish to test it also with my latest electronics plant, as it is a rather huge image...
Thanks for your suggestion :). Results are :
Before : 1823KB vs After : 1770KB
53KB (2.9%) reduction in size
Actually, the percentage of reduction does not vary much even if there are more tiles of images inside the pak. It depends more on the tile size -- you can expect relatively higher reduction rate for pak64 than for pak128, as there are on average fewer coloured pixels per pixel line in pak64 image tiles.
Anyway, the percentage of reduction will not be large. But if we think in this way -- that we have removed 53KB of garbage data from the pak file -- this cleaning up is still worthwhile.
TileCutter doesn't make .pak files directly, but rather uses Makeobj to achieve this, so any optimisations made in Makeobj will apply equally to TileCutter-produced buildings (TileCutter doesn't attempt to optimise its image output for exactly this reason).