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:
1 parent
42fc55cb91
commit
a04dba18c1
12 files changed
+293
-90
No files matched your search
+16
-8
@@ -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
|
||||
|
||||
|
||||
Reference in new issue
Block a user