engine code requires some shaders and assets currently shipped as game assets

[illwieckz]

There are 3 shaders in engine code that are sets from game assets

Daemon/src/engine/client/cl_main.cpp:	cls.charSetShader = re.RegisterShader( "gfx/2d/bigchars", RSF_DEFAULT );
Daemon/src/engine/client/cl_main.cpp:	cls.whiteShader = re.RegisterShader( "white", RSF_NOMIP );
Daemon/src/engine/client/cl_main.cpp:	cls.consoleShader = re.RegisterShader( "console", RSF_DEFAULT );

The first one gfx/2d/bigchars looks to be a fallback if the ttf font is not found. Do we have to keep that? If the ttf found is not found it means both system font and game pack are missing, and if game pack is missing, the fallback will never be found. So, can we get rid of that?

Daemon/src/engine/client/cl_main.cpp

Lines 3054 to 3069 in 8c1c497

	// load character sets
	cls.charSetShader = re.RegisterShader( "gfx/2d/bigchars", RSF_DEFAULT );
	cls.useLegacyConsoleFont = cls.useLegacyConsoleFace = true;
	// Register console font specified by cl_consoleFont, if any
	// filehandle is unused but forces FS_FOpenFileRead() to heed purecheck because it does not when filehandle is nullptr
	if ( cl_consoleFont->string[0] )
	{
	if ( FS_FOpenFileRead( cl_consoleFont->string, &f, false ) >= 0 )
	{
	re.RegisterFont( cl_consoleFont->string, nullptr, cl_consoleFontSize->integer, &cls.consoleFont );
	cls.useLegacyConsoleFont = false;
	}
	FS_FCloseFile( f );
	}

The other ones are just shaders for pure white and pure black shaders:

https://github.com/UnvanquishedAssets/unvanquished_src.dpkdir/blob/8bd935eca289ab3e55ef21d6122eab884378fd6d/scripts/misc.shader#L106-L114

white
{
	cull none
	{
		map *white
		blendfunc	GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbgen vertex
	}
}

https://github.com/UnvanquishedAssets/unvanquished_src.dpkdir/blob/8bd935eca289ab3e55ef21d6122eab884378fd6d/scripts/misc.shader#L38-L45

console
{
	nopicmip
	nomipmaps
	{
		map gfx/colors/black
	}
}

The white one only relies on pure text, it can be embedded. The console one (black one) relies on a pure black textures, it can probably be generated at run time or we can probably embed a 1×1px xpm or something like that (it's currently a pure black 8×8 jpg)…

Note that both white and console shaders are redefined by the game code itself and game packages so they basically are fallbacks for when game code does not define them and when game packages are not there, so the purpose of fallback is entirely defeated: the fallback for missing game requires game packs (!!!).

[illwieckz]

Well, the engine also requires:

lights/defaultPointLight
lights/defaultProjectedLight
lights/defaultDynamicLight

and they rely on some pixmaps.

If it's an engine-required stuff, why not having them shipped built in the engine (the same way we did with glsl shaders)?

Why not having the engine embedding a small dpk and activating a built-in vfs? Any idea anyone?

[illwieckz]

note that:

console
{
	nopicmip
	nomipmaps
	{
		map gfx/colors/black
	}
}

can be modified like this:

console
{
	nopicmip
	nomipmaps
	{
		map $blackimage
	}
}

to not rely on any external file.

[illwieckz]

So what could be cool would be to embed those shaders in engine, we can give them explicit paths to be sure to not collide with existing game paks (like using a gfx/engine/ prefix), so for example:

gfx/engine/white
{
	cull none
	{
		map $whiteimage
		blendfunc	GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbgen vertex
	}
}

gfx/engine/console
{
	nopicmip
	nomipmaps
	{
		map $blackimage
	}
}

I don't know what to do with the pixmap console font fallback (bigchars) do we really need it?

[illwieckz]

So these are the current shaders required by engine:

white
{
	cull none
	{
		map $whiteimage
		blendfunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbgen vertex
	}
}

console
{
	nopicmip
	nomipmaps
	{
		map $blackimage
	}
}

// console font fallback
gfx/2d/bigchars
{
	nopicmip
	nomipmaps
	{
		map gfx/2d/bigchars
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbgen vertex
	}
}

lights/defaultDynamicLight
{
	{
		stage attenuationMapZ
		map lights/mkintsquarelight1a
		edgeClamp
	}
	{
		stage attenuationMapXY
		forceHighQuality
		map lights/round
		colored
		zeroClamp
	}
}

lights/defaultPointLight
{
	// this will also be the falloff for any
	// point light shaders that don't specify one
	lightFalloffImage lights/mkintsquarelight1a
	{
		stage attenuationMapXY
		forceHighQuality
		map lights/squarelight1
		colored
		zeroClamp
	}
}

lights/defaultProjectedLight
{
	// by default, stay bright almost all the way to the end
	lightFalloffImage lights/mkintsquarelight1b
	{
		stage attenuationMapXY
		forceHighQuality
		map lights/squarelight1
		colored
		zeroClamp
	}
}

The required files are:

gfx/2d/bigchars.png
lights/mkintsquarelight1a.png
lights/mkintsquarelight1b.png
lights/round.png
lights/squarelight1.png

Those are not required by game code neither the level editor, they are pure engine stuff.
It reminds me an old issue with gtkradiant: the editor faulted when 'radiant/notex' and 'radiant/shadernotex' where missing, they were pure radiant stuff, but radiant never shipped them so every games on earth had to ship them. I just fixed that issue in gtkradiant but that annoying behavior was there since decennials… It was so annoying to start a new mod or new game and to have radiant faulting because of that!

I think it's the exact same case with these shaders except dæmon is not aborting if they are missing, but it still does weird things without them. Basically, the engine is not complete without these shaders, and having to ship engine stuff in game packages looks weird.

Similar job was done previously with glsl shaders that are now embedded.

There is still that question about the bigchars fallback, is it really needed?

[ghost]

There is still that question about the bigchars fallback, is it really needed?

Probably not. It's even more harmful than helpful. If the intent is to have a really light font embedded in engine, then png is a very bad format for the task, as it lacks many font-related data, which have to be guessed somehow by special weird code which implements a "freetype for the poor" thing.
If the use of a minimalist font file is real, there are alternative formats which exist for that very real reason, like PSF (used notably by linux kernel).
Also, there's already unifont, which is a much better fallback as it at least includes a lot of glyphs (and it's size might be reduced by using a more recent version).

Removing that bigchars file would also allow to get rid of redundant code, that is even likely never executed, since when you have this file, then you also have unifont anyway.

As for the solution... I guess using a .dpk for that would be pretty weird. What would be the benefits of a .dpk instead of just normal files sitting next to the engine (or in a specific directory, cleaner and more alike the unix way of organizing files)?

[VReaperV]

defaultDynamicLight, defaultPointLight, and defaultProjectedLight are to be nuked as part of #747.

[slipher]

Using a dpk would make sense if the files are intended to be overridable by the game/user. Otherwise it would probable be better to embed files directly, reusing the code for embedding GLSL. Unless adding code paths to access the embedded byte array (instead of opening a pak file) proved so burdensome that implementing an embedded DPK proved easier.