Category: Week 5

Hi everyone, this is week 5 of my GSoC project. Work on the Dungeon Master engine is almost at an end — except for one last hurdle, which I’ll discuss later.

The Unresponsive Wall

At level 13, casting Zo Kath Ra spell to open the wall should free the power gem — but the wall stayed completely unresponsive.

Cause:

for (thingBeingProcessed = squareFirstThing; thingBeingProcessed != _vm->_thingEndOfList; thingBeingProcessed = dungeon.getNextThing(thingBeingProcessed)) {
		Thing lastProcessedThing = thingBeingProcessed;

The lastProcessedThing pointer was being updated to thingBeingProcessed at the start of each iteration. Before unlinking this particular sensor, the code checks if (lastProcessedThing == thingBeingProcessed). Since both pointed to the same thing, this check always failed and the sensor was never unlinked, failing to trigger the next sensor.

Fix:  updating lastProcessedThing to thingBeingProcessed before updating thingBeingProcessed resolved the issue.

Shade Screen Box

Next I implemented DisplayMan::shadeScreenBox. It draws a checkerboard pattern over a given box by coloring every other pixel based on alternating coordinates, creating a semi-transparent shading overlay on top of whatever was already drawn there, graying out menus or buttons.

Before:

After:

Before:

After:

Before:

After:

Fix blitToBitmapShrinkWithPalChange()

Enabled palette translation in blitToBitmapShrinkWithPalChange by mapping each source pixel through the translation table and dividing by 10 to account for the original game’s 10-multiplier scale.

A spell stone kept on ground:

When viewed from a distance of 2 tiles, it looks:
Before (without Palette translation):

After (with Palette translation):

Segfault on restart

Restarting after your party is dead would result in a crash with buffer overflow.

Cause:  On restart, loadDungeonFile() was skipping reallocation to reuse existing buffers — but if the new dungeon needed more space than what was previously allocated, writes would go out of bounds.

Fix:  Track each thing type’s allocated capacity in _allocatedThingCounts. On restart, if the new dungeon’s count exceeds what was previously allocated, reallocate and update the tracked limit

Runtime errors

Some places in the code used << on signed integers, which is undefined behavior in C++ when the value is negative.

Fix: Replaced those with * to get the same result safely.

Another instance,

int16 attribMask = 1;
for (uint16 stringIndex = 0; stringIndex < 16; stringIndex++, attribMask <<= 1) {

On the 16th iteration the value overflowed the int type, causing signed integer overflow.

Fix: changed attribMask to uint16

Fixing blitBoxFilledWithMaskedBitmap()

*nextDestPixel = *mask & nextSrcPixel;

Cause:  Doing a bitwise-AND directly on ScummVM’s 1 byte per pixel format corrupts the resulting color palette index. The combined indexes produced garbage color index numbers, leading to severely corrupted/incorrect pixel colors on the screen

Fix:  Rewrote the logic to pick the mask color directly if it isn’t white, or fall back to the source pixel if it isn’t transparent.

Spellcasting Tabs Display

Cause: The highlight screen box was using an XOR mask of 0x0F, but only the 3rd bit needed to be flipped, producing the wrong highlight color on the spellcasting tabs.

Fix:  Changed the mask to 0x04.

Before:

After:

The one last hurdle

Issue:  loadDungeonFile() reads Big-Endian file data and stores it into _thingData as native-endian uint16s. But the gameplay macros like DOOR_nextThing access this memory using READ_LE_UINT16 and WRITE_LE_UINT16, which always expect Little-Endian memory layout. On Big-Endian machines this setup won’t work.

Proper Fix:  As Sev suggested, I would parse the file data on load directly into arrays of structs, so the engine can just address those structs directly instead of re-parsing every time. This time it won’t take much time as I’m already familiar with the places these macros are used.