tr_font: no need for file extension

[illwieckz]

• tr_font: no need for file extension
  I did it for log æsthetics, but it fixes testshader fonts/unifont_0_0_32 as an unexpected side effect.
• tr_image: use GL_RGBA8 explicitly for glyphes
  We always use an explicit format as internalFormat everywhere else.

[slipher]

It might be good to use a name that can't conflict with / is distinct from normal file names. Like for the RmlUi font textures we have $generatedTexture6 or whatever.

[illwieckz]

That's doable. I guess it was named like this because in the past it could be a generated image in the pk3. There are comments about it. But it was tied to some limitations we don't have if I'm right.

[illwieckz]

I discovered that testshader can't find and then display an image whose name starts with $.

[slipher]

That's doable. I guess it was named like this because in the past it could be a generated image in the pk3. There are comments about it.

OK, that makes some sense, it's fine as is.

[slipher]

That's doable. I guess it was named like this because in the past it could be a generated image in the pk3. There are comments about it.

OK, that makes some sense, it's fine as is.

Actually no, the code is confusing but it doesn't look like there would be any way to use an image from a pak instead of rendering using Freetype. RE_RegisterShaderFromImage creates a shader directly from an image_t without doing lookups in the shader or image namespaces. So using a name that has no overlap with normal shaders would make more sense.

I think I changed that behavior recently; before it might have been possible to do an image lookup for that function. But that could only happen after the glyph was already rendered with Freetype. It seems clearly wrong to render something and then discard it so I prevented that lookup from happening.

[illwieckz]

I believe we have no reason to load such file from pk3/dpk anymore, so I'm OK with making the name using some internal naming scheme, but then we must clean-up anything about loading such file from the VFS.

[slipher]

I believe we have no reason to load such file from pk3/dpk anymore, so I'm OK with making the name using some internal naming scheme, but then we must clean-up anything about loading such file from the VFS.

OK, if you find anything to clean up go ahead. Regarding pre-rasterized fonts I'm only aware of the code loading gfx/2d/bigchars but that's a single image that can't be split into blocks.

[illwieckz]

I discovered that testshader can't find and then display an image whose name starts with $.

Not only our builtin image detector doesn't check for paths starting with $, but our builtin image detector is actually checking for the image name to not contain any /, and font names contain one.

[illwieckz]

But is the image generated by RE_StoreImage() actually used? The image object is local to the function…

[slipher]

But is the image generated by RE_StoreImage() actually used? The image object is local to the function…

A shader is created using the image and the shader handle is stored.