mirror of
https://github.com/Dingo-Shenanigans/ReSkate.git
synced 2026-10-17 20:57:08 +02:00
AyeZeeBB
b763631b77
Mesh streaming pool (fixes loading crashes on older GPUs) - 1.0.0 forced MeshStreaming.PoolSize to 3.5 GiB on every card. An RX 580 crashed while loading with DXGI_ERROR_DEVICE_RESET, and the oversized pool is the likely cause. The pool is now a quarter of the largest hardware adapter's dedicated video memory, capped at 3.5 GiB; cards of 6 GB or less keep the game's own 520 MB. The card, its memory and the chosen size are logged once at startup. Remote players (busy servers) - Transform interpolate is inline plain arithmetic: 22 -> 5.8 ns per joint. It was 4% of a busy server's client frame, since every player within 200 m has the whole skeleton interpolated every frame. - Players out of the camera's view and more than 8 m away are sampled at 20 Hz, like far players. Their position still updates every frame for collision, sound and nametags, and a player coming into view is sampled that frame. Expression hooks (run for every expression the game executes) - No profiler zones in the expression hooks: taking a sample switched them on, inflating the very samples that measured the hooks. - The throwdown lab pump does one sorted lookup of the running graph and skips everything else for graphs it doesn't watch (graph_throttle gets throttled_graph for this). Settings and memory reads - Script gameplay-setting and native-setting gets are served from small per-thread caches, keyed on the asset/key address, its first 8 name bytes and a new profile::Store::changes() counter, instead of a store lookup each call. - Per-frame reads in the client tick, native settings and population controls use memory::peek instead of ReadProcessMemory. - Script error logging probes each argument pointer once.
27 lines
1.6 KiB
C++
27 lines
1.6 KiB
C++
#pragma once
|
|
#include <cstdint>
|
|
|
|
// Authored graphs that re-post themselves every frame and get nothing done. Every graph run
|
|
// costs the game thread, so these are quietened, each through the one call that re-posts it:
|
|
//
|
|
// - three debug-only loops re-post first and then find their debug switch off (a retail
|
|
// setting stub, or an instance flag that is always clear): the re-post becomes a no-op, so
|
|
// they run once and stop. MPActivityCoordinator.OnDebugDrawUpdate (0xe300874d),
|
|
// InputVisualization_Dev.OnUpdate (0xe399e493, two instances) and
|
|
// ActivityLeaderboardManager.OnDebugPrintLoop (0xf5a89f23);
|
|
// - four loops wait for something offline play never gives them and ask again every frame:
|
|
// NarrativeSet's failed Play Event retry (0xa4becd75, which also formats a log line each
|
|
// time), QuickDropPersistenceManager.OnWaitForEntitlements (0xf64d93b7),
|
|
// MilestoneManager.OnInitLoop (0x7fab7dbd) and QuestManager.OnDelayedInit (0xa24d0261).
|
|
// Their waiting re-post now asks again after 1 s (60 frames), so they still finish if
|
|
// what they wait for ever arrives.
|
|
//
|
|
// Only the waiting branch's call is changed; the graphs' other calls stay native.
|
|
namespace dingosdk::multiplayer {
|
|
// Call after every graph run, any realm (the expression pump). Other graphs return after one
|
|
// hash compare, lock free; each loaded copy of the seven above is checked and patched once.
|
|
void throttle_graph_ran(std::uintptr_t base, std::uintptr_t vm) noexcept;
|
|
// Whether the graph with this hash is one of the throttled ones (the pump skips the rest).
|
|
bool throttled_graph(std::uint32_t hash) noexcept;
|
|
} // namespace dingosdk::multiplayer
|