OpenGFX - Graphics Base Set

Discuss, get help with, or post new graphics for TTDPatch and OpenTTD, using the NewGRF system, here. Graphics for plain TTD also acceptable here.

Moderator: Graphics Moderators

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9425
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by planetmaker »

edorfaus wrote:
planetmaker wrote: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).
Last edited by planetmaker on 23 Jul 2009 23:41, edited 1 time in total.
User avatar
Ammler
President
President
Posts: 953
Joined: 18 Jun 2006 18:18
Location: Switzerland
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by Ammler »

edorfaus wrote:
Ammler wrote: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
Attachments
ogfx-monolev-ba.nfo
(3.45 KiB) Downloaded 94 times
edorfaus
Engineer
Engineer
Posts: 16
Joined: 13 Jul 2009 17:18

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by edorfaus »

planetmaker wrote: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...
planetmaker wrote: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 wrote: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 89 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...))
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9425
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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
Buildings with wrapper 1
Anderburg Transport, 08-05-1980.png (83.41 KiB) Viewed 4777 times
Buildings with wrapper 2
Buildings with wrapper 2
Anderburg Transport, 18-06-1980.png (42.85 KiB) Viewed 4790 times
I still like the idea with some bow added to the still closed boxes.
User avatar
Ammler
President
President
Posts: 953
Joined: 18 Jun 2006 18:18
Location: Switzerland
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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
trop_4604_church.png (1.86 KiB) Viewed 4467 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
Engineer
Engineer
Posts: 16
Joined: 13 Jul 2009 17:18

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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...
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9425
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by planetmaker »

edorfaus wrote: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.
User avatar
Ammler
President
President
Posts: 953
Joined: 18 Jun 2006 18:18
Location: Switzerland
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by Ammler »

edorfaus wrote: 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
Engineer
Engineer
Posts: 16
Joined: 13 Jul 2009 17:18

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by edorfaus »

planetmaker wrote: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.)
Ammler wrote: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
comparison-1313.png (1.65 KiB) Viewed 3965 times
After this change, this line is no longer output by grfcodec:
grfcodec wrote:Warning: 8 of 1984 pixels (0%) in sprite 1313 are pure white
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9425
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by planetmaker »

edorfaus wrote: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.
User avatar
mrMann
Tycoon
Tycoon
Posts: 2793
Joined: 27 Oct 2006 20:38
Location: A house.
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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...
Hmm, what should I put here...
User avatar
AndersI
Tycoon
Tycoon
Posts: 1732
Joined: 19 Apr 2004 20:09
Location: Sweden
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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
Attachments
The two images subtracted and gamma adjusted to show the changed pixels.
The two images subtracted and gamma adjusted to show the changed pixels.
Image1.png (223 Bytes) Viewed 3827 times
User avatar
Zephyris
Tycoon
Tycoon
Posts: 2830
Joined: 16 May 2007 16:59

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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...
User avatar
Ammler
President
President
Posts: 953
Joined: 18 Jun 2006 18:18
Location: Switzerland
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by Ammler »

If we do that, we would need to do it with all:
console wrote:> cat opengfx-nightly-r149-compile.log | grep white | wc -l
450
Would be a bunch of work... :P

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

Greets
Ammler
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by DaleStan »

Ammler wrote:
console wrote:> cat opengfx-nightly-r149-compile.log | grep white | wc -l
450
Would be a bunch of work... :P
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
LordAzamath
Tycoon
Tycoon
Posts: 1656
Joined: 08 Jun 2007 08:00

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by LordAzamath »

And while at it, he even doesn't have to unselect the background as that won't be encoded anyway, correct?
PS: And I stopped the propaganda to support Dave Worley since he got a nice new red hat now.[/color]
I know I have a BBCode error in my signature but I really cba to fix it.
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by Rubidium »

LordAzamath wrote: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.
User avatar
Ammler
President
President
Posts: 953
Joined: 18 Jun 2006 18:18
Location: Switzerland
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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.
User avatar
FooBar
Tycoon
Tycoon
Posts: 6553
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by 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... :D

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 :wink:
Noldo
Engineer
Engineer
Posts: 75
Joined: 16 Jun 2005 13:17
Location: Lappeenranta, Finland

Re: [8bpp] Graphics Replacement Project - OpenGFX

Post by Noldo »

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

Return to “Graphics Development”

Who is online

Users browsing this forum: No registered users and 14 guests