OpenGFX - Graphics Base Set

[planetmaker]

As it stands now, I have to measure the size & offsets of each

Those are already in the grf I linked, aren't they? Or have I misunderstood something here?

A grf contains all that information and it's moderately easy to de-compile it in order to retreive them. So yes, a grf will do fine.

EDIT: In principle the copy&paste approach in order to obtain a grf as you describe works. You'll need an action 08, though, which defines the grf. There are a number of examples of simple, separate grfs in the OpenGFX repo (in sprites/nfo).

[Ammler]

Best would be a NewGRF, then we have the pcx and the alignment, all in one.

OK... Do you have any hints on how to best/easiest make a NewGRF out of the grf/pcx/nfo files I have now?

Should I just copy the relevant sprite lines from the base nfo to a new file and encode (with grfcodec) a grf from that?

As example my monolev newgrf:
http://trac.openttdcoop.org/browser/grf ... emonolevba

It is very basic ActionA

As attachment the final nfo which will be used from grfcodec.

Greets
Ammler

[edorfaus]

A grf contains all that information and it's moderately easy to de-compile it in order to retreive them. So yes, a grf will do fine.

Well, the grf I was thinking about is here (as linked in the earlier post). It's the whole ogfx1_base.grf though, just with my sprites pasted in and reencoded. Which I guess can get annoying to extract things from...

EDIT: In principle the copy&paste approach in order to obtain a grf as you describe works. You'll need an action 08, though, which defines the grf. There are a number of examples of simple, separate grfs in the OpenGFX repo (in sprites/nfo).

As example my monolev newgrf:
http://trac.openttdcoop.org/browser/grf ... emonolevba

It is very basic ActionA

OK, I'll read up on this stuff a bit and see what I can come up with.


EDIT:
OK, I think I've got something now... Started with a .nfo from the repo, modded the Action8, used grfdiff to get the sprite numbers and grepped those lines into the new nfo, and modified the ActionA appropriately (I hope; dec2hex by hand...), then ran nforenum and grfcodec on it. I seem to recall reading about a parameter to one of these that stripped out unneeded transparency (there is some), but couldn't find it in my versions...

wrapping.grf

NewGRF for toyland house wrapping

(36.63 KiB) Downloaded 107 times

In case anyone's interested, the changed sprites are: 4627-4628, 4630-4631, 4633-4634, 4636-4637, 4639-4640, 4642-4643, 4645-4646, 4648-4649, 4657-4658, 4666-4667, 4669-4670, 4672-4673, 4695-4696 (26 total)
(I found a grd-to-grf converter, but it didn't work and was closed-source :/ (maybe I should write my own, shouldn't be that hard...))

[planetmaker]

Thanks for the grf It _really_ made it easy and I added them in r147.

Here how it looks ingame:

Buildings with wrapper 1

Anderburg Transport, 08-05-1980.png (83.41 KiB) Viewed 5639 times

Buildings with wrapper 2

Anderburg Transport, 18-06-1980.png (42.85 KiB) Viewed 5652 times

I still like the idea with some bow added to the still closed boxes.

[Ammler]

We got permission from Varivar to use his 32bpp church for opengfx. I just resized his png to "our" size and converted to 8bpp. Here the result:

trop_4604_church.png (1.86 KiB) Viewed 5329 times

If someone is able to make it better, please go on, we got the whole source pack from varivar. Everything available at our DevZone: https://dev.openttdcoop.org/issues/150

Greets
Ammler

[edorfaus]

I have an svn version of grfcodec, which warns about pure-white pixels in sprites. One of the reasons it warns about this is that the pure white isn't faded out when TTD fades to black. (The other one is that pure white pixels is usually a typo on the real-sprite.)

Running encode on OpenGFX (r149) (right after decoding) gives warnings about 450 sprites that contain pure white (338 of them in base.grf).

Do we want to do something about this? (E.g. replace the pure white (#FF, i255) with the visually identical almost-pure white (#FC, i15)?)

I suppose there might be some sprites we don't want to do this on, even if we want it for most, but I'm not sure which that would be...

[planetmaker]

I have an svn version of grfcodec, which warns about pure-white pixels in sprites.

Certainly makes sense to have a closer look. The question is whether the result shows or whether it doesn't. There might be some unreported or unseen bugs or glitches there Having it build without warning is certainly also desirable.

Btw, is that grfcodec version (already) official trunk of grfcodec and if so which version? I didn't upload anything newer ( http://dev.openttdcoop.org/bundles/grfdev/ ) than r2127 / r2125 as I didn't see any functional change.

[Ammler]

Do we want to do something about this? (E.g. replace the pure white (#FF, i255) with the visually identical almost-pure white (#FC, i15)?)

Do you have an example?

Greets
Ammler

[edorfaus]

Btw, is that grfcodec version (already) official trunk of grfcodec and if so which version? I didn't upload anything newer ( http://dev.openttdcoop.org/bundles/grfdev/ ) than r2127 / r2125 as I didn't see any functional change.

Well, assuming svn://svn.ttdpatch.net/misc/grfcodec is the official trunk, yes... I grabbed from there and compiled myself (because I wanted it on a 64bit Linux install that doesn't have 32bit libs installed).
Currently using revision 2156 (well, 2155 has the latest change inside that subtree), which came about due to an issue I had with nasm (it didn't want to link for 64bit implicitly, so I sent a patch he ended up not using). I see no changes between that and r2125 in svn, and this change was only for 64bit compiles, so what you have should be the same for all practical purposes. (I didn't know about that link btw, I used the old 0.9.10 before compiling myself.)

Do you have an example?

Well, sprites 1313 to 1405 (road sprites) have some pure white in them; seems to me it's the center line (that's it in 1313 at least).

To get a visual comparison of the suggested fix (replacing i255 with i15), I made an image with the original and changed versions side by side (can you see any difference?):

comparison-1313.png (1.65 KiB) Viewed 4827 times

After this change, this line is no longer output by grfcodec:

Warning: 8 of 1984 pixels (0%) in sprite 1313 are pure white

[planetmaker]

Well, assuming svn://svn.ttdpatch.net/misc/grfcodec is the official trunk, yes... I grabbed from there and compiled myself (because I wanted it on a 64bit Linux install that doesn't have 32bit libs installed).

Ok. Actually I get those warnings, too, but considered them "normal" If they can be made to go away, it would IMO be nice.

To get a visual comparison of the suggested fix (replacing i255 with i15), I made an image with the original and changed versions side by side (can you see any difference?):

comparison-1313.png

I don't see any difference.

[mrMann]

I *think* that one of them is a shade darker, and that the kerbing is 1 pixel wider on one of them. But otherwise, they look very similar...

[AndersI]

The *only* difference is that the left one has the color <252, 252, 252> for the center line, the right one has <255, 255, 255>. No other pixels differ

[Zephyris]

There really is no perceptible difference, and if anything it softens the harshness of the white lines in the road. I say change all the 255 pixels to 253 if it stops the error messages...

[Ammler]

If we do that, we would need to do it with all:

> cat opengfx-nightly-r149-compile.log | grep white | wc -l
450

Would be a bunch of work...

Ticket created: http://dev.openttdcoop.org/issues/352

Greets
Ammler

[DaleStan]

> cat opengfx-nightly-r149-compile.log | grep white | wc -l
450

Would be a bunch of work...

Well, some. Open each image in GIMP. Use the Color Select tool (Shift-O), with the threshold set to zero, to select everything that's #FFFFFF. Use the Fuzzy Select tool (U), with the threshold set to zero again, to unselect the contiguous background block, and then use the Paint Bucket (Shift-B) tool to fill the entire selection with #FCFCFC.

This, in a couple minutes, fixes all internal whites, without concealing any warnings about sprites that include the background.

Then save, encode, and manually fix the remaining ones.

In a test of ECSTownw, GIMP removed 88.2% (990 of 1122) of the pure white pixels, completely fixing 71.5% (30 of 42) of the sprites, and removing 84.0% (695 of 827) of the white pixels from the remaining 12 sprites.

[LordAzamath]

And while at it, he even doesn't have to unselect the background as that won't be encoded anyway, correct?

[Rubidium]

And while at it, he even doesn't have to unselect the background as that won't be encoded anyway, correct?

He has, otherwise he's going to remove the 'correct' warnings also.

[Ammler]

It might be a easy task, if we decode the base grfs and do that conversion, it is a havy task if we would still use our splitted source.

It doesn't help a author like FooBar, as he has the whole file blue, not just the sprite.

[FooBar]

With help of a photoshop action I think it's five minutes work to change all existing (splitted) pcx files. Four minutes recording the action, one minute executing it on all opened files...

I don't have photoshop (or hg for that matter) on the netbook, but I can give it a go once I'm back from the States (in about a week or so). Since it's no showstopping but, I think it can wait if noone else is interested in fixing it.


By the way, I don't have the whole file blue usually

[Noldo]

I tried DaleStan's way, works nice enough, but the #FFFFFF colored pixels inside the sprite number will be recolored.