Page 4 of 4
Posted: Fri Jan 13, 2006 17:00
by chopkinsca
Graf Zahl wrote:Boingo the Clown wrote:
I am continuing to use the DooM palette, since that is what I am used to using at the moment.
Why don't you just allow each texture to have its own palette? You really don't need to remap anything and can keep it as optimized as possible.
How do you do this? Or does it only apply to texture/flats and not sprites?
Posted: Fri Jan 13, 2006 17:26
by Graf Zahl
If you put a PNG in your WAD its original palette will be used.
Posted: Fri Jan 13, 2006 17:44
by Paul
Graf Zahl wrote:If you put a PNG in your WAD its original palette will be used.
What's the pallette's index for transparency in PNG in Gzdoom? Or do I have to set up an alpha channel?
I almost cracked how-to do 32-bit colored weaponry
Stay tuned.
EDIT:
YAY! I solved it
Posted: Fri Jan 13, 2006 17:57
by Graf Zahl
PNG transparency is done with the alpha channel. There's no need to define a transparent index for a format that stores this information internally.
Posted: Fri Jan 13, 2006 18:07
by Paul
Then it cannot be used in Gzdoom.
Alpha Channel and 8-bit exclude each other and when I tried making an alpha-chanelled png (32 bit) imported to the wad, it DID import (as raw data) but Gzdoom didn't recognize it as a texture.
Technical limitations or am I doing something wrong?
EDIT:
I did a test for 32 bit graphics (paletted pngs) AND masked pngs. Both work
This is important as we can now use 32-bit graphics for Arctic Wolf Redux! Or at least the weapons I'm planning to do.
Posted: Fri Jan 13, 2006 18:38
by Graf Zahl
Paul wrote:Then it cannot be used in Gzdoom.
Alpha Channel and 8-bit exclude each other
PNG supports full alpha channel information for a palette. Normally this is merely used for a traditional transparent color but it can really be any value between 0 (transparent) and 255 (opaque) for each palette entry.
Posted: Fri Jan 13, 2006 19:13
by Boingo the Clown
Enjay wrote:
It's also worth highlighting how offsetting such a texture works because it confused me for a while - and there are now 2 options to try and combat the confusion.
By default, a texture will be offset by pixels in the original image. Therefore, if you have a 256x256 image scaled to be a 128x128 texture, as per Nash's example, and you give it an offset of 64, it will only be shifted by quarter of its width as opposed to a normal 128x128 texture that would be moved by half its width.
However, you can set an option to change the above. I'm not sure exactly how it's done in XWE (I use DeePsea) but it involves putting a value into the flags field for that texture. This option allows the texture to be offset by "world units" rather than pixels. So, again using the above example, an offset of 64 would move your scaled texture by half its width.
Option 1 allows for very fine control of texture offsets
Option 2 allows hi-res textures to be easily slotted in to replace existing ones or to behave as their effective size rather than their actual size.
I have just discovered that changing the flags field for a texture in XWE to $8000 will switch it to using world units.
Posted: Fri Jan 13, 2006 19:20
by Paul
$8000