~a1batross/xash3d-fwgs

client: make vgui2 character drawings always use utf-8 (old engine behaviour, that used in hlsdk-portable) v1 PROPOSED

mittorn: 1
 client: make vgui2 character drawings always use utf-8 (old engine behaviour, that used in hlsdk-portable)

 1 files changed, 4 insertions(+), 2 deletions(-)
I think, we may use utf32 unicode codepoints everywhere (just move utf decoding to client side)
It should work on 16-bit unicode subset correctly, will be compatible with wchar_t on linux and i'm unsure any supported mod use anything higher as it's likely to be broken in vgui2. Even if vgui2 use utf-16, our renderer does not precache anything hgher.
Note that hlsdk-portable have check for xash3d and does not use vgui2 char render functions under GS
It might get worse if somebody started using these functions, relying
on their exact behavior under Xash, and there would be mods that used
these functions relying on the wchar_t behavior from Goldsrc.

You know, we might implement proper Unicode support on engine side in
a few weeks, few months or few years. There better be a more
future-proof solution.
Ok, but what abput non-unicode locales? How this should work? I do not thing that is good idea to rely on system locale. I even getting locale errors when launching GS/Source now (but engine seems to work ok).
That's true. locales & wchar_t is horrible.

I'm thinking of Unicode here (specifically UTF-16 and UTF-32) because mostly everyone uses it now, for some reason uses wchar_t to store it, and we could just don't accept anything else, and don't rely on locale at all.

(Sorry, had to figure out how to disable HTML. This should be ok)
Export patchset (mbox)
How do I use this?

Copy & paste the following snippet into your terminal to import this patchset into git:

curl -s https://lists.sr.ht/~a1batross/xash3d-fwgs/patches/48010/mbox | git am -3
Learn more about email & git

[PATCH] client: make vgui2 character drawings always use utf-8 (old engine behaviour, that used in hlsdk-portable) Export this patch

---
 engine/client/cl_game.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/engine/client/cl_game.c b/engine/client/cl_game.c
index f8413b5d..889b8570 100644
--- a/engine/client/cl_game.c
+++ b/engine/client/cl_game.c
@@ -2884,7 +2884,8 @@ pfnVGUI2DrawCharacter
*/
static int GAME_EXPORT pfnVGUI2DrawCharacter( int x, int y, int number, unsigned int font )
{
	return pfnDrawCharacter( x, y, number, 255, 255, 255 );
	rgba_t color = { 255, 255, 255, 255 };
	return CL_DrawCharacter( x, y, number, color, &cls.creditsFont, FONT_DRAW_HUD | FONT_DRAW_UTF8 );
}

/*
@@ -2895,7 +2896,8 @@ pfnVGUI2DrawCharacterAdditive
*/
static int GAME_EXPORT pfnVGUI2DrawCharacterAdditive( int x, int y, int ch, int r, int g, int b, unsigned int font )
{
	return pfnDrawCharacter( x, y, ch, r, g, b );
	rgba_t color = { r, g, b, 255 };
	return CL_DrawCharacter( x, y, ch, color, &cls.creditsFont, FONT_DRAW_HUD | FONT_DRAW_UTF8 );
}

/*
-- 
2.39.2
GoldSrc unconditionally uses wide characters here. Not just UTF-16 but
wchar_t... which definition already varies depending on system and
locale combination.

Using hlsdk-portable on GoldSrc yields in unreadable text for
multibyte UTF-8 sequences.

In that sense, the real choice would be to fix hlsdk-portable instead,
and expect wchar_t here. Should we allow UTF-8 for now and deprecate
it later when we get wchar_t support? Or do nothing, again until we
get wchar_t support? I honestly don't know.

Sorry, I broke the thread. Disregard previous emails.