.png sprite loading removed from OpenTTD

[studiocpb]

Hi,

Can you upload all sprites from the forums to the repo. All this sprites are otherwise not in the 32bpp GRF's.

this sprites:
http://www.tt-forums.net/viewtopic.php? ... 80#p884028
http://www.tt-forums.net/viewtopic.php? ... 83#p726083

and this GRF
http://www.tt-forums.net/viewtopic.php? ... 00#p898859

Can i Use the 32bpp without lines ground tiles as this GRF comes

[Alltaken]

You can already do that (more or less) with my Visual PNG codec program.

Ah cool, perfect!

[maquinista]

It would be nice to add a switch to GRF coded to enable a automatic loading of PNG sprites from TAR files.

I mean something like this:

Code: Select all

grfcodec -e myset.nfo -png file_with_32_bpp_sprites.tar

IMHO, rewriting a NFO file to add the code for 32 BPP sprites would be a lot of work.

[planetmaker]

How is that less work than referencing the files in NFO or NML?

Also it would yet again require a cryptic naming scheme for sprites. Something like the old scheme with spriteID-naming immediately breaks for any NewGRF if you only add one single pseudo sprite before the real sprite is referenced (like adding a single parameter, a single translation, a single compatibility check,... whatever).

After all you do not need all the steps with pngcodec anymore, one tool less to use. And you just edit and align everything in one place now: the nfo or nml file itself. Just like everything has been done for 8bpp sprites since the dawn of newgrfs.

[Alltaken]

So out of curiosity, what would be the process to add a 32bpp sprite to the game now?

Generate 32bpp sprites for:
256, 128, 64, 32, 16 pixel zooms?
Generate 8bpp sprites for:
64, 32, 16 pixel zooms?

Use newGRF editor to add images to newGRF file? This is a graphical interface where you can align things in it?

Load into the game and test?

Corect me where i am wrong.

Cheers,

[FooBar]

You must provide 8bpp normal zoom. All others are optional and your choice if you wqnt to provide thm or not.

Then write the appropriate NFO (or in the future also NML possible). Refer to the newgrf specs documentation on how to do this. It's not too complicated. Easier than pngcodec I think, as you can have one text file with all offsets.

There's no such thing as a 'newgrf editor'.

[planetmaker]

Generate 32bpp sprites for:
256, 128, 64, 32, 16 pixel zooms?
Generate 8bpp sprites for:
64, 32, 16 pixel zooms?

Why skip the zoom levels 4x and 2x for the 8bpp sprites?

The format for the real sprites is described in the specs, at the end is found an example: http://newgrf-specs.tt-wiki.net/wiki/Re ... version_32 where indeed the default 8bpp normal zoom is the only required image file, all other colour depths and zoom levels are optional.

Base grfs, with the exception of the extra grf, only consist of these kind of real sprites. You can use any plain text editor of your choice to edit an nfo or nml file.

[Rubidium]

This post contains the result of about two hours of writing scripts. It allows me to make a GRF of the PNGs in 32bit-gfx-nightly-megapack-2012-02-23.tar with two exceptions (see the bash script for details).

Warranty has already ended. There is no manual and it's likely buggy. It also needs a very recent OpenTTD (r23976 or higher), otherwise you're bound to get crashes. It uses basically everything NML has a depencies + grfcodec + pngcodec + bash/sed/awk.

[maquinista]

How is that less work than referencing the files in NFO or NML?

Also it would yet again require a cryptic naming scheme for sprites. Something like the old scheme with spriteID-naming immediately breaks for any NewGRF if you only add one single pseudo sprite before the real sprite is referenced (like adding a single parameter, a single translation, a single compatibility check,... whatever).

After all you do not need all the steps with pngcodec anymore, one tool less to use. And you just edit and align everything in one place now: the nfo or nml file itself. Just like everything has been done for 8bpp sprites since the dawn of newgrfs.

But... It means to rewrite lots of sprites on a NFO file.

I'm sorry, but I won't update my OpenTTD until I get a better way to create GRF files.

I will release the sprites in the current format (TAR), I hope that someone could create a tool to translate them to GRF files.
IMHO, PNG sprite loading is better to develop new 32bpp extra zoom sprites.

[FooBar]

I hope that someone could create a tool to translate them to GRF files.

Look 1 post above yours. Rubidium just did that 4 hours before your post

[Jupix]

This post contains the result of about two hours of writing scripts. It allows me to make a GRF of the PNGs in 32bit-gfx-nightly-megapack-2012-02-23.tar with two exceptions (see the bash script for details).

Warranty has already ended. There is no manual and it's likely buggy. It also needs a very recent OpenTTD (r23976 or higher), otherwise you're bound to get crashes. It uses basically everything NML has a depencies + grfcodec + pngcodec + bash/sed/awk.

If I understand this correctly, this is truly useful. Bear in mind that it's a bash script of nearly 100 lines and it looks like utter gibberish to me. Without you I'm pretty sure we wouldn't have had this in months. So thank you.

Since at least you understand what it does, I would suggest you write that manual now. That script should come with info on:
- what files is takes as args and how many
- what the tool used for
- what the resulting file is and what spec that file follows
- what version of the game the resulting file is compatible with
- what does it use as a "base" sprite (8bpp)? converts the 32bpp to 8bpp?
- does it generate the additional zoom levels on the fly?
- what naming scheme does it support for the png's? the "standard tar" one?
- does it handle the sources directory in tars gracefully? it may have unrelated png's.
- anything else good to know for someone who doesn't understand how it works but needs to use it?


Related, if we generate .grf's with that, can they go on bananas no problem, right now?


Unrelated, I'd like to ask, what stable version of ottd is the last to support tars?

Converting everything to newgrf's takes time. Until that is closer to being completed I recommend that tar loading is put back in the game.

[FooBar]

the last stable with png loading is 1.1.5 (or 1.2.9-beta4 if you want to call that 'stable').
I can probably help you with the rest of your questions as well, but not from my phone. Will get back to this later.

[FooBar]

Since at least you understand what it does, I would suggest you write that manual now. That script should come with info on:
1 what files is takes as args and how many
2 what the tool used for
3 what the resulting file is and what spec that file follows
4 what version of the game the resulting file is compatible with
5 what does it use as a "base" sprite (8bpp)? converts the 32bpp to 8bpp?
6 does it generate the additional zoom levels on the fly?
7 what naming scheme does it support for the png's? the "standard tar" one?
8 does it handle the sources directory in tars gracefully? it may have unrelated png's.
9 anything else good to know for someone who doesn't understand how it works but needs to use it?

1 It takes all png files from a single directory; untarred.
2
3 The resulting file is a grf with the name grf_32bpp.grf and grfid "32BPP"
4 1.2.0-rc1 and above
5 an empty sprite
6 no
7 the filename of the png must be the same as with png sprite loading, the offsets must be pngcodeced into it
8 yes, it does not look in any subdirectory
9 not really, maybe just that every sprite that must go into a grf needs to be in the same directory. Also that it doesn't handle climate specific sprites.

[GeekToo]

Oops, I just wrote a small howto, and see that Foobar did too, posting it anyway if not everything is covered. Thanks Rubidium.


What it does:
----
Call the script in a directory with png-files, pngcodeced in the "old" way and the empty.pcx. E.g. an untarred nightly pack
It will then create a .grf file, containing all the graphic data from the pngs for 32bpp, and "empty" graphics for 8bpp

To do so, it will first:
---------
-make sure all the pngs are in rgba mode (and convert using python imaging lib if not)
-make sure the mask palettes are ok
-create an nfo file, referring to the sprites in the directory, and the empty 8bpp file. pngcodec -l is used for obtaining the offsets
-call nforenum to have the numbering in the nfo file right
-call grfcodec to make the .grf file from the pngs and the nfo file

What do you need:
------
-An environment capable of executing bash-scripts (linux or mingw or..)
-Install the last version of grfcodec and nforenum (supporting the container version 2 format for grfs, and info version 32 for nfo)
-Install python
-Install the Python imaging lib (On Gentoo: emerge imaging)
-For testing the grf: r23976 or higher of the nightlies of openttd

[Lord Aro]

...1.2.9-beta4...

Source please!

@Jupix: I (and Rubidium) have been using the script for a couple hours now, and while it does not make things 'perfectly' it is very good at showing up errors, several of which i am working on fixing
(As Rubidium says) the script is only a temporary thing for showing that stuff can easily be transferred from tar format to grf format
Eventually the 32bpp-ez sprites will (probably) be included in some form of OpenGFX

Edit: also note that Rubidium has updated his script a bit: http://rbijker.net/openttd/create.txt

[Jupix]

Thanks for the info so far. This would make a nice wiki page.

@Jupix: I (and Rubidium) have been using the script for a couple hours now, and while it does not make things 'perfectly' it is very good at showing up errors, several of which i am working on fixing
(As Rubidium says) the script is only a temporary thing for showing that stuff can easily be transferred from tar format to grf format

Sure, and I would think the smart thing to do is to use this script as a basis for developing a conversion tool. (One that isn't temporary and abandoned by its author.)

Eventually the 32bpp-ez sprites will (probably) be included in some form of OpenGFX

That's what we've been aiming at for the last 3 years or so, no?
The desired end product for the base set project was always an "OpenGFX32" or whatever, with or without the 8bpp version bundled. It just shouldn't consist of any sprites, merely those that fit in.

Since you've been using it, would you say the tool is ready to start putting that set together?

[FooBar]

...1.2.9-beta4...

Source please!

Yeah, that's what you get when typing on a phone with fat fingers...
So unfortunately I don't have the source of that, as I meant to type 1.2.0-beta4

[planetmaker]

Sure, and I would think the smart thing to do is to use this script as a basis for developing a conversion tool. (One that isn't temporary and abandoned by its author.)

Why do you need a permanent conversion tool for a one-time task? What would be smart about that?

And yes, let's start putting together a baseset which also contains 32bpp. I think we just should work jointly on a common base set which supports all zoom levels and colour depths. It's easily feasible now and avoids unnecessary work.

Especially as we have the grfstrip tool at our command, we can simply include all sprites in OpenGFX itself. And then get a 8bpp-only version by running the grfstrip over it without any extra work needed.

Indeed let's start. And yes, let's include only those which fit our standard.

[Lord Aro]

Eventually the 32bpp-ez sprites will (probably) be included in some form of OpenGFX

Since you've been using it, would you say the tool is ready to start putting that set together?

No. As several people have said, this was just a quick hack to show that, if necessary (Spain Train set, etc), the tar format could be converted to grf format
Having the sprites included in ogfx will (apart from waiting for nml to support 32bpp) mean that only certain sprites (most from standard megapack) will be included in existing files, so what would be the point of creating 'new' newgrfs?

[Jupix]

Why do you need a permanent conversion tool for a one-time task? What would be smart about that?

Stop splitting hairs

And yes, let's start putting together a baseset which also contains 32bpp. I think we just should work jointly on a common base set which supports all zoom levels and colour depths. It's easily feasible now and avoids unnecessary work.

I take it this would happen at the ottdcoop devzone?

only certain sprites (most from standard megapack) will be included in existing files, so what would be the point of creating 'new' newgrfs?

Well, I assume people will want to play with some graphics, whether they are in the "opengfx32" or not. For those graphics that aren't, unless they get converted, they are broken.
Unless I misunderstood your question.