GRF encoder tool: GRFMaker [under development]

[Ameecher]

I seem to be quite regularly getting 'Out ofMemory' error when using GRFMaker.

Could be that you have a sprite line where not every sprite starts at the same row, I think I got "Out of memory" when I had that.

That's what I thought of too. I get that too when the sprites are not at least 2px apart.

[Tom0004]

is there anywhere we can get a hold of this program ?

or to we still need to get intouch with Szappy, i only ask as it seems he's not been to the forums for awhile.

if so, can some on please PM me his email address,

i've emailed his MSN/WLM address given by the site, but have yet not received a reply,

also sorry for bumping what seems to be a dead topic now

regards

0004tom

[Purno]

I'm trying to get an updated version of GRF Maker too. PMing Szappy doesn't help at all...

[BobDendry]

There is no updated version. gl2 and Szappy haven't been seen in a long time.

[Purno]

I did have a somewhat older version (3.01B), I now was able to get v3.03B, which was an updated version for me

[Tom0004]

There is no updated version. gl2 and Szappy haven't been seen in a long time.

then how would one recomend, one getting his hands on such a program ?

[Purno]

One recommended me to get in touch with Aegir.

[Aegir]

[rant]

NO!

Stop telling people to ask me for the program! I I only host it, I am not allowed to distribute it for people, everyone has to get permission from Szappy and gl2, I have no authority on the matter. I am getting tired of having to answer PM and Emails constantly, and having to tell them the same thing over and over.

I'm only allowed to hand it out, really, to TTDPatch developers and other such 'gurus', basicly, to people that the GRFMaker devs couldn't possibly say no to.

To be honest, GRFMaker is of very little use* in it's pre-alpha testing stage if Szappy and gl2 aren't around. Nobody else has the source to it, so when bugs are found, or features are missing (That happens quite a lot), you're stuck having to either: a) kludge it, b) write it in a manual NFO block, or c) sit on your hands and wait.

For the hideously ultra basic operations people are trying to use GRFMaker for (Simple sprite replacements), really, write it in NFO. Really. GRFMaker is not some magic bullet that will eradicate having to understand the mechanics of NFO. At the end of the day, you still need to learn the language. GRFMaker just makes it easier to build and manage large sets, so that you can focus on things like your action2 chain logic instead of something like syntax and endianess.

*Note, for trains and vehicles, you're largely safe, since a lot of features for trains have been around for a while longer than newstations, newhouses, newindustries, et cetera. But still, you're stuck working on your own, the only two proficient vehicle coders I know who use GRFMaker are Whitehand and AndersI, but their knowledge is limited in comparison to Szappy and gl2, and trust me, you will have questions that only they, or a TTDPatch Dev/Guru NFO coder can answer, and getting help from a TTDPatch Dev or Guru NFO coder still requires you to [img]know%20NFO[/img].

[/rant]

[Purno]

the only two proficient vehicle coders I know who use GRFMaker are Whitehand and AndersI

Well, I seem to be able to code quite nicely with GRF Maker too...

[jvassie]

the only two proficient vehicle coders I know who use GRFMaker are Whitehand and AndersI

Well, I seem to be able to code quite nicely with GRF Maker too...

Plus Hyronymus and I have been coding in for quite a long time too..

[Aegir]

Indeed, I can count lots of other people who use GRFMaker to great effect, but I still vote Whitehand and AndersI as being probably being my top two coders using GRFMaker. Whitehand especially when it comes to helping other users with their coding. When he isn't being a prat, that is.

[AndersI]

Sure, GRFMaker is not a substitute to learning NFO coding, but it really does help me. My Swedish trains wouldn't be coded at all if it wasn't for GRFMaker. Period. Plain NFO coding is too time consuming. I don't want to count bytes, convert numbers to hex, write opcodes as hex bytes etc. I want to code my trains and get them into the game (with as many features as I can learn). But that's another - unfortunately quite dormant - thread here on the forums.

It is a pity that the development of GRFMaker seems to have stopped without the source being released to let others continue - being a Delphi programmer both by profession and hobby, there sure are things I would like to 'fix'.

[Csaboka]

It is a pity that the development of GRFMaker seems to have stopped without the source being released to let others continue - being a Delphi programmer both by profession and hobby, there sure are things I would like to 'fix'.

Actually, I do have the sources of v3.03, with some modifications added. The modifications are there for the bugs and limitations that came out while coding TTRS3. Working around all of them would have had ill effects on my sanity...

I respect gl2 for working on this program so much, but to be honest, the source code is horrible. Variable and function names with 1-3 characters for a name, almost no comments, huge case statements instead of object hierarchies and virtual methods, hard-coded "magic" limits, to mention the worst ones. (One example: 2500 entries should be enough for everyone, right? Except that TTRS3 uses 3460...)

My personal opinion is that we would be better off with developing an open-source alternative from scratch. Delphi may not be the best choice for the language; C++ with a cross-platform library would probably be more flexible. (I have installed wxWidgets and did some small experiments, it is probably good for the job, and porting to Linux should in theory only need a recompile.) I don't really have time to do it myself currently, though. The foundation of this program could be shared with the "human-readable NFO" compiler, which was discussed in another topic.

[DaleStan]

I don't want to count bytes,

You don't have to. Not since November of 2004 have you had to count bytes.

convert numbers to hex,

You don't have to. This is more recent, but it's still been over a year since NFORenum and GRFCodec learned to read decimal numbers.

write opcodes as hex bytes

What do you mean by "opcodes"? If you mean the <op>/<operation> bytes in adv. var2, 7, 9, D, and GRM, you don't have to. At least in most cases. A few outliers still don't have escapes, but those are the new ones that GRFMaker wouldn't know anyway.

[AndersI]

Delphi may not be the best choice for the language

Delphi is always the best choice of language

Jokes aside, C++ may be better if portability is important, sometimes it is, sometimes it isn't. My guess is that the 'target customers' for GRFMaker are probably mostly Windows users, so I still think a 'Windows only' version is much better than 'no version at all'.

In theory, Pascal can also be portable, using for example FPC (Free Pascal Compiler), but as I have no experience with it, I don't know how it works out in reality. In theory, Delphi programs should be 'easy' to port to FPC...

@DaleStan:Sorry, it seems I haven't really read up on the capabilities of GRFCodec - actually I'm at a loss where the documentation and examples are found, can't find much in the TTDPatch Wiki. And http://www.ttdpatch.net/grfcodec/ doesn't seem to have much either, unless you count the change history. http://www.tt-forums.net/viewtopic.php?f=26&t=26846 is a discussion thread, searching for GRFCodec gives too many results, searching for "grfcodec documentation" gives too few. Where should I look?

[DaleStan]

The NFO spec is a good place to look. "grfcodec -?" may also contain UI.

Looking at the first two pages of posts in which I've said "grfcodec", and some link chasing, turns up:
http://users.tt-forums.net/dalestan/grf ... sions.html
http://www.tt-forums.net/viewtopic.php?f=26&t=24845
http://www.tt-forums.net/viewtopic.php?f=26&t=26338

I haven't updated the first one in ages, but what it specifies is correct.

[AndersI]

OK, so of the documents you recommend,

- one "isn't updated in ages" (but correct as far as it stands)
- one is a proposal with no reference to if and when it was/will be implemented
- one is a thread where I can find the sources to a revision that implements (most of?) the proposal (probably)
- one is the 'official' thread for grfcodec (probably), but it stops at version 0.9.9
- the link in your sig takes me to a page showing version 0.9.10, this page leads to three other documents, also describing some aspects of grfcodec (but not the proposal).

Thanks for the link digging, but this is leading off in too many directions. I'd prefer one 'master document' where I could find everything that is relevant for the current version. Like:

- Purpose (we all know that)

- How to use (encoding, decoding)

- Extensions to the plain NFO format (which 'shortcut' constructs exists, what output options creates which extended format, etc.)

- Advanced use (the more esoteric options)

- Revision history

Keeping that one, single document in one well documented place would make it possible for others to 'keep current' with the capabilities of grfcodec.

[DaleStan]

- Purpose (we all know that)
- How to use (encoding, decoding)
- Extensions to the plain NFO format (which 'shortcut' constructs exists, what output options creates which extended format, etc.)
- Advanced use (the more esoteric options)
- Revision history

As you said, we all know #1, so I'll leave that one alone.

#2 and #4, are, IMO, properly documented on the other end of "grfcodec -?", and that's where you'll find them. You'll also get basically the same result if you run grfcodec with no arguments. And there aren't really that many esoteric options. -b and -u are probably the most esoteric, and they're also among the oldest.

#3 is documented on the wiki. If you want to know about the extensions that are useful in advanced variational action 2s, see "VarAction2Advanced". If you want the extensions that are useful for GRM, see the GRM documentation. And so on. The assumption here is that if you can remember which byte does what, you don't need the extensions, but if you can't, you're going to be looking them up on the wiki, at which point you'll get both the byte and any meaningful alternative formats.

There is one exception, though: If you want the extensions that only NFORenum recognizes, read the NFORenum docs, which are not on the wiki.

#5 is found in the same place as the grfcodec download. Or, if you want the version that applies to the most recent public source of GRFCodec, it's in svn, and a more detailed version is here, though it may be harder to extract the signal from that list.

Feel free to mash these all together into one place, but I guess I don't personally see the point. Everything's exactly where I'd expect to find it, and keeping up multiple sets of documentation is

[BobDendry]

The one biggest trouble with GRFMaker users at present is that they expect it to be the holy grail of coding, ie "Plug sprites in and out pops mah GRF". It doesn't work like that. While NFO isn't required per se, if you want any support whatsoever from the real NFO wizards such as DaleStan or Pikka, you're going to have be able to talk to them in atleast basic NFOspeak. With Szappy and gl2 out of the picture as of late, your best bet for support for GRFMaker is myself, AndersI and Aegir. Aegir is certainly the best if you're after support for anything stationary pretty much, though I can swing around the Industry sprite blocks if you so desire. For vehicles, you definitely want myself or AndersI, depending on what timezone you're in, for the best and quickest reply.
That said, the best way to learn GRFMaker well is to just stuff around with it until you find out what you're trying to do. I can honestly say that, along with A LOT of help with Aegir, is what set me onto the path to the competent coder I am today.

[Csaboka]

Good news for the GRFMaker users!

GL2 has agreed to release the source code of GRFMaker under the terms of GPL v3. This means that someone who can code in Delphi and is willing to fight the bugs can take over development.

The source code can be downloaded from my TT-Forums webspace. The only modifications I've done to it is adding a small readme, copyright notices required for enforcing the GPL and the text of the GPL itself.

Anyone downloading the sources please be aware that the code is often cryptic, contains some Hungarian identifiers and the few comments in the code are all in Hungarian. I can help with the meanings of Hungarian identifiers and comments, but you have to cope with cryptic code yourself