What is the purpose of a texture with the prefix ~, by the way? Created 4 years ago2020-02-11 02:04:10 UTC by MrMystery

If there's any.

~

If I recall correctly, it means it's a light-emitting texture. They don't work out of the box though. Gotta define their light values inside lights.rad.

I think its mostly used for textures that came with the mod/game to separate them from normal textures. You can define your own texture lights by using lights.rad or even better by making a point entity info_texlights and entering the info there, having "~" before the name is not required for this to work.

https://twhl.info/thread/view/18303?page=1#post-312739

I wouldn't be too surprised if it was originally intended to denote light-emitting textures but was changed later to being specified in lights.rad. By that point, why change the texture names?

It also makes it easy to filter for light textures, even if you do have to make sure to add them to lights.rad or info_texlights

I beg to differ with the tilde marking light emitting textures. It appears on a number of textures that would never emit light, including the off variants of lights, as well as generic textures like computer side panels and such. Certainly not a bad idea to mark light emitting textures with a tilde though, assuming you don't just call them "light"

Yeah, maybe it was just a marker used by the development team of Quake and HL

They were textures that were meant to glow. The last x amount of colors in the palette would be fullbright so even in a dark area, you'd be able to see them. The feature was only partially implemented before being canned. You can see it in it's working state in the leaked alpha but only in software mode.

The last 32 colours - did the Quake engine use the ~ prefix or something else?

From my experience with the Quake engine, if the colours were from the fullbright range, they would render as such, no matter the prefix.
I got some Quake WADs, and none of them have ~prefixed textures, so.

In Quake, the last 32 colors in the palette would always be rendered as fullbright, but only in the software renderer. I guess Valve were originally going to carry this over, but decided not to since the game has hardware rendering support, and surfaces are lit through lights.rad anyway. Interestingly enough, it seems as though some of the textures prefixed with ~ has their colors in the last 32 slots of the color palette, similar to were the fullbrights were in Quake.

Hm, I wonder why it was software only.

"Hm, I wonder why it was software only."

Because of graphics programming.
When you write your own software renderer, you have complete control over how things render. When you use an API like OpenGL, 1.1 at the time, you get a lot of features, however at the same time, you can't get the easy per-pixel control as you'd have with a software renderer. (it gets a bit complicated)

One would either have to write a pixel shader (which wasn't available back then), or maybe modify the current texture for the current wpoly, before rendering it.

I'm guessing the algorithm went something like this for each pixel in the texture:

if ( texturePalette < 224 )
   color = textureColor * lightmap;
else
   color = textureColor;

This is the kind of 'control' that I'm talking about. We're basically modifying the texture before uploading it to draw the current wpoly. But, this isn't my area yet and I'm likely incorrect.

Modern Quake sourceports like Quakespasm and Mark V (the ones I've used) support this feature in OpenGL mode, so it's probably not that much of a trouble.

Quake's software rendering is actually quite interesting when it comes to lighting. The original software renderer could only render 256 colors in total. That's not 256 colors per texture, or 256 colors * lightmap, that's 256 colors in total on screen. These 256 colors were defined in a single palette that was also used for every texture in the game. Since only 256 colors could be used, they used a precalculated lightmap where each palette index were remapped to another palette index based on its light level. Fullbrights were implemented in a really simple way really; the remapped palette indexes for the last 32 colors of the palette would simply remap to its original palette index no matter the light level. This is why the later released OpenGL renderer doesn't have fullbrights. It doesn't use this remapping since they could just straight up multiply the lightmap with the textures without having to stay to the original 256 color palette.