Cyd
4979193528
It was drawing the map mirrored. The X flip came from the setup console's picture of Brewer's Bane, which is an illustration and not a screenshot - the game does not draw it that way round. What the game does: L4GaugeImagePrimitive::Draw plots MoveToAbsolute(dest->x, dest->z), so the screen axes are view-space X and Z, and the graphics view's origin is bottom left with Y increasing upward - BackgroundLine draws endpoints.bottomLeft to endpoints.topRight, and the port's zero-degree blit is documented with the origin in the bottom left corner. So +X runs right and +Z runs up. Also added the heading the real display has. NavDisplay centres on the vehicle and turns with it, inverting the viewer's transform and taking yaw only unless rockAndRoll is set; the viewer defaults to heading 0, which is the north-up case, and Q/E/R turn it. Panning and dragging now work in what you see rather than in world axes, so up stays up when the map is turned. TRACKS.html is left following the console pictures on purpose: nine of those cards are the console pictures, so the reconstructed nine have to sit beside them consistently. The two disagree by a mirror and each is right for what it is, which both READMEs now say.
82 lines
3.8 KiB
Markdown
82 lines
3.8 KiB
Markdown
# mapview
|
|
|
|
A dev tool: every track drawn the way the pod's map screen draws it, with pan
|
|
and zoom, so you can ask "what does the map actually show here?" without booting
|
|
the game. Nothing here ships — [pack-dist.ps1](../../pack-dist.ps1) does not
|
|
look at it.
|
|
|
|
```powershell
|
|
python tools\mapview\build_mapview.py <rpl4tool-listing.txt> tools\mapview\mapview.html
|
|
```
|
|
|
|
Then open `mapview.html`. It is self-contained: track data, palette and all.
|
|
|
|
| key | |
|
|
|---|---|
|
|
| <kbd>↑</kbd> <kbd>↓</kbd> <kbd>←</kbd> <kbd>→</kbd> | pan north / south / west / east |
|
|
| <kbd>+</kbd> <kbd>-</kbd> | zoom in / out |
|
|
| <kbd>[</kbd> <kbd>]</kbd> | previous / next track |
|
|
| <kbd>F</kbd> / <kbd>A</kbd> | fit the course / fit everything |
|
|
| <kbd>G</kbd> | GPS or NavDisplay LOD behaviour |
|
|
|
|
Dragging pans and the wheel zooms.
|
|
|
|
## What it reproduces
|
|
|
|
`NavDisplay::CalculateBounds` ([RPL4GAUG.cpp:1587](../../RP_L4/RPL4GAUG.cpp#L1587))
|
|
derives `metersPerPixel` from the zoom and sets `LODIndex` to it. `L4GaugeImage::Draw`
|
|
([L4GAUIMA.cpp:908](../../MUNGA_L4/L4GAUIMA.cpp#L908)) then walks the LOD scales:
|
|
|
|
```c
|
|
for (lod_index = 0; lod_index < LODCount; ++lod_index)
|
|
if (LOD_value <= LODScales[lod_index]) break;
|
|
if (lod_index < LODCount) { ...Draw... } // else nothing is drawn
|
|
```
|
|
|
|
Scales ascend, so index 0 is the finest and running past the largest drops the
|
|
object entirely rather than simplifying it. The viewer does the same and reports
|
|
the count, though this content barely exercises it: every placement in every
|
|
track is `cn3`, which carries a single LOD at scale 1000, so nothing is dropped
|
|
until 1000 m/px and then all of it goes at once.
|
|
|
|
Two display modes, because the game has two map gauges and they disagree:
|
|
|
|
* **NavDisplay** — `nav(A,ModeAlwaysActive,(448,416),0x00,0x3C,...)`. The
|
|
448×416 radar screen, LOD following the zoom.
|
|
* **GPS** — `gps(R,ModeAlwaysActive,(125,203),1.0)`. The 125×203 panel,
|
|
LOD pinned at 1.0 by the config however far out it is scaled.
|
|
|
|
## Colour
|
|
|
|
Not a phosphor screen. Primitives carry palette indices and the palette is
|
|
whichever the port was configured with; for the pod's secondary port, where the
|
|
nav display lives, `L4GAUGE.CFG` says
|
|
`configure(0, sec, 270, 0x00ff, clut0, rgb, secpal.pcc)`. PCC is PCX, so the last
|
|
769 bytes are `0x0C` and 256 RGB triples. The walls come out grey because index
|
|
51 is `#4b4b4b`; the background is index 0, black. A primitive whose own colour
|
|
is 0 keeps the colour already set, which is the display's `staticColor`, `0x3C`.
|
|
|
|
Palettes are per-file, not global — 39 of 40 gauge PCCs differ from each
|
|
other — so the port's configured palette is the one that matters, not any
|
|
convenient nearby image.
|
|
|
|
## Orientation
|
|
|
|
**+X runs right, +Z runs up.** That is the engine's projection rather than a
|
|
choice. `L4GaugeImagePrimitive::Draw` plots `MoveToAbsolute(dest->x, dest->z)`,
|
|
so the screen axes are view-space X and Z; and the graphics view's origin is at
|
|
the bottom left with Y increasing upward — `BackgroundLine` draws
|
|
`endpoints.bottomLeft` to `endpoints.topRight`, and the port's zero-degree blit
|
|
is documented with the origin at the bottom-left corner.
|
|
|
|
Worth knowing: **the setup console's pictures of the tracks are mirrored against
|
|
this.** They are illustrations, not screenshots. The plans in `TRACKS.html`
|
|
deliberately follow the console pictures, because nine of those cards *are* the
|
|
console pictures and the reconstructed nine have to sit beside them consistently.
|
|
This viewer follows the game instead. The two disagree by a mirror, and both are
|
|
right for what they are.
|
|
|
|
The nav display also centres on the vehicle and turns with it, inverting the
|
|
viewer's transform and taking yaw only unless `rockAndRoll` is set. Heading 0
|
|
here is the north-up case; <kbd>Q</kbd>/<kbd>E</kbd> turn the map.
|