Sprite translations for different rendering
Moderator: GZDoom Developers
Sprite translations for different rendering
OK, here's two things I'd really like to see. They are both based on the existing principle of being able to specify a range of colours in the palette to do things to (ie colour translations), but instead of just swapping the colours you do different things to them. Of course, being able to do it via DECORATE and not just ACS would be most welcome.
1. Selective translucency. This is something similar to what Legacy used to have (and maybe still does). The old DOS Legacy of about 7 years ago had special palettes or colormaps or something that displayed the torches in a special way - the flames were translucent but the stands were opaque. These special palettes could be applied to any object using dehacked.
What I suggest is being able to specify a range of colours from the palette (like you already do with translations) and then being able to specify the type of translucency to be applied to them. That way, not only could you have torches with translucent flames, but monsters with translucent areas, glass tanks with solid frames...
2. Selective all-bright. Something like this used to exist in Quake1 (I think). Certain pixels were always drawn fullbright. It was a small range of red colours towards the end of the palette IIRC. If you used these on a monster skin (I used them for lights on a gun) the monster could be standing in the dark and all you could see were the bright pixels.
What I suggest is again being able to specify a range of colours from the palette and instructing them to always be drawn at full brightness. That way you could have demons with glowing eyes, lights on things, torches where only the flames glow, glowing green NV Goggles without having to make the rest of the sprite black/near black (as in Action Doom)...
And finally, more a question than a suggestion, is there any reason why full bright sprites cannot always be drawn in their original colours? It just strikes me as odd that when a bright, glowing orange ball of fire passes through a room that just happens to have a blue light on, the fireball turns blue whilst it is passing through the room. Surely the fireball is a light source and should glow its own colour regardless of the surroundings?
38
1. Selective translucency. This is something similar to what Legacy used to have (and maybe still does). The old DOS Legacy of about 7 years ago had special palettes or colormaps or something that displayed the torches in a special way - the flames were translucent but the stands were opaque. These special palettes could be applied to any object using dehacked.
What I suggest is being able to specify a range of colours from the palette (like you already do with translations) and then being able to specify the type of translucency to be applied to them. That way, not only could you have torches with translucent flames, but monsters with translucent areas, glass tanks with solid frames...
2. Selective all-bright. Something like this used to exist in Quake1 (I think). Certain pixels were always drawn fullbright. It was a small range of red colours towards the end of the palette IIRC. If you used these on a monster skin (I used them for lights on a gun) the monster could be standing in the dark and all you could see were the bright pixels.
What I suggest is again being able to specify a range of colours from the palette and instructing them to always be drawn at full brightness. That way you could have demons with glowing eyes, lights on things, torches where only the flames glow, glowing green NV Goggles without having to make the rest of the sprite black/near black (as in Action Doom)...
And finally, more a question than a suggestion, is there any reason why full bright sprites cannot always be drawn in their original colours? It just strikes me as odd that when a bright, glowing orange ball of fire passes through a room that just happens to have a blue light on, the fireball turns blue whilst it is passing through the room. Surely the fireball is a light source and should glow its own colour regardless of the surroundings?
38
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
These are good ideas.
As for the last point I have to agree. A light source should not be affected by light color in the way it is now. Of course then the fullbright flag has to be divided into two - a 'lightsource' flag and a 'full brightness with colorization' flag. There are some fullbright objects which should be affected by light color.
As for the last point I have to agree. A light source should not be affected by light color in the way it is now. Of course then the fullbright flag has to be divided into two - a 'lightsource' flag and a 'full brightness with colorization' flag. There are some fullbright objects which should be affected by light color.
- Your Name Is
- Posts: 802
- Joined: Sun Oct 31, 2004 5:06 pm
- Location: Raleigh, NC
- Contact:
- David Ferstat
- Posts: 1113
- Joined: Wed Jul 16, 2003 8:53 am
- Location: Perth, Western Australia
- Contact:
Re: Sprite translations for different rendering
It was also possible in Doom with a modified COLORMAP. I did this for the Twice Risen pre-releases. I think some changes in the way ZDoom handles these lumps broke this functionality, though.Enjay wrote:2. Selective all-bright.
However, a remap table would be much preferred to the COLORMAP method anyway, since you'd have access to the entire palette range.
How might it be extended if ZDoom ever moved to 24/32 bit color?
Re: Sprite translations for different rendering
I'm assuming you mean if people are including graphics using higher colour depths? 256 colour graphics using a different palette could presumably still use palette indexes? For more colours... the current translation method allows you to specify colour ranges to change things to by RGB values as well as palette indexes. Might that principle be useful?Risen wrote:How might it be extended if ZDoom ever moved to 24/32 bit color?
37
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Sprite translations for different rendering
Enjay wrote: the current translation method allows you to specify colour ranges to change things to by RGB values as well as palette indexes. Might that principle be useful?
37
With no palette limit the resulting colors can be used directly and thus increase the usefulness of translations significantly. Of course you will never be able to translate a True Color source picture efficiently (because you'd have to do every pixel separately.)
Anyone notice in Strife, some of the robots have this red light that always appear full-bright no matter how dark the sector is?
Seems like it's already possible...
Anyway, I love Enjay's suggestions. Maybe if it's possible, you would be able to apply some sort of greyscale "alpha mask" to a sprite that determines the translucency on the sprites' pixels. The darker the alpha mask, the more translucent the pixel will be. Not sure how will that be implemented though, it's probably not even possible, heh.
Useful for smooth-looking smokes, flames, explosions, blood, etc.
Seems like it's already possible...
Anyway, I love Enjay's suggestions. Maybe if it's possible, you would be able to apply some sort of greyscale "alpha mask" to a sprite that determines the translucency on the sprites' pixels. The darker the alpha mask, the more translucent the pixel will be. Not sure how will that be implemented though, it's probably not even possible, heh.
Useful for smooth-looking smokes, flames, explosions, blood, etc.
It´s done via colormap AFAIK!Nash wrote:Anyone notice in Strife, some of the robots have this red light that always appear full-bright no matter how dark the sector is?
Seems like it's already possible...
You can specify the range, to what a color shades...
they simply set this red color to never shade at all.
I could be wrong though!
Um...
You could use alpha maps for translucency, but also for how much areas are affected by brightness. It could potentially add a lot of size, but it would also allow 24-bit color sources to take advantage of this.
...yeah.Risen wrote:It was also possible in Doom with a modified COLORMAP. I did this for the Twice Risen pre-releases.
You could use alpha maps for translucency, but also for how much areas are affected by brightness. It could potentially add a lot of size, but it would also allow 24-bit color sources to take advantage of this.
I guess the downside of the colormap method is that the specified palette index values are then always drawn bright - so they become useless for everything other than items and walls (etc) that are meant to be bright - losing you some of the palette entries for general use. Well, that and it no-longer works in Zdoom.
36
36