PNGCodec

[glx]

Well it's not pngcodec that is broken, but the compile farm did something wrong.

Attached a working win32 pngcodec.

Edit: after reading the pngcodec compile logs, it seems the compile farm builds all version with its local g++ instead using the "host" one.

[Edit TrueLight] Compiled executables are now correct [/Edit]

[DaleStan]

That would indeed be a problem. I suppose that means that all the pngcodec builds, except for the x86 Linux one, are broken?

[PouncingAnt]

Thanks V much for the fix. Hope I my whining helped highlight the problem to some degree...

[athanasios]

Thanks glx.

[QtanJ]

I made a useless script to manage a lot of pictures at the same time. I thought it worked, but that the 32bpp engine was bugged so I posted it here. When I discovered that I had done something wrong I did a lot of work to try to fix it, and when I finaly decided to check how pngcodec actually worked I found that x_offs=-31 and y_offs=-32 worked. I even tried to use algebra to find out how I should calculate the y_offs from a croped image before I tried this.

The script isn't as useful as I thought when I first began to create it(since it is very simple), but I can provide it anyway, in case someone want to use it. But the only reason I didn't delete this was in case someone saw this post and wondered what the result would look like(someone with the same knowlege about pngcodec as when I started with the script)

Code: Select all

#!/bin/bash 

PNGCODECDIR="/usr/bin"
IMAGEFOLDER="trg1r"
	for i in $( ls $IMAGEFOLDER ); do 
		$PNGCODECDIR/pngcodec r $IMAGEFOLDER/$i x_offs=-31 y_offs=-32
	done

Edit: Replaced all content, because I didn't know what I was doing when I posted the first time, I only thought I did.

[TrueBrain]

There indeed was a bug on the compile farm, where the compiler of the host was used for all targets. This problem is now corrected and all produced binaries are for the target specified by their name.

[TrueBrain]

(..) x_offs=-31 and y_offs=-32 (..)

Just remember that the x-offs and y-offs can't be -31 by -32 for all images. It depends on the artist and which image he replaces what the offset should be. You might want to look at this list to see the x-offs and y-offs of all original grf images:

http://devs.openttd.org/~truelight/orig ... ffsets.txt

I myself use this script to give all images the offset as they were in the original grfs. This in no way is any guarantee the result looks correct!!!

http://devs.openttd.org/~truelight/orig ... offsets.sh

[n0k0m]

Can someone explain me how can i count x and y offs, again?

I tried to make the png with the same size as the original picture was (copied from the original decoded grf file). I used the original picture also (to test it) and the original picture's offs.

Than i used the pngcodec and i added that offs. It said it worked. So i copyed it back to the tar file, made the info (line copyed and modifyed from a working one).

Than add it to the cfg file.

ZOOM error allways...
And i tried it 213312 times, tried to count pixels and looked at many offs and pictures and still... i cant see logic in that (i su*k in math).

So please help

[Rubidium]

The tar and the extra zoom levels are of the obsolete 32bpp branch (pngcodec is not used there).
pngcodec is used for 32bpp images in trunk.

[n0k0m]

The tar and the extra zoom levels are of the obsolete 32bpp branch (pngcodec is not used there).
pngcodec is used for 32bpp images in trunk.

Oh! Is there a new way to do it? Where can i find a post about how to do it?

[TrueBrain]

The tar and the extra zoom levels are of the obsolete 32bpp branch (pngcodec is not used there).
pngcodec is used for 32bpp images in trunk.

Oh! Is there a new way to do it? Where can i find a post about how to do it?

Try the sticky just three posts below this one.... might be useful

[n0k0m]

Omg, Ban please. I am so blind today

[LordAzamath]

Hmm. I was pngcodecing some things and found out that there are image editors that support text fields in. I'm particulary talking about gimp here.
I post the screenshot here.

I don't know is it possible to change that line when saving files

Code: Select all

comment=created with the gimp

but if that can be done (I mean particulary that "comment=" side of that)
then gimpers can codec their pngs w/o pngcodec too.

I mean the comment should be replaced with x_offs or y_offs and the comment itself with proper values. Though I think it would be possible to give it only one field not both x and y
I'm not so sure

BTW the 32bpp pngs with that comment work with openttd too. So there is no need of removing these

[BlazE]

I don't know is it possible to change that line when saving files

You can change the comment for example with this GIMP plugin:
ecomment

[TrueBrain]

BTW the 32bpp pngs with that comment work with openttd too. So there is no need of removing these

OpenTTD ignores all fields besides x_offs and y_offs. So feel free to add any other field you like

[Slye_Fox]

Right.

How the hell do i use this dam thing?

I know it's a commandline program, but when i try and do anything on it's list i get this:

Code: Select all

'pngprops' is not recognized as an internal or external command,
operable program or batch file.

What does that mean?

And why doesn't this thing have a manual?

[Leviath.NL]

What OS are you using Windows XP? What command did you type in? For win32 I think it is

Code: Select all

pngcodec.exe a <filename>.png x_offs=xx y_offs=xx

You could also post your brickland rail sprites (in the brickland thread)and I'll pncodec them for you.

[Slye_Fox]

Allready figured out the problem,
I was typing 'pngprops'

[Wacki]

I have a question too:

[Slye_Fox]

I think the codec needs to be in the same folder as the file