Files
RP412/docs/RP412-ROADMAP.md
T
CydandClaude Fable 5 d6745353b1 L4D3D: survive missing textures instead of crashing at mission load
d3d_OBJECT::LoadTexture never checked D3DXCreateTextureFromFileA, cached
the NULL texture, and unconditionally AddRef()ed it - an access violation
on any missing/unreadable texture, hit by every bare working copy because
the pod skins (VIDEO\player1-8) come from the presets/replacement-material
path, not the depot. Failures now log the filename+hr and the draw op
renders untextured, matching the existing no-texture-filename path. Also
guard the unchecked gReplacementData->find() in LoadObject (same latent
UB one branch earlier).

Verified in the sandbox working copy: the game now boots to a running
RPL4 window with -windowed -egg TEST.EGG (RIO served by vRIO), logging
the eight missing pod skins instead of dying in MakeEntityRenderables.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-12 12:41:29 -05:00

123 lines
6.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# RP 4.12 Roadmap — Steam + Internet Multiplayer
Working plan for turning the 4.11 arcade/cockpit build into a consumer Steam
title. Status: initial assessment (2026-07-12). Items marked **[investigate]**
need code archaeology before they become concrete tasks.
## Where 4.11 stands
- **Game**: `rpl4opt.exe`, 32-bit Win32, DirectX 9, VS2005/2008-era `.vcproj`
projects ([BUILD.md](../BUILD.md)). Builds clean on VC++ 2008 Express.
- **Networking**: the engine has a real multiplayer layer —
[MUNGA/NETWORK.cpp](../MUNGA/NETWORK.cpp), [MUNGA/SOCKET.cpp](../MUNGA/SOCKET.cpp),
[MUNGA/HOSTMGR.cpp](../MUNGA/HOSTMGR.cpp), interest management
([MUNGA/INTEREST.cpp](../MUNGA/INTEREST.cpp)), bound to WinSock2 in
[MUNGA_L4/L4NET.CPP](../MUNGA_L4/L4NET.CPP) (TCP; the 2007 WinSock port of the
1995 code). It was built for pods on a dedicated LAN.
- **Input/output**: the pod's controls are a **RIO** serial board (buttons,
five analog axes, lamps) and a **plasma display** (128×32 dot-matrix on COM2,
driven by `MUNGA_L4/L4PLASMA.CPP`). No cockpit, no controls.
- **Session control**: races are configured and launched from the outside by
**TeslaConsole** over the Munga control protocol (TCP 1501, via `Munga Net.dll`),
with TeslaLauncher (TCP 53290) handling app lifecycle on each pod.
## Workstream A — Play without the cockpit (from vRIO)
vRIO already solved the "no hardware" problem once, from the outside: it speaks
the RIO serial protocol as the device, with a complete **keyboard + XInput
bindings model** (deflect/rate/deadzone/invert per axis, bindings file), and
vPLASMA renders the display's recovered command grammar
(`VPlasma.Core/Protocol/PlasmaProtocol.cs`, grammar recovered from
`L4PLASMA.CPP` itself). For 4.12 that logic moves *inside* the game:
**Design principle — recreate the cockpit's feel on screen.** The 4.12 screen
layout places the RIO panel controls *around* the displays in the same
physical arrangement as the pod: MFD button clusters framing the screens,
board columns and keypads where they sit in the cockpit, the plasma glass in
its place above. vRIO's panel layout data (`VRio.Core`, the five MFD
clusters / four board columns / two keypads / encoder-gauge strip) is the
geometry reference — it is already the faithful software copy of the physical
panel. On-screen buttons light with the same lamp states the game commands,
so press-feedback works like the real button field.
- Replace the RIO serial path in the L4 layer with a native input layer
(keyboard / mouse / XInput, later Steam Input). Port vRIO's binding model —
its axis-travel semantics (throttle ratchet, spring-back pedals, ±80 stick)
are exactly what the game expects. **[investigate]** where the L4 layer reads
RIO input, and whether an abstraction seam already exists.
- Render the plasma display in-game (HUD overlay) instead of streaming
`ESC P` graphics to COM2 — `L4PLASMA.CPP` already composes the frame into a
local 1bpp buffer before serializing, so the seam is likely right there.
- Lamp feedback (button lighting) maps to on-screen highlight / controller
rumble / RGB later; low priority.
- vRIO itself stays useful as a dev harness against unmodified builds.
## Workstream B — In-game sessions (from TeslaConsole)
Consumer players get no operator. The create/configure/launch flow that
TeslaConsole drives over TCP 1501 becomes in-game UI:
- Front-end menus: pilot setup, race/mission select, create/join session.
**[investigate]** how much of the mission-launch handshake lives in the game
(`MUNGA` mission/host code) vs. in the console — TeslaSuite's `Contract/` and
the console's Munga-protocol client are the reference implementation.
- **vPOD** (TeslaSuite) impersonates both the game client and launcher — a
ready-made test double while the launch flow is being internalized.
- TeslaLauncher's responsibilities (install, watchdog, auto-login) disappear —
Steam owns install/update/launch.
## Workstream C — Steam + internet multiplayer logistics
### Networking
- The engine's LAN TCP assumptions need auditing before anything else:
**[investigate]** what `HOSTMGR`/`NETWORK` actually synchronize (state
replication vs. lockstep), tick/latency assumptions, and who is authoritative.
A LAN design that tolerates ~1 ms RTT may need prediction/interpolation work
for 50100 ms internet RTTs; the existing interest manager is a good sign.
- Transport: **Steam Networking Sockets** (`ISteamNetworkingSockets`) is the
target — it gives NAT traversal + Steam Datagram Relay for free, hides IPs,
and offers reliable + unreliable channels. Plan: introduce a transport
abstraction under `L4NET` so raw-socket LAN play (dev) and Steam sockets
(retail) coexist.
- Topology: player-hosted (listen server / P2P over SDR) is the low-cost
default for a pod-count-sized race; dedicated servers are a later option.
- Matchmaking: Steam **lobbies** (`ISteamMatchmaking`) for create/join/invite;
friends-list invites come nearly free once lobbies work.
### Steamworks integration
- Steamworks partner account + app credit (Steam Direct, $100/app), appid,
depot layout via SteamPipe. The old `Setup1/` installer project retires —
Steam delivers files; OpenAL / libsndfile runtime DLLs ship in the depot.
- `steam_api.dll` supports 32-bit Win32, so Steam does not *force* a 64-bit
port. It does require init/callback pumping in the main loop and the
overlay hooking D3D9 (works, but test early — old-engine present() paths
sometimes fight the overlay).
- Steam client requires Windows 10+ now, which **frees 4.12 from the XP-era
constraints** that shaped the 4.11/TeslaSuite line.
### Toolchain
-**Done (2026-07-12)** — the solution builds on **VS2022 (v143)** with the
Windows 11 SDK; see [BUILD.md](../BUILD.md) §3 for what changed and why.
Runtime-verified equivalent to the VC9 baseline (including RIO init against
vRIO). Remaining cleanups called out there: un-`/Zp1` the Windows-header
boundary, port `stdext::hash_map``std::unordered_map`, single-TU the
duplicated globals so `/FORCE:MULTIPLE` can go away.
- ✅ The pre-existing mission-load crash (NULL-texture `AddRef` in
`d3d_OBJECT::LoadTexture`) is fixed — missing textures render untextured and
log. The game boots standalone to a running window (BUILD.md §4). Note for
Workstream B: pod skins (`player18`) come from the presets /
replacement-material path the console used to drive; the in-game session UI
must own that.
## Suggested order
1. Toolchain upgrade to VS2022 (unblocks everything, no design risk).
2. Workstream A input layer (makes the game *playable* on a desktop — also the
fastest path to a demoable build).
3. Networking audit (**C**), then transport abstraction + Steam sockets.
4. Workstream B session UI, using vPOD as the test double.
5. Steamworks bring-up (appid, overlay, lobbies), SteamPipe packaging.