Revert the workaround of loading of hd textures#999
Merged
codeHusky merged 1 commit intosmartcmd:mainfrom Mar 9, 2026
Merged
Conversation
The previous crash fix forced HD skins at every resolution which made everything blurry at 720p and below because Iggy was downscaling 1080p assets. The real problem was that 4J loaded the HD skin libraries (skinHD.swf, skinHDHud.swf etc) unconditionally on Win64 but the HD platform skin was only registered above 720p. At 720p or lower Iggy couldnt find platformskinHD.swf and crashed. Now on Win64 we load both skin sets at startup, HD and non-HD, each with their own registered name so they dont conflict. loadMovie() picks 1080.swf or 720.swf based on actual screen height, and each scene SWF naturally imports the right skin chain. No crash, no blurriness. 4J already had the eLibraryFallback enum slots for this (including eLibraryFallback_Platform) but it was behind a debug-only guard and the platform skin slot was never actually loaded. Removed the guard and added the missing load.
Collaborator
|
Tested and seems to work |
piebotc
pushed a commit
to piebotc/LegacyEvolved
that referenced
this pull request
Mar 9, 2026
The previous crash fix forced HD skins at every resolution which made everything blurry at 720p and below because Iggy was downscaling 1080p assets. The real problem was that 4J loaded the HD skin libraries (skinHD.swf, skinHDHud.swf etc) unconditionally on Win64 but the HD platform skin was only registered above 720p. At 720p or lower Iggy couldnt find platformskinHD.swf and crashed. Now on Win64 we load both skin sets at startup, HD and non-HD, each with their own registered name so they dont conflict. loadMovie() picks 1080.swf or 720.swf based on actual screen height, and each scene SWF naturally imports the right skin chain. No crash, no blurriness. 4J already had the eLibraryFallback enum slots for this (including eLibraryFallback_Platform) but it was behind a debug-only guard and the platform skin slot was never actually loaded. Removed the guard and added the missing load.
Kamenkovic
pushed a commit
to Kamenkovic/VSync
that referenced
this pull request
Mar 9, 2026
The previous crash fix forced HD skins at every resolution which made everything blurry at 720p and below because Iggy was downscaling 1080p assets. The real problem was that 4J loaded the HD skin libraries (skinHD.swf, skinHDHud.swf etc) unconditionally on Win64 but the HD platform skin was only registered above 720p. At 720p or lower Iggy couldnt find platformskinHD.swf and crashed. Now on Win64 we load both skin sets at startup, HD and non-HD, each with their own registered name so they dont conflict. loadMovie() picks 1080.swf or 720.swf based on actual screen height, and each scene SWF naturally imports the right skin chain. No crash, no blurriness. 4J already had the eLibraryFallback enum slots for this (including eLibraryFallback_Platform) but it was behind a debug-only guard and the platform skin slot was never actually loaded. Removed the guard and added the missing load.
MrTheShy
added a commit
to MrTheShy/MinecraftConsoles
that referenced
this pull request
Mar 9, 2026
…ain compile error Merges 19 commits from smartcmd/MinecraftConsoles (upstream/main) into the dedicated-server branch and resolves the resulting networking conflicts while preserving all dedicated-server-specific behaviour. --- Upstream commits included in this merge: - Port over RCE Patches from LCEMP (smartcmd#1023) Hardened packet parsing across ByteArrayInputStream/OutputStream, Tag, Socket, Connection, and a dozen packet types; bounds-checked reads, length limits, and safe decompression paths to close known RCE vectors. - Revert accidentally pushed "LCEMP RCE fixes" / LCEMP RCE fixes Intermediate clean-up of the above work. - Reject duplicate UIDs on login and remove noisy gdraw debug log (smartcmd#1013) Incoming players whose UID is already active are now disconnected instead of force-kicking the existing player. Removes a per-frame debug printf left in gdraw_SetViewSizeAndWorldScale. - Always show version overlay, add more info Version string is now always visible at runtime. - Fix split-screen UI wrong positioning on window resize (smartcmd#989) - Reimplement boat gravity again (smartcmd#988) - Use correctly sized icons on 720p (smartcmd#883) - Revert workaround for loading HD textures (smartcmd#999) - Fix crash when launching at 720p or lower resolutions (smartcmd#981) - Modernize project codebase (smartcmd#906): NULL → nullptr, C-style cast → C++ cast, shared_ptr(new …) → make_shared, misc type fixes. - Split screen, widescreen support, font rendering and UI scaling fixes (smartcmd#767) - Flame not working with one-shot arrow (smartcmd#856) - Fix focus sound playing repeatedly on mouse hover (smartcmd#890) - Fix stale held item appearing when switching worlds (smartcmd#910) - Fix F3 debug crash when throwing ender pearl long distance (smartcmd#934) - Allow closing some menus with inventory/crafting keys (smartcmd#868) - Fix second-person nametag pitch (smartcmd#963) --- Conflict resolutions (4 files): Minecraft.Client/Common/Network/GameNetworkManager.cpp Conflict 1 — variable declarations in StartNetworkGame: Kept HEAD. The dedicated-server branch declares `dedicatedNoLocalHostPlayer` here and reads it from NetworkGameInitData. Upstream had dropped that variable while modernising the NULL → nullptr style; keeping it is required for the dedicated-server startup path. Conflict 2 — primary-player connection block: Kept HEAD. When `dedicatedNoLocalHostPlayer` is true the branch intentionally skips creating a local-host ClientConnection and goes straight to setting the game mode. Upstream's refactor created a ClientConnection with a null socket even for the dedicated path and ran the full tick loop; that approach is incompatible with headless operation. Minecraft.Client/PendingConnection.cpp Kept HEAD. The branch wraps the duplicate-XUID rejection path with a #if MINECRAFT_SERVER_BUILD guard that calls ServerLogManager::OnRejectedPlayerLogin. Upstream's version removed that call and rewrote only the comment. Preserving the guard keeps the server-build audit log intact. Minecraft.Client/ServerConnection.cpp Kept HEAD comment. Both sides changed only a single-line comment above the playerSnapshot vector. HEAD's comment ("Disconnect through PlayerConnection so clients receive a proper DisconnectPacket before socket close") describes the functional intent; it was kept as the more meaningful description for this branch. Minecraft.Client/Windows64/Network/WinsockNetLayer.cpp Conflicts 1 & 2 — shutdown thread teardown: Hybrid: adopted upstream's nullptr style (consistent with the rest of the file after the modernisation PR) while keeping HEAD's more precise comment ("Ensure all host-side receive threads have exited before destroying locks"). Conflict 3 — AcceptThreadProc accept() call: Kept HEAD. HEAD passes sockaddr_in remoteAddress to accept() so that TryGetNumericRemoteIp can extract the client IP for connection logging and the IP-ban check (ServerRuntime::Access::IsIpBanned). Upstream had simplified the call to accept(…, nullptr, nullptr), which would have silently broken IP-based access control in the server build. --- fix: declare extern ConsoleUIController ui in ServerMain.cpp Windows64_UIController.h (included by ServerMain.cpp) defines the class but does not forward-declare the global `ui` instance. The `extern ConsoleUIController ui` declaration lives only in Common/UI/UI.h, which is not in ServerMain.cpp's include chain. The object is defined in Windows64_UIController.cpp, which IS compiled as part of Minecraft.Server.vcxproj, so the linker already sees it; the missing declaration caused a C2065 compile error only in the server translation unit. Added the extern declaration alongside the other extern globals at the top of ServerMain.cpp.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fix blurry UI at sub-HD resolutions on Win64 by loading both HD and non-HD skin sets and picking the right scene SWF based on actual screen height.
Changes
Previous Behavior
The earlier crash fix (from #981) forced HD skins at every resolution to prevent Iggy from failing to resolve
platformskinHD.swf. This fixed the crash but at 720p and below Iggy was downscaling 1080p assets and everything looked blurry.Root Cause
Two issues, both from 4J's original code:
The HD skin libraries (
skinHD.swf,skinHDHud.swf, etc.) are loaded unconditionally on Win64/Durango/Orbis. These SWFs internallyimport platformskinHD.swf. But the platform skin registration was behind a runtime resolution check — at <=720p it registeredskinWin.swfasplatformskin.swfinstead ofplatformskinHD.swf, so Iggy couldn't resolve the import and crashed.loadMovie()on Win64 was hardcoded to always load the 1080p scene SWF variant (*1080.swf), regardless of actual window size. The 1080p scenes import HD skins, so even if you fixed the platform skin you'd still be using HD assets at low resolutions.4J actually started building a solution for this — they defined
eLibraryFallback_*enum slots (includingeLibraryFallback_Platform) and had code to load the non-HD skins into them, but it was gated behind#ifndef _FINAL_BUILD(debug only) and the platform skin slot was never actually loaded. So the fallback was incomplete and non-functional.New Behavior
The game starts and runs correctly at any resolution on Win64. Above 720p it uses 1080p scene SWFs with HD skins (same as before). At 720p and below it uses 720p scene SWFs with non-HD skins — native assets for the resolution, no downscaling, no blurriness. No crash at any resolution.
Fix Implementation
UIController.h: Removed the_FINAL_BUILDpreprocessor guard around theeLibraryFallback_*enum entries so they're available in release builds, not just debug.UIController.cpp—loadSkins(): Rewrote the Win64 path to load both skin sets at startup:eLibrary_Platform=skinHDWin.swfregistered asplatformskinHD.swfeLibraryFallback_Platform=skinWin.swfregistered asplatformskin.swf(this was the 4J bug — slot existed but was never loaded)eLibrary_*= all HD skins (skinHDGraphics.swf,skinHD.swf, etc.)eLibraryFallback_*= all non-HD skins (skinGraphics.swf,skin.swf, etc.)Both sets use distinct registered names so they coexist in the same Iggy session without conflicts.
UIScene.cpp—loadMovie(): On Win64 the scene SWF resolution is now chosen based on actual screen height instead of being hardcoded to 1080p:>720ploads*1080.swf(these import HD skins which importplatformskinHD.swf)<=720ploads*720.swf(these import non-HD skins which importplatformskin.swf)The existing fallback (try 720 if 1080 file is missing) still works as a safety net.
AI Use Disclosure
Ai was used to write this pr description.
Related Issues