Weird doors ?

[Childarion]

Hello,

First congratulation for the development of CSBWin, DSB and ReDMCSB !
I dug into the code during the last few months and the least I could say is that the code is bit hard to read (I'm a professional C++ Developer ).
I manage to understand C++ code written as C (looking at you CSBWin).
Plain C is still OK but I had to learn Lua for DSB.
I really tried to look at ReDMCSB but the assembly code is a bit too much for me ...

Anyway I made this post because I used part of CSBWin code I found on GitHub to extract the graphics of DM. I know it has already been done but I wanted to generate 8A8R8G8B Bitmap files for doors with overlays at the right position.
And when I managed to do it, I stumbled upon two really weird looking doors.
First one is the door just before the ZOOOOM in level 9, it's the only instance of a door that uses a portcullis as base and the rectangular handlebars as overlay.
When I saw my rendering I thought it was wrong because the handle bars looks like they are floating in the portcullis void (I'm new to this forum, not sure how to post a picture).

So I had a look to CSB rendering and indeed it's weird as well.
I found a youtube video of a playthrough of "Dungeon Master HD" (whatever it might be) that show briefly this door, and the handlebars are neatly integrated into the second row of the portcullis "holes" which seems that is the intended rendering (I don't remember this door being weird during my original playthrough on my father's Atari 520 STF 30 years ago, but as it's a single door on the whole dungeon ...)

So I checked DSB rendering with DM conversion for DSB, and the rendering is the same as CSBWin (maybe because of the conversion ...)

Next step was to have a look at ReDMCSB but I'm really rebuked by the ASM code for bitmap rendering, and it seems the x/y offsets of door overlays are encoded in the graphics.dat file anyway so maybe it's irrelevant.

All of that to ask you about this weird door, do anyone has found a rendering of it that looks great ? Could it be a bug in the Atari ST graphics.dat for the x/y coordinate ? Or maybe the dungeon.dat reference a wrong id for the overlay that should point to other x/y coordinate in the graphics.dat ?

There are also two instances of portcullis with rounded handlebars overlay on level 11 but they are doors that you encounter sideways and they open when you pass in front so you would have to be quick to notice them.

[ChristopheF]

(as a new member of the forum, you are not allowed yet to upload images yet, this will become possible after you have made a few posts)

You have found a new bug that I was not aware of. Both of the door ornaments you mention (and no other door ornaments in the game), i.e. the "square grid" on the door at (09,30,22) and "arched grid" at (11,43,31) and (11,45,31), use the coordinates set #0 for door ornaments and are affected by this bug.
I made a few tests. On the attached screenshot, on the left is the door as seen in CSBwin (I also confirmed the same issue in the original DM for Atari ST 1.2 English), and on the right the door in DM for PC 3.4 English.
I did not test other versions. From the ReDMCSB source code (variables G0196_auc_Graphic558_DoorOrnamentCoordinateSetIndices and G0207_aaauc_Graphic558_DoorOrnamentCoordinateSets), I can already say that the same bad coordinates are also used in DM for Apple IIGS and DM for Amiga version 2.x.
I can't say yet for other versions as coordinates are not as easy to read.

[Cycl0ne]

Hi Childarion,

welcome to the forums. Here a small explanation from my side, because it made me alot of Headaches 2 Years ago.
With the switch from 1.x to 2.x+ of DM/CSB they used a LAY1 Structure in graphics.dat (you can extract it with my python tool: dmcsb in pypi with all graphics in the format you like)
Pre-LAY1 (V1.x) was hardcoded into the "binary" file of DM.

The speciality in this Lay1: its a big routine in the code that handles that, its now all relative to anchorpoints, which can have anchorpoints, which have anchorpoints. (Something similiar like CSS in webtechnology). My Assumptions: this was done to make the game portable to other systems with other resolutions (Amiga PAL 320x256 vs Amiga NTSC 320x200, etc.)

The stripped down C code transfered to python is like this:
https://codeberg.org/CyCl0ne/pyDM/src/b ... ne/zone.py

so if you want to convert anything for your bitmaps, you need to traverse the LAY1 struct, access it via the ZONE_ID and you get the coordinates to blit.

I just started today on documenting the LAY1 from the code:
https://codeberg.org/CyCl0ne/pyDM/src/b ... RIPTION.md

The only doc at the moment is an ExcelSheet partly in French on the wiki.

[ChristopheF]

With the switch from 1.x to 2.x+ of DM/CSB they used a LAY1 Structure in graphics.dat

That's not so simple. The switch was more between 2.x and 3.x, although DM for FM-Towns and PC-9801 are 2.0 and yet they use the new coordinate system.

- Old: DM/CSB for Atari ST, Apple IIGS and Amiga 2.x use lots of data arrays to store screen coordinates. On Atari ST, most of these coordinates are stored in binary item #558 in graphics.dat, with some other scattered in many places in the program code. On Apple IIGS and Amiga, there is no item #558 and all coordinates are stored directly in the executable itself.

- New: DM/CSB for Amiga 3.x versions, PC, FM-Towns, X68000, and PC-9801 use a "unified" data structure to describe the layout of things on the screen.
DM for FM-Towns, X68000 and PC-9801 store this unified data structure in the executable.
DM/CSB for Amiga 3.x, DM for PC, CSB for FM-Towns, X68000 and PC-9801 store this unified data structure in the graphics.dat file, as a separate binary item that I named LAY1 in my doc.