Menü-Demo läuft mit variabler Zeitschrittweite und damit mit anderer Physik als das Spiel #10
Labels
No labels
accessibility
bug
cleanup
consistency
crash
critical
game-feel
gameplay
high
input
level-generation
low
maintainability
medium
pause
physics
responsive
security
spec-gap
ui
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gilli/pulse-sprint#10
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Komponente: GAME (
updateDemo,simStepDemo)Betroffene Version:
main@238ed66,index.htmlZeilen 2731–2754Beschreibung
Der laufende Hintergrund des Hauptmenüs ist ein echter Autopilot-Lauf – er verwendet aber die
Bildschirm-Framerate als Simulationsschritt, während das Spiel selbst mit
FIXED_TIMESTEP = 1/120in einer Akkumulatorschleife rechnet:Der Spielerpfad dagegen (
update, Zeile 2652–2657):Auswirkung
sich zwischen 60 Hz, 120 Hz und
reducedMotion(dt * 0.6).sehen ist, muss im Spiel anders aussehen – und umgekehrt deckt die Demo Regressionen im
Fixzeitschritt nicht auf.
MAX_FRAME_TIME= 33 ms, z. B. Backend-Tabs) wird die Demozusätzlich verzögert, aber nicht schrittstabil gerechnet.
Lösungsvorschlag
Wie im Spiel akkumulieren:
Dokumentiert in
gitlab-issues/10-menue-demo-variable-zeitschrittweite.md(Commit238ed66). Alle Befunde ausgeführt und gemessen; Repro-Schritte im Text.changed the description
changed the description