Special characters in paths causing issues

[The-Gig]

After someone mentioning on Discord that he wasn't able to start the game and then figured out it was due to special characters (accented letters) in the installation path (in his French Windows, "Downloads" folder is "Téléchargement". His issue happened with nightly build binaries (latest available at the time of this writing, from 2023), not with 0.8.8 binaries, so it looks like some kind of regression), I made a few tests myself (tested in Windows 10).

About basepath (game installation folder):
For the test, I added a "à" or "£" to the OpenArena installation folder name ("openarena-0.8.8à" or "openarena-088£" or "openarenaà-0.8.8")

• Using 0.8.8 binaries it works well (apart from the small detail that the special character looks like a blank space in console)
• Using nightly build binaries 2023/11/07, the game cannot start: "couldn't load default.cfg" error.

About homepath (settings/autodownload folder):
For the test, I added "à" to the fs_homepath command line parameter. It seems the game ignores the special character and everything follwing it. It looks like it does the same with both 0.8.8 binaries and nightly build 2023/11/07.

• openarena.exe +set fs_homepath c:\folder\openarenaà
  results in game settings in c:\folder\openarena\baseoa
• openarena.exe +set fs_homepath c:\folder\openàarena
  results in game settings in c:\folder\open\baseoa
• openarena.exe +set fs_homepath c:\folder\àopenarena
  results in game settings in c:\folder\baseoa

Workaround is obviously avoiding using accented letters (or some other special characters) in paths, however maybe something could be improved in the engine.

[leilei-]

This could be build or lib related as I can't reproduce this with my usual mingw gcc 4.7.2 builds

[leilei-]

Mildly interesting that Trenchbroom (map editor) has a similar bug (currently not fixed)

TrenchBroom/TrenchBroom#4652

[The-Gig]

Yes, if your manual builds and Sago's docker nigthly builds behave differently, then I guess it may be some different compiling switch, or some other difference related to the environment (windows, linux, etc) or building tools used...

[sago007]

It is likely an encoding issue.
SDL forces the argv parameter to be UTF-8 encoded but I believe most calls are in ANSI mode.

I am a bit surprised that it has ever worked with an SDL build. As far as I know SDL has always converted argv arguments to UTF-8.