Dungeon Master Forum

I’m looking for any historical/reverse-engineering notes about **DM PC v3.4 `GRAPHICS.DAT` item 0312**.

In both DMExtract and Greatstone’s PC graphics DB it maps to **Wall Ornate 26 (Front) = Gold Lock**. In our ReDMCSB compatibility work, `0312` behaves unusually together with `0308` (Topaz Lock Front): both remain stable where several other front-lock graphics do not.

Has anyone documented anything special about **0312** specifically, either in the PC version, old extractor notes, or rendering experiments?

First, welcome to this forum.

I wrote ReDMCSB, and I am not aware of anything special with that graphic.

What is the "ReDMCSB compatibility work" you mention? I don't understand what you mean by "behaves unusually", "remain stable".
Please clarify your issue and provide context, otherwise I'm afraid no one will be able to answer your question.

Thanks, and thank you for replying.

By “ReDMCSB compatibility work”, I mean that I am analysing and reproducing original `GRAPHICS.DAT` behaviour in a compatibility/reimplementation context, using the original assets and trying to distinguish content-driven effects from engine-driven ones.

What drew my attention to graphic 308 was not that it appears obviously special in isolation, but that during repeated comparative analysis of neighbouring entries in the same late range, it behaved as an outlier. In my tests, some nearby graphics were more easily perturbed by the transformations or compatibility probes I was running, while 308 remained comparatively stable. That made me wonder whether there was any historical reason for it, such as special treatment, a different usage role, or metadata/handling that was not obvious from the bitmap alone.

So the precise question is:

- Is graphic 308 known to have any special role in the original data or engine logic?
- Is it grouped or used differently from nearby entries in that part of `GRAPHICS.DAT`?
- Or should I assume it is an ordinary entry, and that the outlier behaviour is purely a consequence of its encoded image content?

For context, I am comparing it mainly against neighbouring entries in the same block, and by “stable” I mean that it remains comparatively unchanged under the specific compatibility/decode experiments I am running, whereas adjacent entries diverge more noticeably.

If helpful, I can post the exact entry range and a more concrete description of the observed differences.

What I can tell is that the source code does not have any special case for handling that graphic compared to the others.