tr_image: rework some builtin images

[illwieckz]

• tr_image: extend internal image detection
• tr_image: do not rely on previously set data for cinematic, numberize and rename as *name
• tr_image: resize builtin images as 1×1
• renderer: simplify builtin color image name parsing, rename as $name, forget about unused aliases
• tr_image: rename framebuffer images as *name
• tr_image: rename remaining builtin images as $name
• tr_image: rename generated textures as *name
• tr_image: make the $black builtin image opaque
• tr_image: NUKE the $red, $green and $blue builtin images

---

Original message:

• make _black opaque
• add _null for zeroed image (instead of _black)
• explicitly set _cinematic color instead of relying on previously set values
  imported from Add support for the GL_RED format, use it, also rework format detection #1793
• make images 1×1 sized, makes the code simpler
• extend shader parsing for keywords like $blueimage.

This will conflict with #1793 but I plan to rebase #1793 over it once this is merged.

[illwieckz]

As said here:

Previously _black, was usable to make a transparent texture:

transparent
{
	map _black
	blend blend
}

Because all its channels were set to 0, including the alpha one.

But when stored as RED the alpha channel is opaque (so, 1).

But I have seen no map in the whole betaserv corpus that used any _black, *black, $black, $blackimage keywords at all, so even not used as trick with blend to get a fully transparent texture.

Actually it bugged me that the black image was not opaque black.

So, we better have a dedicated _null instead.

[illwieckz]

Also this may spark some discussions. First, the reason why there was no $black usage, etc. is because ioq3 never parsed that. ioq3 only parsed $whiteimage and *white.

It also means ioq3 never parsed $white and _white.

It means we really don't have to parse all those variants.

I grepped etlegacy and realrtcw and none of them did more than defining $whiteimage and *white, no syntax variant, no other colors.

This also brings the topic that we may just name images like _black as $blackimage directly.

If I'm right, we don't need to actually parse things like _white or _black in tr_shader because the image loading code will find them as they are created and loaded as startup anyway. Parsing them just skips some code.

So an alternative code may be to only parse for *white for ioq3 compatibility, and name the image $whiteimage, and name all other builtin images this way, and not parse any other color image names, relying on the map lookup to find them.

[illwieckz]

The only $blackimage and $black thing we find in etlegacy is in their GL2 renderer which deviates from XreaL like us. That look pure XreaL stuff there, no one uses that as far as I know. Their other renderers (GL1, GLES) don't parse that at all.

In fact, ioq3 and QIII don't parse *white (even not in ioq3's renderer2), that's because QIII names that image *white so it works by image lookup.

[illwieckz]

Hmm, actually if we name the images like $whiteimage, then testshader can't find them.

[slipher]

For a transparent shader we should make it possible to parse a shader with 0 stages (instead of assuming it is an error or a fog). Using a stage with an image is wasteful since it still has to execute the shaders.

[slipher]

Hmm, actually if we name the images like $whiteimage, then testshader can't find them.

Are you sure? For me it works with $generatedTexture0.

[illwieckz]

Hmm, actually if we name the images like $whiteimage, then testshader can't find them.

Are you sure? For me it works with $generatedTexture0.

Test that latest commit. It will even break the console because some shaders rely on $whiteimage.

[illwieckz]

Hmm, the problem is not the $ character:

]/testshader $blueimage
Debug: loading '$blueimage' image as shader 
image params mismatch for $blueimage: 0x0 0 0/0 0 0 vs. 0x40000 0 0/0 0 0 
Warn: Couldn't find image file '$blueimage' 
Shader $blueimage not found 

[slipher]

Oh right, the code to treat builtin images specially (by allowing params mismatch) assumes that the builtin image names start with _ not $.

[VReaperV]

For a transparent shader we should make it possible to parse a shader with 0 stages (instead of assuming it is an error or a fog). Using a stage with an image is wasteful since it still has to execute the shaders.

If it's currently assumed to be fog, then changing that might break some maps.

[slipher]

A fog has to have fogparms so it's not hard to distinguish.

[VReaperV]

A fog has to have fogparms so it's not hard to distinguish.

True. As long as it takes precedence over the automatic transparency.

[illwieckz]

I renamed all the builtin images to $name and the engine now uses $ to detect builtin images.

I also numberized cinematic images, and slightly renamed some others.

I removed aliases that were not used.

[illwieckz]

I also removed the patches modifying the builtin black image and adding the null one, those topics will be cared about in later PRs.

Now this PR is about unifying and cleaning-up the builtin image code.

[slipher]

Could we have a naming convention that distinguishes between images which are intended to be available for artists to use in shaders, and ones that are an internal implementation detail? Like the white image is good to use in shaders, but the light tile images aren't.

I'm not saying that we should make it impossible to use those in shaders (it's convenient for debugging sometimes), but some convention to know whether it's supported or not would be nice.

[illwieckz]

I also thought about that. I don't really like the _ prefix though as it's much more probable to be used in a file path, unlike $ or * for example.

I believe it's a good idea to keep the $name scheme for things usable in shaders, as we already have $lightmap (and some other engines even have $deluxemap), and quake3 had $whiteimage, and use something else for purely internal things like framebuffers.

In names usable in shaders, we may even be more precise, using one syntax for generic name for context-dependent pseudo-variables (like $lightmap), and another syntax for things that directly name an unique image, like *white (Q3 did both *white and $whiteimage, but $whiteimage was only usable in shaders, where *white was usable as the actual image name). But having that distinction in shaders may be overkill, having $lightmap and $white is good enough, without requiring the $lightmap and *white distinction.

What would you suggest for truly internal things like a framebuffer? I dislike _. Actually we may use * like in *lighttilerender.

What's your own opinion for RmlUi generated images? It seems to fall in the the case of not being intended for use outside of debugging, so it would use the same convention as framebuffers.

[illwieckz]

I renamed possibly reusable images as $name, and frambuffers and UI generated images as *name.

I left _fog unmodified as it is meant to be deleted anyway.

[illwieckz]

I only kept the backward compatibility for $whiteimage, *white, and blackimage. All the other names like _white, *black and $flatimage were XreaL/Dæmon-specific, we did not use them.

We actually use or have used $whiteimage and *white in our official assets, but not $blackimage or *black.

I have seen some games like Warsow (QFusion engine) using $blackimage and *black in their assets, so mappers may use that.

[illwieckz]

I added a commit making $black opaque (no 0 alpha channel).

I also added a commit NUKING $red, $green and $blue images, they were never used and we can use $white with rgbgen const instead.

[slipher]

Also delete these fields from the tr struct

[illwieckz]

Done.

[slipher]

You can remove _ now since it's not an image anyone needs to load from a shader.

[illwieckz]

Done. Also this _fog image is now NUKED anyway.

[slipher]

You can drop the / test since * or $ can't be used in file names.

[illwieckz]

Awesome!

[illwieckz]

Cleaned-up.

[slipher]

LGTM