Transport Tycoon Forums

AndersI wrote:...the more I look at the program, the more I appreciate the tremendous lot of work gl2 has put into it. Give him my best wishes!

Add me to the list of new fan! I forgot to mention that. The work done is incredible, the imaginative solutions to different problems encountered are fascinating too. I just hope we'll be able to make it even better

It is a real pleasure to play around with the code, and I feel priviledged to be able to contribute to this project, the same way I feel about been able to contribute to OpenTTD.

And a big thank you to all those who supplied test cases

Csaboka wrote:The basic trick is keeping 2K of the previous sprite data in the memory, and using two-byte "back pointers" instead of the data itself when the new data is already present somewhere in the buffer.

For more fun and games, you can even say "copy the next ten bytes from the buffer, starting three bytes ago". This type of encoding can save some space, but is probably more complicated than encoding that guarantees that the count is at least as large as the offset.

(If you ever decide to deal with decoding, note that if you've got equivalents to the C memcpy and memmove, neither are safe. The former has undefined behaviour in that circumstance, and the latter has the wrong behaviour.)

DaleStan wrote:This type of encoding can save some space, but is probably more complicated than encoding that guarantees that the count is at least as large as the offset.

From my experience, there is only little extra work in implementing this type of encoding strategy. In practice, when you use the maximum possible overlap that the format allows (15), you gain another 2-5% on the compression ratio.

I somewhat suspect that the current encoder in GrfMaker isn't very well done, since all the files I've seen produced by it were quite a bit bigger than what even grfcodec can produce.

You can have a look at my c++ implementation of grf encoder/decoder in it's repository. I haven't touched it for a while, and it could certainly use some work, since it's a bit on the slow side, but it does the job.

When I get off my lazy arse I'll re-upload my entire portfolio of sets I have coded in grfmaker. I still intend on swapping to full NFO (I devoted far too much time to my custom makefile), but my .lst's should be of use for grfmaker's development.

Csaboka wrote:While testing the sources, I was reminded to another annoying thing - the loading times are way too high. The LST has 3460 entries, and v3.03 needs 30 seconds to load it on this machine.

Just a little teaser: I'm down to ~30 seconds for the full cycle: start GrfMaker, load TTRS3, create GRF, close GrfMaker

That's with compiler optimizations ON, range and overflow check OFF. Flipping these three gives me ~52 seconds full cycle. If you compile GrfMaker yourself, check those settings.

Edit: After my latest changes the times are down to 23 resp. 34 seconds, so now the unoptimized compile is almost as fast as the optimized was previously...

any hope of getting road vehicle (trams) articulation in grfmaker. I got all of my set done in grfmaker and its a real handy program

That has exactly nothing to do with the topic. Go find the right topic next time.