Draw particles, match the client's fog, and measure frame delay

Particles (point sprites) are drawn as instanced camera-facing squares sized like Direct3D 9's. Fog is by depth buffer value, as Direct3D 9 does with IMVU's projections. At most one frame is queued for display, frames carry the adapter's timestamp so the renderer process logs the delay to presenting, and the log's lines from several processes no longer mix.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
dhkatzandClaude Opus 5.5 committed 2026-10-28 06:11:51 -07:00
1 parent 42fc55cb91
commit a04dba18c1
12 files changed
+293 -90

No files matched your search

+16 -8
View File
@@ -35,15 +35,23 @@ client exits.
## Status
A spike: the adapter still has IMVU's Direct3D 9 engine draw the scene (the pass-through), and the renderer process
only draws a box in the 3D view's corner, pulsing with the client's frames. Checked in the client (Direct3D 11 in
software, on a machine without a graphics driver): the box draws over the scene from the 64-bit process, keeps in
step with the client's frames, clicks on it reach the scene, and each renderer process exits with its engine (room
changes) and with the client. The client keeps two engines alive in a room, so two processes (about 15 MB each);
one process serving all of a client's engines would be leaner.
The renderer process draws the client's whole scene, over the right half of the 3D view, beside the client's own
Direct3D renderer on the left (the adapter still forwards everything to it): `T5DE_RENDERER_VIEW=full` or `off`
changes that. Checked in rooms: the halves match, particles included.
Next: the protocol carrying each frame's calls and the resources (buffers, textures), and the renderer process
drawing the scene itself, with IMVU's Direct3D engine left as the fallback.
- The command stream (`include/t5de/protocol/commands.hpp`) carries state, transforms, lights, fog, textures,
buffers (copied when created or updated) and draws, in chunks through the channel; the adapter waits for each to
be taken, and gives up on a renderer process that stops taking them (the client's renderer carries on).
- The renderer process reproduces IMVU's Direct3D 9 setup (`renderer/shaders/fixed_function.hlsl`), particles
included (point sprites, drawn as instanced squares), with a pipeline per combination of states.
- Speed: on the development VM (software rendering) a room frame takes 8 to 60 ms to draw; the time from the
client finishing a frame to ours being presented averages about 60 ms. The renderer process draws only the
newest frame when it falls behind, and keeps at most one frame queued. Over Remote Desktop, the half drawn by the
renderer process (another process's window, composited by Windows) visibly trails the client's half by more
than that; that delay comes after presenting, and is to be checked on a real graphics card and display.
Next: render targets (offscreen frames are skipped), the renderer process drawing the whole view in place of the
client's renderer, and one renderer process for all of a client's views.
## Building