Fix the building-window framerate collapse - #16
Open
stevenbg wants to merge 2 commits into
Open
Conversation
…-thrash) Opening any building window drops the game from 48 to ~17 fps - worst in the shipyard - because the graphics library ddraw_Dll.dll (Ascaron's SGL, project SGL_DDRAW) keeps decoded sprite images in an LRU cache with a 16 MiB default budget, and one town view plus an open building window needs ~19.4 MB. The evictor (usage counter module+0x80F14, budget module+0x5F734, loops +0x1C2EF/+0x1C39A) then frees exactly the images the next frame redraws, so the dimmed town and the interior re-decode from the archives every frame: ~800 ms of AIM.dll decoding per second, measured. Raising the budget lets usage settle at the working set and restores 48 fps within a second. The knob was meant to be configurable: gl.cfg's "TextureCacheSize" key (GOG even ships 48000000) - but the parser in this build is dead code, its section scanner has no callers and nothing references the "gl.cfg" string. The fix writes 128 MiB into the budget once ddraw_Dll.dll is loaded, guarded on finding the 16 MiB default so other builds are left alone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
128 MiB fixed the thrash but made display mode switches noticeably slower - alt+tab to the desktop, or ESC into the menu, which runs at its own resolution. A mode switch releases and rebuilds the cached surfaces, so the larger the cache, the more there is to tear down and decode again. 48 MiB is about 2.5x the measured ~19.4 MB working set, which keeps the thrash fixed while the switches feel like vanilla again. It is also the ballpark of the 48000000 GOG wrote into gl.cfg, suggesting the original developers had converged on a similar figure before that config path went dead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
I've always wondered why opening the Shipyard drops the frame rate. Now we know.
Opening any building window drops the game from 48 to ~17 fps - worst in the shipyard - because the graphics library ddraw_Dll.dll (Ascaron's SGL, project SGL_DDRAW) keeps decoded sprite images in an LRU cache with a 16 MiB default budget, and one town view plus an open building window needs ~19.4 MB. The evictor (usage counter module+0x80F14, budget module+0x5F734, loops +0x1C2EF/+0x1C39A) then frees exactly the images the next frame redraws, so the dimmed town and the interior re-decode from the archives every frame: ~800 ms of AIM.dll decoding per second, measured. Raising the budget lets usage settle at the working set and restores 48 fps within a second.
The knob was meant to be configurable: gl.cfg's "TextureCacheSize" key (GOG even ships 48000000) - but the parser in this build is dead code, its section scanner has no callers and nothing references the "gl.cfg" string. The fix writes 48 MiB into the budget once ddraw_Dll.dll is loaded, guarded on finding the 16 MiB default so other builds are left alone.