3 Commits
Author SHA1 Message Date
DreadHeadHippyandCopilot 5728a91e7f Replay export: the export dialog's 8, 12 and 18 Mbps choices apply again
Every export was forced to 100 Mbps, about 750 MB per minute of replay, whichever quality
was chosen. The bitrate patch is removed; the frame pacing fix stays.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-10-20 09:56:30 -04:00
AyeZeeBB 6df4f9a7bd Replay export: videos are encoded at 100 Mbps whichever quality is chosen
he export dialog's quality setting picks 8, 12 or 18 Mbps for the H.264
encoder (three mov eax immediates at Skate.exe+0x62c24f, +0x62c256 and
+0x62c25d in the 20260929 build). All three are now 100000 kbps.
- The code around them must match the supported build's bytes, and each
  value must be the game's own or already 100000; otherwise nothing is
  written and the log says the change was skipped.
- The log says whether the bitrate change or the frame-pacing hook was
  skipped. start() reports success if either one is in place, so
  replay_export_initialized can say active while the hook is off.
- The fix that encodes every rendered frame is unchanged.
2026-10-14 20:11:01 -05:00
AyeZeeBB d84b32fc17 Encode every rendered frame of a replay export
Videos exported from the replay editor played two to three times too
fast unless the frame rate was capped, or the export was slow enough to
hold it down by itself (4K, WebM). The fault is in the game's own export
path.
Replay export (Extension/Rendering/replay_export.*)
- While exporting, the game steps the replay by one frame of video
  (speed / fps) for every frame it renders. The engine's movie encoder
  takes a frame only while a permit byte is set; a world update sets it
  once, and a frame submitted without it is dropped. Rendering two or
  three frames per update, most of a clip never reached the file, and an
  MP4 is exactly as long as its frame count. One clip came out as 181
  frames at 30 fps and 297 at 60, 6.0 s and 5.0 s.
- The encoder's frame submit is detoured and the permit set before the
  original runs, for the replay editor's encoder only (matched by its
  vtable). The frame is encoded on the render thread before the call
  returns, so the renderer is held to the pace the encoder keeps and no
  frame is lost. The replay still runs fast on screen during an export:
  that is the encoder's speed, not the file's.
- The same clip afterwards, frame rate uncapped, MP4 1080p: 505 frames
  at 30 fps and 1008 at 60, 16.8 s both, audio as long as the video.
  WebM and 4K take the same path and were not run again.
- Addresses are in Engine/Game/Build/20260929/replay_export.h. The hook
  starts with the others in runtime_init.cpp.
2026-10-03 20:57:07 -05:00