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

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

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?

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.

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?

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?

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

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.

Now only white and gfx/2d/bigchars remain.

Is there any reason why we can't just have some sort of res-engine dpk that is distributed with the engine?

Is there any reason why we can't just have some sort of res-engine dpk that is distributed with the engine?

Dealing with the logistics of it would require more work than packaging them with the game package.

Only the embedding of them would reduce the logistics cost.

Right now the only files are:

gfx/2d/bigchars.png
sound/null.wav
scripts/engine.shader

And the shader file only contains:

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

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

We can definitely embed them, also they are now so few of them that we even don't have to think about some generic dpk emdedding mechanism, we may just embed them as-is one by one.

The bigchars shader look like the default settings you would get if registering with IF_2D | IF_NOPICMIP so explicit shader text is probably not needed. By the way, do we have the license for that gfx/2d/bigchars image?

See #1842 for a work in progress effort at embedding them:

WIP: embed media files #1842

Once the embedding works, we may want to add fonts/unifont.ttf to the list of embedded files, that's something the engine looks when there is no unvanquished dpk.

Once the embedding works, we may want to add fonts/unifont.ttf to the list of embedded files, that's something the engine looks when there is no unvanquished dpk.

If you embed that one, then there's no longer any reason to have bigchars.

By the way, do we have the license for that gfx/2d/bigchars image?

It looks to be the one from Tremulous GPP.

The one from Tremulous 1.1.0 was different.

I have also verified that it is not the one from Quake 3.

As said on #1842 (comment) I managed to cut down the null.wav file to 90 bytes, which even allows to copy-paste the data in a source file directly.

Maybe the only file we would need embedding for is fonts/unifont.ttf.

If we don't embed null.wav with the current VFS implementation from #1842, we still need to provide the sound/null path as it's common for legacy assets to rely on that path.

Unifont's license has an explicit exception for embedding, so it's very fine to embed unifont.

About the remaining assets to embed, here is the work in progress:

fonts/unifont.ttf:
embed: Embed Unifont in the client and NUKE fallback font #1848
gfx/2d/bigchars.png:
NUKE: Embed Unifont in the client and NUKE fallback font #1848
sound/null.wav
generate: Implement the builtin sound/null.wav file #1854

We also have that to embed any future file, and to better embed existing ones (GLSL), the font embedding can rely on that:

Genericize the CMake source generator for embedding files #1849

It can even be possible to embed builtin paks to expose them to the VFS:

WIP: embed media files #1842

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// 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 );
	}

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

Description

Activity

illwieckz commented on Feb 18, 2018

illwieckz commented on Feb 20, 2018

illwieckz commented on Feb 20, 2018

illwieckz commented on Feb 20, 2018

VReaperV commented on Jan 9, 2025

slipher commented on Jan 10, 2025

slipher commented on Aug 6, 2025

VReaperV commented on Oct 3, 2025

illwieckz commented on Oct 3, 2025

illwieckz commented on Oct 3, 2025

slipher commented on Oct 3, 2025

illwieckz commented on Oct 4, 2025

illwieckz commented on Oct 4, 2025

slipher commented on Oct 4, 2025

illwieckz commented on Oct 4, 2025

illwieckz commented on Oct 4, 2025

illwieckz commented on Oct 4, 2025

illwieckz commented on Oct 8, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions