4 Commits

Include renames

Author	SHA1	Message	Date
dhkatzandClaude Opus 5.5	4670a6a191	Pan between ticks, and move animations at their own rate ... The point the camera looks at is its position plus an offset (setCameraFocus, at each tick), so between ticks it now moves with the eased position: panning moves the target the position eases to, and was still at 30 per second. Between ticks, an animation is moved on at the rate it moved at the last step (per tick: the client steps several ticks at once when it falls behind), not only when it moved exactly a frame: animations played at other speeds were posed at the tick, between smooth ones. The engine's stats also log the longest time between frames. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-28 21:56:09 -07:00
dhkatzandClaude Opus 5.5	d1437a3923	Move the camera between ticks ... CameraController::step eases the camera's position, orbit angles and zoom a share k (0.4) of the way to their targets at each tick; between ticks, the adapter's getCameraTransform (its entry in CameraController's exported vtable, replaced after checking it) sets them 1 - (1 - k)^fraction of the way for IMVU's code to make the transform from, then puts them back. k is read from the constant CameraController::step uses, checked to be referenced there. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-28 21:44:56 -07:00
dhkatzandClaude Opus 5.5	2471b1fd4f	Pose avatars between ticks ... ModelInstance::render poses its model (updateCalSkeleton) before drawing it; the adapter redirects that one call (after checking it) to ours, which between ticks moves each playing animation that went on a frame at the last tick ahead by the fraction of a frame since, has IMVU's code pose the skeleton (Cal3D poses between keyframes), and puts the animations back, marking the skeleton to be posed again. Held, looping and starting animations are posed as they are. The frame lengths come from zero.dll's millisecondsPerFrame and secondsPerFrame. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-28 21:38:07 -07:00
dhkatzandClaude Opus 5.5	065c7e9300	Never make the client wait for drawing, or hold up its steps ... The renderer process now takes each view's chunks on a thread of its own as they come, and draws the newest frame on its main thread: the client no longer waits for the previous frame to be drawn (on a VM, 22 of a frame's 25 ms). The adapter records the client's steps (SceneViewer::step, by replacing its entry in the exported IFrameListener vtable, after checking it), and the frame pacer doesn't ask for a frame that wouldn't end before the next step is due: a late step made the client catch up two at once, which showed as hitches. While the renderer process covers the view, the client's renderer doesn't begin or present frames, which could wait for the display. The engine's stats now include the time in the client renderer's methods. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-28 21:30:46 -07:00