Configurable username (username.txt) and persistent game settings (settings.dat)

[dtentiion]

Description

Adds two persistent player-facing features to the Windows 64-bit build: a configurable in-game username read from a plain-text file, and full persistence of game settings (gamma, audio levels, difficulty, HUD flags, etc.) across restarts via a binary save file. Also implements save thumbnail capture and fixes the working directory so all asset paths resolve correctly when launching from any location.

Desktop.2026.03.01.-.23.42.43.01.2.mp4

Desktop.2026.03.02.-.00.44.37.02.1.mp4

Changes

Previous Behavior

• The player's in-game name and nametag was hardcoded to "Windows" and/or "stub" regardless of who was playing.
• All game settings (gamma, music/sound volume, difficulty, debug flags, etc.) reset to defaults every time the game was launched, there was no mechanism to persist them on Windows 64-bit.
• CaptureSaveThumbnail() and GetSaveThumbnail() were empty stubs, so world saves never stored a thumbnail image.
• The working directory was not set to the executable's directory, causing asset path resolution to fail when the exe was launched from a different location.

Root Cause

• The Windows 64-bit platform stub for IQNetPlayer::GetGamertag() returned a hardcoded string with no hook for user configuration.
• InitGameSettings() and CheckGameSettingsChanged() had no _WINDOWS64 branch to read or write settings to disk, the existing paths only covered console platforms (Xbox, PlayStation, etc.).
• The thumbnail functions were intentional stubs left unimplemented in the original port.
• No call to SetCurrentDirectoryA was made at startup, so relative paths used throughout the engine only worked correctly when launching via Visual Studio.

New Behavior

• On startup the game reads username.txt from the same folder as the executable. The first line becomes the player's in-game name and nametag. If the file is absent the name defaults to "Windows".
• All game settings are automatically saved to settings.dat (next to the exe) whenever a setting changes, and loaded back on the next launch. Deleting the file resets everything to defaults.
• World saves now capture and store a thumbnail screenshot via RenderManager.CaptureThumbnail().
• The working directory is set to the executable's directory at startup, so the game can be launched from any location without missing assets.

Fix Implementation

• Windows64_App.cpp: Added wstring g_playerName global and a LoadPlayerName() helper that uses GetModuleFileNameA to locate username.txt relative to the exe. Called from the CConsoleMinecraftApp constructor and from TemporaryCreateGameStart(). Implemented CaptureSaveThumbnail(), GetSaveThumbnail(), and ReleaseSaveThumbnail() using an ImageFileBuffer member on CConsoleMinecraftApp.
• Windows64_App.h: Added #include "4JLibs\inc\4J_Render.h" and the ImageFileBuffer m_ThumbnailBuffer private member.
• Extrax64Stubs.cpp: IQNetPlayer::GetGamertag() now returns g_playerName.c_str() (falling back to L"Windows" if empty) instead of a ProfileManager lookup.
• Consoles_App.cpp: Added _WINDOWS64-gated Win64_GetSettingsPath(), Win64_SaveSettings(), and Win64_LoadSettings() static helpers. InitGameSettings() now calls Win64_LoadSettings + ApplyGameSettingsChanged after SetDefaultOptions. CheckGameSettingsChanged() calls Win64_SaveSettings whenever settings are flushed on both the loop and single-pad code paths.
• Windows64_Minecraft.cpp: Added a SetCurrentDirectoryA call at the top of _tWinMain to set the CWD to the exe's directory.

Related Issues

• Fixes [Bug]: Save #56
• Related to [Bug]: Save #56

[smartcmd]

good job

[smartcmd]

Need to resolve the conflicts

[simulpingus]

saves should go under Windows64\GameConfig\Minecraft.gameconfig

[void2012]

Resolve the branch conflicts and this one will be merged

[void2012]

@simulpingus, @dtentiion please resolve the #217 and #218