GRFCodec 6.0.3

[stevenh]

Sure... it'd still be nice on the download page to link to this file where possible?
It's not the easiest one to find? Or I just didn't look hard enough.

Either way, I got my sprites out of an ageing GRF. NML to the rescue, I hope.

[Edd.Dragon]

Oh, I just dl grfcodec 5.1.3 (released on 2011-12-20 16:24 UTC) and it don't ask dll-s. All reqired functions are imported in exe. All ok.
Size of this grfcodec.exe = 803035 bytes.

[stevenh]

Oh, I just dl grfcodec 5.1.3 (released on 2011-12-20 16:24 UTC) and it don't ask dll-s. All reqired functions are imported in exe. All ok.
Size of this grfcodec.exe = 803035 bytes.

Pikka has now also received this error on both nforenum and grfcodec... it does seem that the DLL is not linked in.
Edd.Dragon, you've somehow got the DLL in your 'PATH'... so it works for you.

[PikkaBird]

Edd.Dragon, you've somehow got the DLL in your 'PATH'... so it works for you.

I found just dropping libgcc_s_dw2-1.dll and libstdc++-6.dll in the grfcodec directory was sufficient to get it working. Would be nice if they were built in though.

Edit: for those having trouble finding them, attached. Found on the internet no guarantees etc.

[Edd.Dragon]

Edd.Dragon, you've somehow got the DLL in your 'PATH'... so it works for you.

Yep, I forget about it. Not long ago I configured IDEs for building OTTD from them and setup PATHs to mingw and msys

[Rubidium]

Today GRFCodec 6.0.1 was released. This is a minor maintenance release with primarily fixes to the GRF container version 2 implementation and NFORenum validation data updates.

[Supercheese]

Ah, thanks, I was wondering why certain .grfs wouldn't decompile with 6.0.0. Everything appears to be fixed now.

[YukonRob]

I'm having palette problems with GRFCODEC (6.01 and previous nightly). When I use grfcodec -d -p1 filename.grf I seem to get a png with a win palette but it was indexed to a dos palette (or some such - it has lots of pinks and when I manually apply a windows palette to it in gimp or PS or Fireworks it looks fine). If I use grfcodec -d -p2 filename.grf the file opens as expected (Win palette) in gimp and if I apply a dos palette manually it looks like the file created by -p1.
Am I missing/misunderstanding something?

[Michi_cc]

The -p option doesn't do any palette conversation, it simply tells grfcodec what palette to add to the output file. If you want to convert things, there's the -m (I think) option.

[YukonRob]

Thanks - worked. I see the -m option now. The help was a little ambiguous (-p : use this palette instead of the default). Is there any way to tell which palette a grf is encoded in without trial and error?

[Eddi]

if it is a recent GRF (less than 2 years), it may have an action 14 telling the paliette, then OpenTTD will tell the palette in the NewGRF list. older GRFs should have it in the filename, then it would end in "w" if it's windows palette.

[wallyweb]

On December 28, 2010 I encoded TTD_landscapew.grf. (using one of the version 5 GRFCodec/nforenum)
This file works in both TTDPatch and OpenTTD.
Yesterday I began updating the file and now it works fine in OpenTTD but it crashes TTDPatch.
I am using GRFCodec 6.0.1 r643 and the nforenum version that came with it.
Currently the only changes between the two nfo files are:
Action 8:
From:
2 * 128 08 07 "WB" 51 20 "TTD Landscape Objects v2.0 - Windows"
to:
2 * 128 08 07 "WB" 51 30 "TTD Landscape Objects v3.0 - Windows"

And

Action 0 Property 08 Class Label:
From:
"TTDX"
to:
"TTD3"

Everything else is identical.
The attached zips contain the respective GRFs, NFOs and the TTDPatch Crash Log.

I have coded other GRFs using my current GRFCodec/nforenum installation without problems so assuming I need to rework my code, the problem is that neither nforenum nor grfcodec identify any errors that might point me in the right direction. Also why does OpenTTD accept the new file but TTDPatch does not?
Any suggestions?

[Yexo]

The grf files are almost binary identical. Notable changes are the ones you pointed out in your nfo file and a few bytes due to grfcodec r920. Unfortunately there don't seem to be any nightlies available from before that change. I'll have another look later to see if that's the actual problem.

[wallyweb]

The grf files are almost binary identical. Notable changes are the ones you pointed out in your nfo file and a few bytes due to grfcodec r920. Unfortunately there don't seem to be any nightlies available from before that change. I'll have another look later to see if that's the actual problem.

Would this be of any help?

[frosch]

Now, this seems to be an very interesting case of how information spreads

1. Let's start with this page http://www.ttdpatch.net/grfcodec/grf.html which appears like an "offical" documentation of the GRF format.
The important half sentence on this page is "or 0x80 bytes of verbatim data if code==0." in the description of the (de-)compression algorithm.

2. In 2007 I wrote grf2html based on this description of the format, and grf2html decodes TTD_landscapewNew.grf just fine. (the half sentence is important for decoding the file)

3. In 2007 OpenTTD (for version 0.6) got a new blitter implementation, which included reimplementing the GRF decoding, apparently using above page.

4. Newer grfcodec have a slightly improved compression algorithm, which makes use of above corner case.


However:
5. The "grf.txt" description of the GRF format in the grfcodec/TTDPatch repository does not contain that half sentence.

6. OpenTTD < 0.6 does not implement that half sentence.

7. If old OpenTTD doesn't implement that, TTD and thus TTDPatch most likely don't either.


So, .... what and where does the "grf.html" specification come from? And why does it not match "grf.txt" And how could it happen that the information from there slowly spread to OpenTTD and other tools


Edit: Given the dates at the bottom of "grf.html" and "grf.txt", the "grf.html" file is newer. Did patchman plan changing the format in this corner case, but never did?

Edit2: The oldest source code of grfcodec I can get hold off (June 2002) implements the special case for decoding already.

[Yexo]

And how could it happen that the information from there slowly spread to OpenTTD and other tools

How it spread to OpenTTD I don't know, but to other tools (ie grfcodec) that's easily explained. I read that webpage when implementing the grf output support in nml, thought it was a nice case and implemented it. From the beginning I've only tested the resulting NewGRFs with OpenTTD which had no trouble loading files created with that trick. Since it results on average in slightly smaller grf files grfcodec later implemented that trick too so output from nml and grfcodec would match again (and be both as optimal as possible).

Edit2: The oldest source code of grfcodec I can get hold off (June 2002) implements the special case for decoding already.

And that's the second reason why nobody has noticed before.

Thanks for the detailed research frosch

[wallyweb]

I hope this helps ...
I did the grf from scratch but with only one sprite, the communication tower, to keep things simple.
It still crashed.
Then I replaced the comm tower sprite with a flat rock sprite.
Everything else was left the same.
This one worked in TTDP.
Here is the difference:

Code: Select all

7 C:\MPS\trg1r.pcx 2 9640 09 90 63 -30 -78 // Communication tower
compared to
7 C:\MPS\trg1r.pcx 242 13320 09 31 64 -31 -0 // Flat rocks

The zip has the GRF and NFO.

TTD_landscapew3.zip

(3.6 KiB) Downloaded 142 times

EDIT (24/10/2012): Until this is resolved I have gone back to GRFCodec v5.1.0 while staying at NFORenum 6.0.1 r943. This works.

[frosch]

I've fixed this in r949, maybe you want to try some nightly in the next days.

[wallyweb]

I've fixed this in r949, maybe you want to try some nightly in the next days.

I would try it now if only I could find the download.
The link in the first post points to http://dev.openttdcoop.org/projects/grfcodec where there is a nightly download link that points to this page that says:

The grfcodec-trunk release is newer than the last grfcodec-nightly release. Please use the grfcodec-trunk release.

which is at r948.

[Alberth]

Nightlies are normally automagically build at a (mostly) fixed time once every 24 hours (if a commit has been done since the last nightly).
As a result it may take up to 23 hours (and 59 minutes) after a commit before a new nightly becomes available.

In other words, try again after waiting for a while