Transport Tycoon Forums

Hi all,

Thanks to more work by DaleStan, I'm pleased to announce the release of GRFCodec 0.9.9. Get it at http://www.ttdpatch.net/grfcodec/ if you're working with .grf files.

This new version checks the palette of any PCX files while encoding to make sure you're not accidentally using the wrong palette, and can now read GIMP palette files as well.

It reads and writes Info version 7 (by default), which makes writing NFO code a little easier by introducing several escape sequences. See the wiki at http://wiki.ttdpatch.net/tiki-index.php ... nsDetailed for more details.

All changes in 0.9.9 (r653)
- By patchman:
- Check for sprites that extend beyond the end of the PCX file.
- Update versioning system to show last-comitted revision for non-release builds.
- By DaleStan:
- (devel) Add release targets to the Makefiles
- Check the palette of the PCX file before encoding from it.
(Override a failed check with -f)
- Introduce several backslash escape sequences; see the wiki for further information.
(disable with -x or -xx)
- Do not apply colormap to sprites that like character glyphs.
(Apply colormap to all sprites with -M instead of -m)
- Enable reading of GIMP palette files with -p.
- (devel) Terse build mode; get the verbose mode with make V=1.
- (devel) Touch version.h if and only if it changes.

slight niggle.

PCX format is nasty, since its about the only graphics format you can't actually save in using paintbrush. any chance of the option to use PNG files as an alternative?

reason for posting here as oposed to somewhere else is that i can't find a topic spacific for sugestions on GRFCodec.

That's in progress, and I was hoping to get it done for this release, but I was pointing too many people to my build just after implementing the palette check, so I decided it was time for a release.

My local copy is in the particularly useless state of reading only PNG files, and writing only PCX files, and it's not going to get off my computer in that state.

DaleStan wrote:That's in progress, and I was hoping to get it done for this release, but I was pointing too many people to my build just after implementing the palette check, so I decided it was time for a release.

glad to hear it

DaleStan wrote:My local copy is in the particularly useless state of reading only PNG files, and writing only PCX files, and it's not going to get off my computer in that state.

yer, it sounds kinda useless

thought I would post this to help just in case...

IrfanViewer can open pcx and save them to several more common formats...on top of several small tools its got itself

Erm...?

http://www.irfanview.net/

regards
Michael

Since I did not find a more suitable thread, I'm posting my problem here.

When encoding a set of sprites (attached pic, bottom row) with 0.9.9 r652 and decoding it again, the sprites contain some pixels in magic pink (top row). However, this only happens when decoding with the "-p2" option, when decoding without it, I get the original sprites. This happens regardless of the settings used for encoding, i.e. with "-p2" as encoding option as well as without using any options. The sprites use the correct windows palette.

Now, this would not be a problem, since I do not have any artifacts in the game, but I have been shown a screenshot where the magic pink pixels are replaced by black ones, which looks somewhat ugly around the roof. However, I have been unable to reproduce this behaviour ingame.

So, what might be causing this behaviour? And what is the magic pink for? The wiki only says "windows api", which does not tell me too much.

I'll need the PCX file for sure. I may need the NFO and command line too, but I won't know for sure until I see the PCX.

The first two pinks are used by character glyphs, but I don't know what use the others serve.

Here it is, nfo + pcx file, and the files resulting from encoding and decoding: for "withparams.pcx" -p2 was used for both encoding and decoding, "withoutparams.pcx" was done without giving any parameters (i.e. grfcodec - germanrv.grf), the last one was the result of supplying parameters only for encoding.

It looks like as long as I always specify -p2, it works correctly.

Uwe wrote:When encoding a set of sprites (attached pic, bottom row) with 0.9.9 r652 and decoding it again, the sprites contain some pixels in magic pink (top row). However, this only happens when decoding with the "-p2" option, when decoding without it, I get the original sprites.

Are you sure you didn't get that backwards? Because if you did get it backwards, then everything is functioning as designed. grfcodec is not smart enough to determine the correct palette from a grf file, so you have to tell it to use the Windows palette when decoding.

-p is not an encoding switch, so it should not effect the encoding.

As for the magic-pink turning black, who posted that, and were they using TTDDOS or TTDWin? There are several magic-pinked sprites floating around in there, and one of the things that TTDWin's magic-pinks do in TTDDOS is turn black.

Ah yes, I mixed that up, decoding with -p2 was ok, without it, pixels got changed and magic pink or wrong colours were introduced. So far I have now understood what's going on.

I'll ask the one who pointed the glitches out what version he was using to produce the mistakes, but I'm quite sure now it was only a missing palette parameter. This is also where the sprites with magic pink in it come from, but these will be changed anyway.