Page 1 of 2
GrfMaker revival - call for test data
Posted: 09 Sep 2007 09:25
by AndersI
As you might have seen, the GrfMaker project has become open source. To ensure that we don't break the program, we need real test data:
Working GrfMaker projects (.lst + .pcx) in all categories (trains, stations, houses etc.) for testing that we don't break GrfMaker with our changes.
To make sure we have something to do

we also need:
Projects and images that exposes bugs in GrfMaker. Note that we're not interested in coding questions/problems in general, only in .lst files and .pcx files that (against expectations) don't work in GrfMaker.
If you have any of the above, and want to contribute, just PM the complete project to
belugas or
AndersI and we will add it to the test battery in the svn repository for GrfMaker.
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 10:19
by BobDendry
If you need a large scale train set, I offer you all of my NSW Set working files. Also, if you need and Industry/Cargo set, I can offer selection of that aswell. Industry tile action 0s are broken, I might add.
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 11:36
by jvassie
As alternate train material i can offer my whole Swiss Set work..
Also a few vehicle grfs too.
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 16:59
by Purno
AndersI, do you still got the .lst of the Dutch Trainset I sent you a while ago, or do you wish to receive it again?
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 17:09
by AndersI
WhiteHand, jvassie: Yes please.
Purno: Yes I still have them, but I think you have made many changes since then, increasing the complexity, so it might be better to have the latest version.
If you send something that breaks GrfMaker, please add a note explaining the problem!
Stations, houses, aeroplanes, ships (and whatever more there is that I forget) anyone?
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 17:57
by DJ Nekkid
am i correct if i say that this program can program grf files with a somewhat simple GUI?
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 17:59
by AndersI
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 18:08
by DJ Nekkid
ill take that as a yes

Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 20:36
by AndersI
As I said in the PM, GrfMaker is not a substitute to learning NFO coding, it is a helper program. Some people like the more 'visual' view, the dialogs to fill in instead of remembering hex codes, etc.
I don't know right now how distribution of the compiled program should/will be handled, but as I said in the other GrfMaker thread - Don't ask for beta versions, they will be released when they are ready to be released. Also, the source is freely available to all (see the other GrfMaker thread) and CodeGear (formerly Borland Developer Tools Division) offers a free download of Turbo Delphi 2006 Explorer, so anyone interested enough can get a working copy that way.
I'm not a distribution center for GrfMaker, that should be solved in some other way.
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 21:08
by DJ Nekkid
AndersI wrote:GrfMaker is not a substitute to learning NFO coding, it is a helper program. Some people like the more 'visual' view, the dialogs to fill in instead of remembering hex codes, etc.
Tho it will make the job prolly a lot easier for someone (like me) that is total noob on the issue. I hope.

Still need to learn the basics behind it, but as u say, its more a visual view of things, thus makeing it easier to keep overview. And probably some general entries are there by default and such. (?)
Re: GrfMaker revival - call for test data
Posted: 09 Sep 2007 22:40
by belugas
Learning Visual Basic does not remove the need to learn Basic...
Using GRFMaker does not removes the necessity to learn NFO even more.
Therefore, it is not a JackOfAllTrade kind of tool.
You NEED to know what you are doing, and how.
Re: GrfMaker revival - call for test data
Posted: 10 Sep 2007 07:13
by BobDendry
I have conditions attached to the use of the NSW Set in GRFMaker tests.
Firstly, it is not to leave the development circle.
Secondly, I will not tolerate it being used for recreational purposes by ANYONE except those who have my express written permission.
Re: GrfMaker revival - call for test data
Posted: 10 Sep 2007 15:36
by AndersI
Seems reasonable to me.
Re: GrfMaker revival - call for test data
Posted: 10 Sep 2007 15:51
by belugas
I agree too. This is understandable.
Re: GrfMaker revival - call for test data
Posted: 10 Sep 2007 17:15
by Csaboka
I can offer the sources of TTRS3, if you're interested. Beware, though, that the thing is HUGE (both by filesize and by the number of entries). I had to increase the internal limit of entries just to allow working on it when I hit the old limit.
It would be useful for testing future performance enhancements - currently, it takes minutes to create a GRF from the source, using the maximum compression option. Creating a GRF with no compression takes one second or two.
Re: GrfMaker revival - call for test data
Posted: 10 Sep 2007 18:24
by AndersI
Csaboka, that sounds like the perfect test case! Pushing the limits, and providing a baseline for future optimization work.
Edit: BTW, I think I have cut a bit on the GRF compression time now...
Re: GrfMaker revival - call for test data
Posted: 11 Sep 2007 06:48
by Csaboka
Luckily, I have the sources on my USB stick, so you don't have to wait until Friday, when I can get back to my computer. The source isn't for the absolutely latest version, I think, but it is very close. You can get it from
http://users.tt-forums.net/csaboka/ttrs3_source.zip
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. I don't know what exactly GRFMaker is doing, but I suspect it's very inefficient at it. Similarly, double clicking on one of the big sprite blocks, you have to wait ages to get into the sprite list window. For example, the first big sprite block (entry 21) has 240 sprites on a 682x5405 BMP file, and it takes some ten seconds to open the sprite list window. This is especially annoying because, when adding building action2 blocks, you don't have any way to tell which sprite has which index; I had to start another instance of GRFMaker just to paste the big sprite block into it, and have it open while I was doing the real work in the first window.
OK, enough whining for now
I hope the LST works with the official GRFMaker version. I've done some modifications on my sources, and I can't test the LST with the offical version right now. I suspect you'll get a "List index out of bounds" error when first loading it, and you'll have to increase the array whose access caused the exception.
Re: GrfMaker revival - call for test data
Posted: 11 Sep 2007 17:25
by AndersI
Csaboka, is this the exact sources used to create the ttrs3.grf available on the home page? Otherwise I'll need the grf from you, too. We need the reference grf to make sure our modifications to GrfMaker aren't destroying anything.
Edit a bit later: It's OK, the GRF from the web page and the one produced with my modified GrfMaker are identical.
Time to open the project on my computer: ~8 seconds
Time to produce the GRF on my computer: ~1 minute.
Side note: The bookmarks are a neat thing I didn't know existed in GrfMaker - I must say, 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!
Another side note: 92% of the total time of loading TTRS3 and compiling the GRF is spent in one single routine in the compression code. Is there a description somewhere of the GRF compression scheme? I'd rather read the definition than deduce from the code what it does.
Re: GrfMaker revival - call for test data
Posted: 11 Sep 2007 20:28
by Dropzone
AndersI wrote:Is there a description somewhere of the GRF compression scheme?
Is
this what you're looking for?
Re: GrfMaker revival - call for test data
Posted: 11 Sep 2007 20:35
by Csaboka
AndersI wrote:Another side note: 92% of the total time of loading TTRS3 and compiling the GRF is spent in one single routine in the compression code. Is there a description somewhere of the GRF compression scheme? I'd rather read the definition than deduce from the code what it does.
The description of the basic GRF format is distributed with GRFCodec, if I remember correctly. The same text file is included in the GRFCodec sources, you can
view it on-line from the repository. 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. I guess the busyest part of the compression is searching for the next byte in that buffer.