# Begrijp de klok in een game-lus
Elk gerenderd frame geeft de game nieuwe verstreken tijd. In een lus met variabele delta wordt beweging vaak bijgewerkt als position += velocity × frameTime. Bij stabiele frames blijft de gemiddelde snelheid dicht bij de bedoeling, maar één update kan zo groot worden als het frame dat haar veroorzaakte. Een hitch is daarom niet alleen een visuele pauze: hij verandert de hoeveelheid gametijd die die update verbruikt. # Vergelijk variabele integratie met een vaste accumulator
Een lus met vaste timestep telt elke frameduur op bij een accumulator en verbruikt daarna herhaaldelijk een gekozen stap zoals 16,667 ms. De simulatie ziet gelijke updates, terwijl de renderer een ander ritme kan houden. De resterende fractie blijft in de accumulator voor het volgende frame. Bij een lang frame voert de vaste lus meerdere kleine updates uit om de verstreken tijd te verwerken. De stapgrootte blijft stabiel, maar er kan een inhaalpiek ontstaan. | Stabiele rendering | Eén update gebruikt elke normale frameduur | Gelijke stappen verbruiken de verzamelde tijd | Beide paden zouden dezelfde beweging moeten volgen. |
| Lang frame | Eén grote update kan een object te ver verplaatsen | Meerdere vaste updates halen de tijd in | Lees drift samen met het aantal inhaalstappen. |
| Andere renderfrequentie | De updategrootte verandert met de framerate | De simulatiestap blijft gelijk | Vaste stappen verminderen renderafhankelijkheid. |
| Delta-plafond | Tijd boven de grens wordt genegeerd | De accumulator ontvangt de volledige frameduur | Begrens alleen wanneer tijd verliezen aanvaardbaar is. |
# Zie wat een framepiek werkelijk doet
Bij 60 frames per seconde duurt een normaal frame ongeveer 16,667 ms. Met een extra piek van 80 ms duurt één frame ongeveer 96,667 ms. Het variabele model verwerkt die hele duur in één update. Het vaste model verwerkt in plaats daarvan ongeveer zes stappen van 16,667 ms. De totale verstreken tijd kan gelijk zijn, terwijl het pad door de simulatie verschilt. # Lees positiedrift samen met inhalen
Positieverschil is het variabele pad min het vaste pad. Het toont hoe ver de twee integratiekeuzes uit elkaar zijn geraakt, niet automatisch welke keuze juist is. Het aantal inhaalstappen toont hoeveel vaste arbeid in één gerenderd frame nodig was. Een groot verschil wijst op zichtbare bewegingsafwijking; veel inhaalstappen wijzen op een mogelijk CPU-budgetprobleem. De signalen hangen samen, maar zijn niet dezelfde diagnose. # Behandel delta begrenzen als een beleid
Een begrenzing kan voorkomen dat een gepauzeerd tabblad, breakpoint of zware hitch een personage teleporteert of een physics-object door geometrie laat gaan. De prijs is dat de variabele klok achterloopt op de echte verstreken tijd. Als de game timing moet behouden, gebruik dan een vaste accumulator of ander herstelbeleid. Als sprongen begrensd en de game responsief moet blijven, kan een begrenzing passend zijn, maar het verlies aan tijd moet opzettelijk zijn. # Kies de lus voor de taak die ze beschermt
| Physics, botsingen of deterministische gameplay | Vaste timestep | Gelijke stappen maken de simulatie minder afhankelijk van het render-ritme. |
| Eenvoudige visuele beweging zonder opgebouwde toestand | Variabele delta | De update is klein en heeft meestal geen inhaalwachtrij nodig. |
| Gameplay-simulatie met vloeiende rendering | Vaste update met interpolatie | De simulatie houdt zijn stap terwijl de presentatie de fractie verbergt. |
| Herstel na een zware stilstand | Begrensd inhaalbeleid | Voorkom dat één slecht frame onbeperkt simulatiewerk veroorzaakt. |
# Gebruik een herhaalbare afstelmethode
Begin zonder pieken en bevestig dat beide paden samenvallen. Voeg één herhaalbare hitch toe en verander daarna het interval om te zien of de zichtbare fout optelt of stabiliseert. Pas de vaste stap aan en bekijk het aantal inhaalstappen voordat je de snelheid verandert. Schakel ten slotte de begrenzing in en vergelijk variabele simulatietijd met echte tijd. Zo scheid je de oorzaak van drift van het beleid dat haar moet beperken.
Wat dit experiment niet kan bewijzen
Het laboratorium gebruikt opgegeven frameduren en constante snelheid. Het verklaart timinggedrag, maar meet geen apparaat en valideert geen engine. Echte physics, inputmeting, netwerk, interpolatie en framebudget kunnen de beste keuze veranderen. Gebruik het resultaat als hypothese en controleer die daarna in de echte game.