Grf Codec keeps screwing up my sprites! there all distorted!

[That Guy]

I've been using Photoshop CS3 to draw my sprites, and I've used the correct Palette and swatches. I've saved my file as a .PCX Image and wrote my .NFO which is just below. And i double checked the .NFO with the NFO Editor 1.2.0. i've checked everything in my process!

Going in they look like this:


and they are acompanied by this .NFO:

Code: Select all

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 6)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
    0 c:\grfcodec\sprites/Mark1.pcx 1 1 01 21 8 -4 -10
    1 c:\grfcodec\sprites/Mark1.pcx 10 1 01 16 21 -10 -8
    2 c:\grfcodec\sprites/Mark1.pcx 32 1 01 12 31 -15 -6
    3 c:\grfcodec\sprites/Mark1.pcx 64 1 01 16 21 -10 -8
    4 c:\grfcodec\sprites/Mark1.pcx 86 1 01 21 8 -4 -10
    5 c:\grfcodec\sprites/Mark1.pcx 95 1 01 16 21 -10 -8
    6 c:\grfcodec\sprites/Mark1.pcx 117 1 01 12 31 -15 -6
    7 c:\grfcodec\sprites/Mark1.pcx 149 1 01 16 21 -10 -8
    8 c:\grfcodec\sprites/Mark1.pcx 1 23 01 21 8 -4 -10
    9 c:\grfcodec\sprites/Mark1.pcx 10 23 01 16 21 -10 -8
    10 c:\grfcodec\sprites/Mark1.pcx 32 23 01 12 31 -15 -6
    11 c:\grfcodec\sprites/Mark1.pcx 64 23 01 16 21 -10 -8
    12 c:\grfcodec\sprites/Mark1.pcx 86 23 01 21 8 -4 -10
    13 c:\grfcodec\sprites/Mark1.pcx 95 23 01 16 21 -10 -8
    14 c:\grfcodec\sprites/Mark1.pcx 117 23 01 12 31 -15 -6
    15 c:\grfcodec\sprites/Mark1.pcx 149 23 01 16 21 -10 -8
    16 c:\grfcodec\sprites/Mark1.pcx 1 45 01 19 8 -4 -9
    17 c:\grfcodec\sprites/Mark1.pcx 10 45 01 15 19 -9 -7
    18 c:\grfcodec\sprites/Mark1.pcx 32 45 01 12 27 -13 -6
    19 c:\grfcodec\sprites/Mark1.pcx 64 45 01 15 19 -9 -7
    20 c:\grfcodec\sprites/Mark1.pcx 86 45 01 19 8 -4 -9
    21 c:\grfcodec\sprites/Mark1.pcx 95 45 01 15 19 -9 -7
    22 c:\grfcodec\sprites/Mark1.pcx 117 45 01 12 27 -13 -6
    23 c:\grfcodec\sprites/Mark1.pcx 149 45 01 15 19 -9 -7
    24 c:\grfcodec\sprites/Mark1.pcx 1 65 01 19 8 -4 -9
    25 c:\grfcodec\sprites/Mark1.pcx 10 65 01 15 19 -9 -7
    26 c:\grfcodec\sprites/Mark1.pcx 32 65 01 12 27 -13 -6
    27 c:\grfcodec\sprites/Mark1.pcx 64 65 01 15 19 -9 -7
    28 c:\grfcodec\sprites/Mark1.pcx 1 85 01 19 8 -4 -9
    29 c:\grfcodec\sprites/Mark1.pcx 10 85 01 15 19 -9 -7
    30 c:\grfcodec\sprites/Mark1.pcx 32 85 01 12 27 -13 -6
    31 c:\grfcodec\sprites/Mark1.pcx 64 85 01 15 19 -9 -7

But for some reason when they come out of Grf codec again they look like this:

[DaleStan]

Going in they look like this:
Image
<...>
But for some reason when they come out of Grf codec again they look like this:
Image

Your "images" are singularly unhelpful. Try posting 8bpp PNG files on a server that works. TT-F, for one.

[FooBar]

While I'm not able to see your image, the most likely cause is that you've drawn the sprites in the Windows palette, but forgot to instruct GRFCodec to use the actual Windows palette: it uses the DOS one by default. Try this:

Code: Select all

grfcodec.exe -e -p 2 nameofgrffile.grf

[That Guy]

if your saying you can see them then i don't know why, they on Google's picasa web albums. I can see them just fine.
but I'll just up the PCX Files.

looks like i left the windows instruction out, how ever i was getting the same results with Grfwizard and it is set to windows

[Lakie]

Simple answer, the source file should have a width which is divisible by 4, the width you use isn't hence the causing it to skew everything.
Try changing the width to 172 pixels and see if that helps.

~ Lakie

[DaleStan]

Or you could use an image editor that doesn't output weird PCX files. GIMP is known not to have this problem.

[FooBar]

Wait a minute...
Now that I've seen the images (copying the address to a new tab did the trick). If I understand correctly, you encoded your grf, and then decoded it again and opened up the pcx file finding your sprites in a different order?
Yes, that's what grfcodec does. It's a feature greatly reducing the filesize of the grf, as it does not have to store the original pcx file, but a much smaller equivalent.

Just don't decode your own grfs. There's no use for that.


EDIT:
@DaleStan: There's nothing wrong with PhotoShop's PCX output. I'm using that for years for drawing grfs without any problems of any kind.

[DaleStan]

That is caused when giving grfcodec PCX files that:
1) have a width that is not an integer multiple of four, and
2) were generated by one of several different programs, including (some versions of) Photoshop.

Trust me, I've seen this multiple times before. Resaving the file with GIMP has worked every time. Having the original user resave the file with a multiple-of-four width has also worked every time.

Figure out how the output of GIMP (which works) and Photoshop (which quite obviously does not) differ, and maybe I'll look into fixing grfcodec.

Now that I've seen the images (copying the address to a new tab did the trick). If I understand correctly, you encoded your grf, and then decoded it again and opened up the pcx file finding your sprites in a different order?

And no. Look at the second file a little bit more closely. "In a different order" is not the problem, unless you're speaking of individual pixels within a sprite.

[That Guy]

thanks everyone

Simple answer, the source file should have a width which is divisible by 4, the width you use isn't hence the causing it to skew everything.
Try changing the width to 172 pixels and see if that helps.

thanks Lakie i think thats my problem

Wait a minute...
Now that I've seen the images (copying the address to a new tab did the trick). If I understand correctly, you encoded your grf, and then decoded it again and opened up the pcx file finding your sprites in a different order?
Yes, that's what grfcodec does. It's a feature greatly reducing the filesize of the grf, as it does not have to store the original pcx file, but a much smaller equivalent.

Just don't decode your own grfs. There's no use for that.

the reason i decompressed them after was just to check and make sure that the sprites weren't damaged (which is an understatement here ) I know that Grfcodec is for compressing them and resorting them to minimize the grf size, i just don't want trains that look like strange pieces of blown glass. I must admit the its a bit weird encoding then decoding, for me its just a safety check.

And yes Photoshop is an expert at producing PCX files. its only after there out of grfcodec that they become distorted, based on my own mistakes this time, but thanks Gimps a nice program, but i like Photoshop CS3 better

anyway thanks you guys. I'll get the rest of it programed up and let you guys grab the train if you want it.

~CHEERS

[DaleStan]

And yes Photoshop is an expert at producing PCX files.

That it may be, but it does something that grfcodec doesn't like when it generates non-multiple-of-four widths.

its only after there out of grfcodec that they become distorted,

No, it's when grfcodec read the PCX that the distortion happened. The decoding is correct; this can be confirmed by grf2html, or, if you make a valid newgrf, TTDPatch or OpenTTD

[That Guy]

well its all good, it compiled the grf properly this time

but i got a new snag guys, i don't know if your still down to give me a had but i can't figer out these values for new properties

for example how does c0 00 = 192?

C0 00 <Value>: Value for Speed (192 Km/h)

[michael blunck]

This is a really old bug which I thought had been removed from grfcodec since a long time as well. It has nothing to do with Photoshop per se but can be produced by using any other graphics program. It´s just the width of the resulting picture that matters, as Lakie said.

regards
Michael

[Lakie]

for example how does c0 00 = 192?

C0 00 <Value>: Value for Speed (192 Km/h)

First point, you will need to understand hexadecimal (as it is used a great deal in nfo).

Code: Select all

Breaking down decimal (calculator can do this),
192 / 4096 (4th nimble of word (16^3)) =  0, r 192
192 /  256 (3rd nimble of word (16^2)) =  0, r 192
192 /   16 (2nd nimble of word (16^1)) = 12, r 0
  0 /    1 (1st nimble of word (16^0)) =  0

Thus we have 0, 0, 12, 0.
In hexadecimal values between 10 and 15 are letters A to F.
Thus the value in hexadecimal is 0, 0, C, 0. (0x00C0).

For nfo, this needs to be stored in little endian style,
which means writing it in reverse pairs.

Continuing our example,
0x00C0 becomes 00 C0

Now we reverse the ordering,
C0 00

Of course with newer grfcodec versions, you could just write:
"\w192" and let grfcodec do that for you.

Secondly, each property will be in a pair (well it can be considered as the following):
<property number> <value> [<value for id 2> ... etc],

Thus for speed, we have "09 C0 00" or "09 \w192".

Hope that helps,
~ Lakie

[DaleStan]

It has nothing to do with Photoshop per se but can be produced by using any other graphics program.

If it's not Photoshop, then why does it work properly if I re-save the PCX with GIMP? Without changing the width.

And yes, I did test that less than a minute ago.

[FooBar]

Look at the second file a little bit more closely. "In a different order" is not the problem, unless you're speaking of individual pixels within a sprite.

I'd better shut up now...

[michael blunck]

If it's not Photoshop, then why does it work properly if I re-save the PCX with GIMP? Without changing the width.

And yes, I did test that less than a minute ago.

Well, I don´t know, because I neither use Photoshop nor theGimp for this kind of work [*]. Have you checked both for differences in output of a "test" image?

[*] generally, I convert to .pcx by using irfanview.

regards
Michael

[Wile E. Coyote]

Hint:
Decode any GRF (preferably smaller) and then load obtained PCX in Photoshop. You can draw in it and later encode without problems. If image is not big enough, you can allways change image size, but pay attention not to change width. Of course, you can there paste sprites from file above. I allways did that and never had problems.
In this particular case, you can even paste your sprites from image "before" to image "after" and when you encode it, all will be fine. That image "after" could be your starting drawing board for future.

[michael blunck]

In response to Wile´s post and in an approach to further clarify my post above:

This bug isn´t due to Photoshop or any other graphics program. It has been in grfcodec since its first version developed by Josef. In those early years, I have tried numerous graphics programs (except the Gimp, which was quite uncommon for Windows back in 2003) and that bug was always there.

Like Lakie said, it seems to be simply dependant on image widths not divisible by 4.

regards
Michael

[That Guy]

yay! it worked after i made the graphic divisible by 4. I got my train roughly done and running in openttd now i'm just trying to figure out the coding, with is proving to be tricky! Don't worry i'll figure it out, I think i just set my goals to high on this one. I wanted a Train with two engines (front/back) but i didn't want the rear engine to just be a mirror of the front engine. as you can see in my sprites i have another version of the engine that has flashing lights; Its suppose to be at the end. i just don't know how to set it up that way . and another thing, i don't know how to set up a callback to make the power car show up every few passenger cars.

jeeze i sound hopeless!

just give me a bit, maybe i can figure it out....

[That Guy]

for example how does c0 00 = 192?

C0 00 <Value>: Value for Speed (192 Km/h)

First point, you will need to understand hexadecimal (as it is used a great deal in nfo).

Code: Select all

Breaking down decimal (calculator can do this),
192 / 4096 (4th nimble of word (16^3)) =  0, r 192
192 /  256 (3rd nimble of word (16^2)) =  0, r 192
192 /   16 (2nd nimble of word (16^1)) = 12, r 0
  0 /    1 (1st nimble of word (16^0)) =  0

Thus we have 0, 0, 12, 0.
In hexadecimal values between 10 and 15 are letters A to F.
Thus the value in hexadecimal is 0, 0, C, 0. (0x00C0).

For nfo, this needs to be stored in little endian style,
which means writing it in reverse pairs.

Continuing our example,
0x00C0 becomes 00 C0

Now we reverse the ordering,
C0 00

Of course with newer grfcodec versions, you could just write:
"\w192" and let grfcodec do that for you.

Secondly, each property will be in a pair (well it can be considered as the following):
<property number> <value> [<value for id 2> ... etc],

Thus for speed, we have "09 C0 00" or "09 \w192".

Hope that helps,
~ Lakie

It did help a lot actually, thanks Lakie