Pan with the arrows, zoom with plus and minus, [ and ] for the next track. Self-contained HTML with the track data and palette embedded; nothing here ships, and pack-dist.ps1 does not look at it. It follows the engine rather than approximating it. NavDisplay derives metersPerPixel from the zoom and sets LODIndex to it; L4GaugeImage::Draw takes the first LOD whose scale is at least that value and draws nothing once the value runs past the largest, so objects vanish rather than simplify. Both map gauges are here because they disagree - nav is the 448x416 radar screen with LOD following zoom, gps the 125x203 panel whose config pins LOD at 1.0. The HUD reports what is dropped, and is honest that this content barely exercises it: every placement in every track is cn3 with one LOD at scale 1000. The map is not a phosphor screen. Primitives carry palette indices and the palette is whichever the port was configured with - for the pod's secondary port, configure(0,sec,270,0x00ff,clut0,rgb,secpal.pcc). PCC is PCX, so the palette is the last 769 bytes. Walls are grey because index 51 is #4b4b4b; background is index 0, black; a primitive with colour 0 keeps the display's staticColor, 0x3C. Per-file palettes, not a global one - 39 of 40 gauge PCCs differ - so the port's configured palette is the one that counts.
60 lines
2.2 KiB
Smarty
60 lines
2.2 KiB
Smarty
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<title>Red Planet map viewer</title>
|
|
<style>{css}</style>
|
|
</head>
|
|
<body>
|
|
|
|
<div id="screen">
|
|
<canvas id="view" tabindex="0" aria-label="Track map"></canvas>
|
|
<div id="scale"><span id="barline"></span><span id="bartext"></span></div>
|
|
</div>
|
|
|
|
<aside>
|
|
<div>
|
|
<h1 id="name">—</h1>
|
|
<p id="key"></p>
|
|
</div>
|
|
|
|
<select id="track" aria-label="Track"></select>
|
|
|
|
<dl id="stats"></dl>
|
|
|
|
<div class="note">
|
|
<div class="keys">
|
|
<span><kbd>↑</kbd><kbd>↓</kbd><kbd>←</kbd><kbd>→</kbd></span><span>pan N/S/E/W</span>
|
|
<span><kbd>+</kbd><kbd>-</kbd></span><span>zoom</span>
|
|
<span><kbd>[</kbd><kbd>]</kbd></span><span>previous / next track</span>
|
|
<span><kbd>F</kbd></span><span>fit the course</span>
|
|
<span><kbd>A</kbd></span><span>fit everything, strays included</span>
|
|
<span><kbd>G</kbd></span><span>GPS / NavDisplay LOD</span>
|
|
</div>
|
|
</div>
|
|
|
|
<p class="note"><b>Dropped by LOD</b> counts what the map screen does not draw
|
|
at all. <code>L4GaugeImage::Draw</code> takes the first LOD whose scale is at
|
|
least the LOD value and draws <em>nothing</em> once the value runs past the
|
|
largest, so objects vanish rather than simplify. Worth knowing what the data
|
|
does with that: every placement in every track is the same model,
|
|
<code>cn3</code>, and it carries one LOD at scale 1000. So the count stays at
|
|
zero until you pass 1000 m/px, when the whole track disappears at once. The
|
|
rule is the engine's; this content just never leans on it.</p>
|
|
|
|
<p class="note"><b>NavDisplay</b> sets its LOD from the zoom
|
|
(<code>LODIndex = metersPerPixel</code>), which is the pannable radar screen,
|
|
448×416 in <code>L4GAUGE.CFG</code>. <b>GPS</b> is the little 125×203
|
|
panel whose LOD the config pins at 1.0 however far out it is scaled.</p>
|
|
|
|
<p class="note">Colours are the game's own: palette indices resolved through
|
|
<code>secpal.pcc</code>, the palette the pod's secondary port is configured
|
|
with. The walls are grey because index 51 is grey.</p>
|
|
</aside>
|
|
|
|
<script id="data" type="application/json">{data}</script>
|
|
<script>{js}</script>
|
|
</body>
|
|
</html>
|