GRF encoder tool: GRFMaker [under development]

[Purno]

Sounds very interesting, good work!

[krtaylor]

I have a question, bearing in mind that I do not know a lick of Delphi, and know nothing about it as a coding language.

I know that there are some converters and tools to convert code, or at least to assist in converting, to and from C and C++. Is there any such thing for Delphi, and would that be a good idea? Because I'm guessing that there are more people around who are familiar with C and its derivatives, than are familiar with Delphi. Is that even feasible?

[Csaboka]

Borland has a product equivalent to Delphi, but using C++ as a language; it's called Borland C++ Builder. There might be tools that convert code between Delphi and C++ Builder; I don't know about any of them, though.

Even if there is a converter, you will still need knowledge about the VCL (Visual Control Library, the library behind Delphi and C++ Builder), so a usual C++ coder still can't work on the code. Additionally, these converters tend to output ugly code, since there are Delphi idioms that don't have a C++ equivalent, and the coding style is different.

Simply put: the best you can get is C++ code that still uses the "Delphi mindset", and that still depends intimately on Borland libraries to work. I'm not sure it's worth doing that.

[BobDendry]

This is excellent news. Now, we can finally see some updates to the product, bugfixes and the like.

[belugas]

I feel like a kid in a candy store!
I have my copy of GRFMaker and already started to read (and guess content of) all the units.

Which brings me to a question : does it mean the original authors have decided to give up on deving?
If so, how can the work can be organized around it?
Should it be put on a svn server?

I'm already doing some cleaning

[Csaboka]

Which brings me to a question : does it mean the original authors have decided to give up on deving?

GL2 said that he doesn't have time to work on it nowadays, so I think it's safe to assume he gave up. Even if he decided to continue later on, he could still benefit from the work others did on his code.

If so, how can the work can be organized around it?
Should it be put on a svn server?

You can do anything with it as long as you don't violate the GPL. This means the source code must be available for all distributed executables, you must not remove the name of the original author (László Gombos), and you must have your name in the modified version to indicate that GL2's code has been modified.

Personally, I think it's too much hassle to put it on an SVN server until someone else shows interest in working on the code.

[Rendall]

Good news indeed. As I am not a coder and just started drawing, making grf's is too hard for me at this very moment. But in future it might be very handy too have such a tools to do the simplified vehicles yourselve. Coders can use there little time in coding more difficult objects. May I suggest an online translator Hungarian to English? If there is any it might very handy allthough sometimes maybe very odd translations..

[Csaboka]

I wouldn't trust those translators, even if there are such things for Hungarian. Especially that since Delphi doesn't support non-English characters, you have to "shave" accented characters. (For example, "állomány" becomes "allomany", "hozzárendelő" becomes "hozzarendelo" etc.) A translator program has an even harder job when it has to guess which accents were shaved off the word. There are even cases where different characters become the same when shaved (ó, ö and ő all become o; ú, ü and ű all become u)...

[belugas]

Little information for those who would like to work on the code, it requires at least Delphi 7.
GRFMaker uses some events/properties not available in Delphi 5 or 6. Since i do not have higher version then 7, i cannot tell.
But for sure, 7 works fine i.e: compiles/executes without errors.
So, if anyone want to join on the developpment, you know which version you need. And don't be afraid to raise a hand

By the way, do not ask for anything (features/bug reports) out of it right now. There are some knowledge that has to be acquired before doing anything realy meaninfull out of it. Although it does not seems to be so complicated.... I have the big lines already figured out.

[Hyronymus]

It would really be nice if this tool became a well-maintained tool again so I hope someone is wiling and able to step in.

Belugas, I know you said not to annoy you with requests but I made a big discovery today with GRFmaker. Or should I say small because the unzipped lst file for the Dutch Trainset is 4.49MB in size while zipped only 62kb.

[belugas]

Since I'm quite more fluent in Dephi then C/C++, i'm trying to give some fresh air to the project yes.
"Annoy" would not the best term. Let say that i'd rather start by getting familliar with it before going on the chase.
Correcting bugs to something that you do not really know (yet, if not at all) and maybe causing more wrong than good is what I fear the most at the moment...

But, OTOH, I could read back the entire history of this topic, at some point
Time will tell.

[AndersI]

Little information for those who would like to work on the code, it requires at least Delphi 7.
GRFMaker uses some events/properties not available in Delphi 5 or 6. Since i do not have higher version then 7, i cannot tell.

It compiles without errors in the free Turbo Delphi 2006 Explorer (http://www.turboexplorer.com/). I haven't had the time yet to check that it works, ie. produces the same GRFs as the 'official' version. It would probably be good to have a repository of GrfMaker projects that work, and run some verifications when changes have been made.

It certainly has a programming style of its own, looks like it started in the old Turbo Pascal days. It will take some time to even begin thinking of doing changes...

[belugas]

Yup.
The main target of work, as I see it, is to give the baby a big injection of OOP
Various areas can benefit of it.
That will give the code less of a volume and more of an immediat visual (code wise) impact.
The series of if can be changed to a few big case statement. That, at least will immediatly benefit on the execution time.

By the way, I really like your idea of a verification run between new and old version. I think it wild be named regression test or something like that

As for the coding style, indeed it should be maintained as it is. Not my style but, like Dalestan, i can be a chameleon regarding that

[Csaboka]

the unzipped lst file for the Dutch Trainset is 4.49MB in size while zipped only 62kb.

This is another "feature" of GRFMaker. The data for every entry is padded with zeroes, so every time an entry needs new data fields, you can just use up some bytes from the padding. In most cases, the padding is almost as big as the useful data. This wastes memory as well as disk space, and definitely needs to be fixed.

Until there is a correct fix, you can work around the problem if you have NTFS filesystem on your hard drive. By setting the "compressed" flag on LST files, Windows will practically zip the file, while still allowing programs to read it as if it was a normal file. The TTRS3 LST file is 4MB, but takes only 500K when enabling compression on it. It can be shrunk to 94K with the best compression setting of ZIP.

As for the coding style, indeed it should be maintained as it is. Not my style but, like Dalestan, i can be a chameleon regarding that

I don't think the coding style should be maintained if it feels uncomfortable to you. I personally don't like the style, but I'm not the one who wants to maintain it

[AndersI]

As for the coding style, indeed it should be maintained as it is. Not my style but, like Dalestan, i can be a chameleon regarding that

Depends on what you mean with 'coding style'. Replacing if-sequences with case is changing the style, isn't it? Replacing all the dynamically created dialogs and other windows is a huge job, with no benefit at all to begin with. But the day you want to change the layout, use standard tools for translation (dxGetText + poEdit) and so on, it would be much easier. There should definitely not be multiple languages coded into the executable, as it seems to be now.

Anyway, there are lots of things that can be done without going into large changes - I count 101 warnings about 'variable may not be initialized', 'value is never used', 'comparing signed and unsigned...' etc. I think this is the first part to dig into, making it a bit more robust.

I also have some ideas about making the sprite editor a bit more efficient on larger images (I have one of my own, half written, lying around somewhere), but I wonder if anyone is really using the sprite editor inside GrfMaker? Maybe it should be taken out completely?

Also, replacing the .lst format with a human readable one should have high priority (IMO). It will make it easier to verify that a modified version still works (easier to run regression tests).

OK, those are just a lot of first impressions - maybe the 'GrfMaker revival' should have a thread of its own?

[DaleStan]

I also have some ideas about making the sprite editor a bit more efficient on larger images, but I wonder if anyone is really using the sprite editor inside GrfMaker?

If it worked, I'd probably use it instead of GIMP for some things. GIMP is really a bit overweight for editing TTD sprites, but when the choice is "wait a minute for GIMP to start" or "Wait an hour for SpriteEdit to flood-fill", the choice is pretty obvious.

[Ameecher]

I only rarely use the sprite editor but it is useful when I spot something a bit wayward as I import the .bmp file or after I've coded it and can then do a little touch up without having to reimport the bitmap again.

[Hyronymus]

I only use the sprite positioning tool and it would be great if the 2 versions that exist within the game would be united.

If you click on a vehicle sprite block you see the xrel and yrel values of the sprites in a table on the bottom left (green box). On the right side of it is a column which allows the editing of the xrel and yrel position (red box). You can click a row in the bottom left table and then adjust the values followed by Apply. But you can also select a row in the bottom left table, click position and then change the xrel and yrel position using a "guiding rail". The latter is much easier and perhaps some space can be created to make it available straight away. Basically the entire blue box would be available for a more easy-to-use alignment tool.

It would also be nice if you could select multipe sprites to edit their xrel and yrel values simultaneously. But now I'm really pushing my luck .

[AndersI]

But now I'm really pushing my luck .

Yes, you certainly are . Also, you're forgetting that other people may use GrfMaker in other ways, or be working with larger sprites:

Example11.png (29.95 KiB) Viewed 3117 times

I think we'll have to keep a low profile on the wish lists, bugs are more important (and hopefully easier to fix).

[Hyronymus]

Meh, people should obey the rules I propose (now) and use smaller bmp's .

Now I'm back working with GRFmaker I'll try and find some juicy bugs.