Building a new clone/enhanced version of CSB

[yeager]

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?

[ChristopheF]

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.

[yeager]

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.

[ChristopheF]

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

[yeager]

Hi Christophe,

We are working on a source-faithful DM1 PC/V1 implementation and are
using the ReDMCSB source as the primary reference. There are two areas
where we would appreciate your advice.

1. Title animation timing / event schedule

From ReDMCSB we currently understand the PC/F20 title path in
`TITLE.C` / `F0437_STARTEND_DrawTitle` like this:

- `TITLE.C:319-324`: clear/fill screen, then draw the “Presents” strip.
- `TITLE.C:340-360`: build 18 shrinked title bitmaps, starting from
320x80 and shrinking by 16x4 each step down to 48x12.
- `TITLE.C:385-387`: render those shrinked bitmaps in reverse order,
i.e. small to full size, with one `M526_WaitVerticalBlank()` before
each blit.
- first visible zoom step: shrink index 17, box approximately x=136
y=74 w=48 h=12
- final zoom step: shrink index 0, box x=0 y=40 w=320 h=80
- `TITLE.C:395-396`: wait two more vertical blanks after the zoom loop.
- `TITLE.C:397-402`: blit the “Master / Strikes Back” strip.
- destination box comes from `DATA.C`:
`G0003_ai_Graphic562_Box_Title_StrikesBack_Destination =
{0,319,118,174}`
- `TITLE.C:409` / equivalent BUG0_71 comment around `TITLE.C:251`:
final `M526_WaitVerticalBlank()` guard before the next transition.

Question:
Is this the correct event schedule for the original DM1 PC title
animation, or is there another PC-specific delay/fade/input gate we
should preserve before the entrance/menu transition?

2. Champion portrait click path in Hall of Champions

We are also trying to verify the no-party Hall of Champions portrait click path.

The source chain we are following is:

`C007 viewport left-click -> C080_COMMAND_CLICK_IN_DUNGEON_VIEW ->
F0377_COMMAND_ProcessType80_ClickInDungeonView -> C05 wall ornament /
door button zone -> F0372 -> F0275_SENSOR_IsTriggeredByClickOnWall ->
C127_SENSOR_WALL_CHAMPION_PORTRAIT ->
F0280_CHAMPION_AddCandidateChampionToParty`

Relevant source points:

- `COMMAND.C:397-403,2322-2323`: viewport left-click dispatches C080
and calls F0377.
- `CLIKVIEW.C:348-349`: PC build converts screen coordinates to
viewport-relative coordinates by subtracting the viewport origin.
- `CLIKVIEW.C:407-431`: with an empty leader hand, a C05 hit calls F0372.
- `CLIKVIEW.C:21-25`: F0372 computes the front square and calls F0275
on the opposite wall side.
- `MOVESENS.C:1392,1501-1502`: C127 champion portrait sensors are
allowed without a leader and call F0280.
- `DUNVIEW.C:525,3913-3928` and `COORD.C:1693-1698`: portrait box
appears to map to roughly screen x=111,y=82 for the PC viewport
origin.

Runtime evidence from our side:

- DM1/V1 initial party position decodes as map0 x=1 y=3 facing South.
- The front wall square at map0 x=1 y=4 contains sensor 16 of type C127.
- After entering the dungeon view, clicking the source-derived
portrait coordinates does not visibly enter candidate champion state.
- We tried 12 input-delivery variants around x=111,y=82 / x=111,y=80 /
x=112,y=83: helper-scaled window-relative, absolute screen click,
window-relative down/up, and repeated clicks. All produced no visible
change.

Question:
Does original DM1 PC have an additional precondition before C080/F0377
will accept this portrait click in the no-party Hall of Champions
state? Or is the C05 clickable zone for champion portraits only valid
after a specific draw/state update that we may be missing?

Related question:
Is it correct that the same C127 sensor both marks the visible
champion portrait and triggers
`F0280_CHAMPION_AddCandidateChampionToParty`, or is there a separate
mirror/portrait activation path in the original PC version?

Thanks,
Daniel

[ChristopheF]

1) In DM for PC version 3.4, F0437_STARTEND_DrawTitle is empty (see the conditional compilation directives). Instead the title animation is stored as an animation data file, file format here http://dmweb.free.fr/community/document ... nimations/
The animation player program is a separate executable file named ANIM, ReDMCSB also has its source code (see files ANIM*.C).

2) The value of G2210_aai_XYZ_DungeonViewClickable[C05_VIEW_CELL_DOOR_BUTTON_OR_WALL_ORNAMENT] must contain the appropriate screen coordinates before a mouse click on a portrait can produce an effect.
This value is cleared at the beginning of F0128_DUNGEONVIEW_Draw_CPSF (DUNVIEW.C).
Then it may get initialized in F0107_DUNGEONVIEW_IsDrawnWallOrnamentAnAlcove_CPSF (DUNVIEW.C) that copies G2032_ai_XYZ into G2210_aai_XYZ_DungeonViewClickable[C05_VIEW_CELL_DOOR_BUTTON_OR_WALL_ORNAMENT].
G2032_ai_XYZ itself is initialized with a call to F0635_ in F0791_DUNGEONVIEW_DrawBitmapXX when the portrait wall decoration is drawn.
So you cannot click on the portrait before it was drawn, because the "active" area where you can click is not defined until then.

3) The sensor of type 127 (C127_SENSOR_WALL_CHAMPION_PORTRAIT) is displayed as a portrait frame + champion face (in G0289_i_DungeonView_ChampionPortraitOrdinal) by the game engine.
After you add the champion to the party, the sensor type is changed to 0 which actually disables the sensor (done in F0282_CHAMPION_ProcessCommands160To162_ClickInResurrectReincarnatePanel).
There is no "separate mirror/portrait activation path".