khallaandClaude Opus 5.5
09f7dcc0f4
Primitives covering the whole 1024x768 layout inside a moved window, such as the dimming behind the exit confirmation, were shifted with the window and left both sides undimmed; they are stretched to the render width instead. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
61 lines
3.2 KiB
Markdown
61 lines
3.2 KiB
Markdown
# HUD layout in widened views (`src/mods/hud.cpp`)
|
|
|
|
The UI is laid out for 1024x768. In a widened render target (e.g. 1835x768)
|
|
the windows are moved as a whole, without touching their own coordinates:
|
|
the bottom bar and all dialogs are centred, the party panel (portrait, health)
|
|
sits at the right edge. Main menu and loading screen keep the classic 1024x768
|
|
frame (see `widescreen.md`).
|
|
|
|
## How a window is moved
|
|
|
|
A window's render and event methods are hooked (`HUD_RENDER`, `HUD_RENDER3`,
|
|
`HUD_EVENT`). While one of them runs on a thread, everything the window sees or
|
|
draws is translated by its offset `dx` (outermost window wins, children and
|
|
shared base methods are inside the scope):
|
|
|
|
| What | Where | Translation |
|
|
|---|---|---|
|
|
| screen-space vertices (`XYZRHW`) | `IDirect3DDevice7::DrawPrimitive` / `DrawIndexedPrimitive` (vtable 25 / 26) | x + dx |
|
|
| 3D items (belt, equipment) | ortho projection centred on the screen | none needed |
|
|
| mouse events | `cEvent_mouseMove` x at +4 (previous) and +0xc; button down / up x at +8 | x - dx, restored afterwards |
|
|
| mouse cursor object (`*0xcdbadc`, accessor `0x6550f0`) | x at +4, previous x at +0xc (polled for hover, item pick-up `0x6559a0`) | the accessor returns a per-thread copy with x - dx; dwords the window changed are written back afterwards |
|
|
| `GetMouseClientPos` (`0x66e500`) | polled position | x - dx |
|
|
|
|
## Calls outside a window's scope
|
|
|
|
- Tooltips (`cUI_Tooltip::vf14` `0x6e7300`) are separate windows that the
|
|
hovered window positions in its own layout: they draw with the offset of the
|
|
moved window under the cursor (noted while windows render, expires after
|
|
150 ms).
|
|
- Hit tests (`vf1c`: `0x731d40`, taskbar `0x6dfb10`) are also called by the UI
|
|
manager with plain render coordinates, e.g. "is UI under the cursor" for
|
|
world picking (`0x75a370`). They use the offset the top-level window (parent
|
|
chain at +0x50) was last drawn with.
|
|
- The item carried by the cursor (`0x6555e0`, drawn by the render loop) and the
|
|
manager's status line / message box (`0x75bbf0`, `0x75c200`, laid out around
|
|
x = 512) draw with the centre offset.
|
|
|
|
## UI events
|
|
|
|
`vf04` of an event is its category: 1 mouse move, 2 button down, 3 button up,
|
|
4 key (code at +8), 5 UI command (`cEventUI2`: id at +4, vf08 subtype). Only
|
|
mouse events carry positions; category 5 events with subtype 0x10 test a point
|
|
at +0x48 in `cUI_Window2::vf10`, but commands such as "open ESC menu" (0x11)
|
|
keep unrelated data there.
|
|
|
|
## Why the cursor is copied, not shifted
|
|
|
|
UI windows render on the render thread while world input (picking,
|
|
hold-to-move, `0x611f10`) reads the same cursor object on another thread.
|
|
Shifting the shared object for the duration of a window's scope let the world
|
|
sample a position ~400 px off now and then (jerky hold-to-move). Every user of
|
|
the cursor goes through the accessor `0x6550f0`, so inside a moved window it
|
|
returns a thread-local copy instead (with its own CRITICAL_SECTION at +0x24;
|
|
copying and writing back hold the real object's lock).
|
|
|
|
## Full-screen layers
|
|
|
|
A primitive drawn inside a moved window that covers the whole 1024x768 layout
|
|
(e.g. the dimming behind the exit confirmation) is stretched across the render
|
|
width instead of shifted.
|