[Closed] Sprite translations for different rendering

[Enjay]

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

[Graf Zahl]

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.

[Your Name Is]

That selective translucency and the "blue fireball" point are excellent! Plus, only certain parts of a pallette being full brightness, transclucent, etc. Alllows some interesting ideas into my mind!

[Vader]

Very good suggestions!
Especially the partial-translucent-thingy sounds great.
I always wanted to make a 'Xcom Aftermath' like giant maggot (Translucent), wich contains a zombiefied human (opaque) in its body

[David Ferstat]

As usuual, good ideas from Enjay.

[Risen]

2. Selective all-bright.

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.

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?

[Enjay]

How might it be extended if ZDoom ever moved to 24/32 bit color?

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?

37

[Graf Zahl]

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.)

[Nash]

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.

[Vader]

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...

It´s done via colormap AFAIK!
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!

[Risen]

Um...

It was also possible in Doom with a modified COLORMAP. I did this for the Twice Risen pre-releases.

...yeah.

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.

[Enjay]

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

[Vader]

Risen:
I must have missed that sentence