textures2quake: Takes high res textures --> Quake/Half-Li

[Sajt]

A nearest-neighbour reduction using luminosity weighting (wow... a lot of big words makes that sound more than what it is: extremely simple) produces a much more palatable image:



But I'm sure that that fancier algorithm must be good for something. I wonder what sort of image it would do well on.

[Baker]

Works well enough for my purposes. Most textures that would be used in a Quake map aren't really "millions of colors" type textures.

I used what was available in FreeImage.

Quake palette conversion of Nexuiz:



Maybe fun to work on the fixed palette conversions for future versions

/Btw ... I can't tell if you are being sarcastic, but if so I'd like to point out that your palette indexes in your sample are wrong.

[Sajt]

I'm not really sure what I could have been sarcastic about. I would like to see an example of what sort of situations this special algorithm is designed for.

As for the palette, my program exported a PCX and I used PSP to convert it to a PNG so I could upload it. Paint Shop Pro rearranges the palette (or "optimizes" it?) when it saves a PNG. They still are the same Quake colours, though, just in a different order. (It's not like anyone in their right mind would use PNG for game textures, anyway.)

Looks like PSP has an option to disable that palette "optimization". I'll use that next time...

[Baker]

[Teiman]

[Baker]

[c0burn]

[Teiman]

I was trying to avoid it, but here goes:

Why? Why is a bad idea to use PNG?

Is not like JPG, it don't destroy the quality of the image. and it supports a alpha channel, two styles (1 bit alfa and 8 bits alfa )...

Why is not that good? do it randomize the palette in 8 bits mode or something?

[Spike]

Tei:
png and zip use the same compression algorithm, but applied differently.
In png, its applied on a per-plane basis. In zip+tga its applied over the entire byte stream.
Compressing a tga in a zip means that you compress each pixel individually while png compresses each pixel 3/4 times. Repeating patterns and windows and stuff mean that tga has a smaller chance for repetition, but when there is some, there are a third less references in the window.

Basically the outcome is that you can block-decompress+decode a tga faster than you can decode+combine the multiple planes of a png.
And its a bit smaller too.

.rar+.tga or .tar.gz+.tga gives solid archives, which allows the reuse of compression windows over multiple similar files.

If the engine supports zips/pk3s, use tgas.
If the engine doesn't support zips/pk3s, you get even better compression from tgas inside a pak anyway, and the extra size weighed against the lack of compression doesn't hinder load times, but it does mean faster download speeds. However it does use more disk space. Disk space is rarely a concern nowadays.

pngs are nice and all... but... mneh.

[Baker]

[Sajt]

[Teiman]

Uh.. ok, thanks guys ( Sajt, Baker, Spike).

Now.. I remember the libpng library as a memory-hungry and unstable one.

The tga in a zip thing is very interesting.

[ceriux]

[negke]

[Baker]

Some things that this could do better ...

Take the #water #lava textures and for the Quake portion of the process, turn them into *water and *lava, etc.

Apparently a 16 pixels is the minimum Quake texture dimension, not 8. Reference: http://www.celephais.net/stuff/texturefaq.htm

And apparently liquids and clip should be 64x64 for software renderers.

And sky textures 256x128. Although since Quake 3 and no other game uses Quake sky textures, such a conversion enforcement is a little "unneeded".