HL25 HUD

[a1batross]

This set of patches adds support for available since HL25 update HD set of sprite sheets.

Because not every player might like the new HUD look, there is a new cvar hud_allow_hd that limits the usage of HD sprites and reverts some style changes, like battery HUD being super close to the left and HUD numbers are shifted down a bit to match the icons (additionally, it fixes HUD inconsistency bug caused by this change, see ValveSoftware/halflife#3728).

There is no way to switch between old and new HUD by toggling hud_allow_hd cvar without restarting a level, so I wonder if we should use Xash3D's FCVAR_LATCH extended flag to notify the player that the change will be skipped until server restart.

[a1batross]

I reverse-engineered the exact numbers (like switching between resolutions in GetSpriteRes and iHudNumbersYOffset) but I wrote the code the way I wanted, so for example the function I mentioned doesn't exist in decompiled client.so.

[tmp64]

While the code matches HL, I think ammo bars should scale with HUD size for consistency

hlsdk-portable/cl_dll/ammo.cpp

Lines 328 to 337 in e8db2fa

	if( ScreenWidth >= 640 )
	{
	giABWidth = 20;
	giABHeight = 4;
	}
	else
	{
	giABWidth = 10;
	giABHeight = 2;
	}

[a1batross]

@tmp64 yeah, I checked that specifically in decompile, and they haven't touched that.
Dunno, it still looks good enough to me.

[FreeSlave]

They also got the train sprite wrong as described in ValveSoftware/halflife#3510
But it's more of the resource issue.

[a1batross]

@FreeSlave about train code not referencing train sprites hud.txt: I don't think the behavior should be changed that much.

[a1batross]

@tmp64 I fixed the ammo bar scaling you mentioned in last commit.

[FreeSlave]

Imagine the following situation.
The mod uses this code and provides sprites for high resolutions. Some sprites are larger than 256x256 and the pre-anniversary goldsource wouldn't be able to load them. However the developer wants the mod to work on both current and legacy branches.
So we need to detect whether the client is running on the legacy version, and not load high res sprites in this case and treat everything as if hud_allow_hd was set to 0.

[a1batross]

True, that's planned to do.

[nekonomicon]

Is it ready to merge?

[a1batross]

I'm too lazy to check whether legacy GoldSrc can support this.

Until we get confirmation that it works, or otherwise I make some detection to disable the HD HUD, I don't think it's ready to be merged.

[a1batross]

Also, this:

There is no way to switch between old and new HUD by toggling hud_allow_hd cvar without restarting a level, so I wonder if we should use Xash3D's FCVAR_LATCH extended flag to notify the player that the change will be skipped until server restart.

I'm still not sure about this. Should we just use LATCH flag from Xash3D (and hope that it won't break anything for GoldSrc) or do some workaround?

[FreeSlave]

As I said before, before merging we need to add a dynamic check for the legacy GoldSource version so mods won't try loading highres sprites when running on steam_legacy.

[tmp64]

BHL does this by checking if one of the new sprites exists
https://github.com/tmp64/BugfixedHL-Rebased/blob/1a1f601b50217ef8ac5f1d84f7813361c6a36ae1/src/game/client/hud.cpp#L114-L120

[FreeSlave]

It's not what I'm talking about.
You can't rely on checking for resources.
Imagine an author wants a mod to run on both steam_legacy and the current HL versions, using benefits of support for highres sprites when it's possible. The old engine doesn't support big sprites (I actually need to check what happens if it tries to load them).