Hello, everyone! With both the European and US Amiga releases of Kult \/ Chamber of the Sci-Mutant Priestess<\/i> playable from start to finish, this week I shifted focus from adding features to hardening what was already there. Last week I mentioned that ScummVM runs the engine through the Coverity and PVS-Studio static analysers, and that their reports had turned up a handful of issues worth looking at. This week I went through those reports properly, and on top of that I chased down a save\/load bug that had been quietly breaking a couple of rooms after loading a game.<\/p>\nWorking through the Coverity report<\/h2>\n
Static analysers are good at spotting the kind of code that is technically wrong but rarely bites in day-to-day play: unreachable branches, resources that are allocated but never freed, and fields that are read before they are written. Chamber is a reimplementation of a 1989 DOS game, so a lot of the code mirrors the original binary very closely \u2014 which means some of these findings are actually faithful reproductions of dead code that was already dead in the original.<\/p>\n
That distinction mattered while reviewing the reports, because I did not want to “fix” something that was deliberately mirroring the disassembly. So for each finding I went back to the original code to confirm what was really going on before touching anything.<\/p>\n
A few of the more interesting ones:<\/p>\n
In In In the CGA blitter, Alongside the dead code, the report caught two genuinely useful things: a memory leak and an uninitialised field. Several call sites were calling PVS-Studio leans towards a different class of finding \u2014 dead stores and redundant expressions \u2014 and it caught a similar mix:<\/p>\n Another impossible clamp in the CGA blitter, this time A dead In In There were also a couple of intentional busy-wait loops that PVS-Studio flagged for having an empty None of these are dramatic bugs, but clearing them keeps the engine’s future reports clean, so real regressions do not get lost in a wall of pre-existing noise.<\/p>\n The most interesting problem this week was not a static-analysis finding at all \u2014 it was a save\/load bug I ran into while testing.<\/p>\n Chamber builds each room from a base decor, but scripts frequently draw persistent changes on top of that: alternate decor sets, extra objects that appear once triggered, and the final frames of animations. The catch is that they draw these directly into the backbuffer. On a fresh visit that is fine, but when you saved and reloaded, the engine rebuilt the room from the base decor only \u2014 so anything a script had painted into the backbuffer was simply gone.<\/p>\n In practice this meant that things like the De Profundis monster, or Deilos, would fail to reappear after loading a game, even though the game state said they should be there. The state was correct; the pixels that represented it had never been saved.<\/p>\n The fix was to bump the save version to That wraps up the cleanup pass I wanted to do before moving on. The engine is now noticeably tidier and more robust, which is a perfect state to leave it in. Starting next week, I will be shifting my focus to a completely different engine. I wonder if anyone can guess which one it will be?(Hint: It will be a great adventure!) Stay tuned, and thanks for reading.<\/p>\n","protected":false},"excerpt":{"rendered":" Hello, everyone! With both the European and US Amiga releases of Kult \/ Chamber of the Sci-Mutant Priestess playable from start to finish, this week I shifted focus from adding features to hardening what was already there. Last week I mentioned that ScummVM runs the engine through the Coverity and PVS-Studio static analysers, and that […]<\/p>\n","protected":false},"author":31,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-80","post","type-post","status-publish","format-standard","hentry","category-gsoc-2026"],"_links":{"self":[{"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/posts\/80","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/comments?post=80"}],"version-history":[{"count":1,"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/posts\/80\/revisions"}],"predecessor-version":[{"id":81,"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/posts\/80\/revisions\/81"}],"wp:attachment":[{"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/media?parent=80"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/categories?post=80"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/andy\/wp-json\/wp\/v2\/tags?post=80"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}CMD_21_VortTalk<\/code>, Coverity flagged a branch guarded by rand_value >= 170<\/code> as unreachable. Checking the disassembly, the num == 7<\/code> case it belonged to is dead in the original too, so the branch could go.<\/p>\n<\/li>\ndrawRoomStatics<\/code>, there was a door check for index == 91<\/code>, but by the time that code runs the index is already constrained to the 50..60<\/code> range, so the check can never be true.<\/p>\n<\/li>\nblitToScreen<\/code> had an endY > 200<\/code> clamp that could never fire, because dy<\/code> and h<\/code> are hardcoded to 0<\/code> and 200<\/code> just above it.<\/p>\n<\/li>\n<\/ul>\nloadFond<\/code> \/ ega_loadFond<\/code> \/ loadSplash<\/code>, which return a Graphics::Surface<\/code>, and then throwing that surface away without freeing it \u2014 a small leak every time a room background or splash was loaded. And the engine’s _speaker<\/code> member was not being initialised in the constructor. Both are the sort of thing that is easy to miss by eye and exactly what these tools are for.<\/p>\nWorking through the PVS-Studio report<\/h2>\n
\n
endX_bytes > 80<\/code> on the horizontal axis, again dead because the width is hardcoded to a full 320<\/code> pixels.<\/p>\n<\/li>\nofs++<\/code> in cga_ZoomInplace<\/code>, immediately followed by ofs<\/code> being reassigned to oofs<\/code>, so the increment never had any effect.<\/p>\n<\/li>\nSCR_23_HidePortrait<\/code>, a left\/right button branch where both arms were identical \u2014 this handler simply has no special behaviour to skip, so the branch collapsed to a single path.<\/p>\n<\/li>\nSCR_46_DeProfundisLowerHook<\/code>, the return value of getPuzzlSprite()<\/code> was being stored into sprofs<\/code> and then overwritten on the very next line, so the first store was pointless.<\/p>\n<\/li>\n<\/ul>\n;<\/code> body. These are genuinely meant to be empty \u2014 they are timing delays \u2014 so instead of silencing the warning I gave them an explicit {}<\/code> body to make the intent obvious to both the analyser and the next person reading the code.<\/p>\nFixing room state that vanished after loading a save<\/h2>\n
2<\/code> and store what was actually missing: the zone palette, the current video mode, and the backbuffer contents themselves. On load, if the video mode matches, the backbuffer is restored verbatim; otherwise the engine falls back to the old rebuild-from-decor behaviour, so older saves and cross-mode loads still work. While I was in there I also made load reapply the room palette and honour the launcher’s save-slot option, so booting straight into a save from the launcher lands you in a correctly coloured room.<\/p>\nLooking ahead<\/h2>\n