Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Fixed Step Logik + variable Zeit = limitierte Variable Step Logik

Werbeanzeige

CentuCore

Frischling

  • »CentuCore« ist der Autor dieses Themas

Beiträge: 43

Wohnort: Wien

  • Private Nachricht senden

1

12.10.2016, 12:24

Fixed Step Logik + variable Zeit = limitierte Variable Step Logik

Bevor ich den Thread von Big_Santa noch vollspamme mach ich dazu lieber einen eigenen Thread auf.

Kurze Einleitung:
Meine Ursprungsfrage warum überhaupt Fixed Step Logic und was der Nachteil wäre wenn man sie durch soeine ersetzt:

C-/C++-Quelltext

 
1
2
3
4
5
6

if( ZeitSeitLetztemUpdate >= KonstanteZeit )
{
     Update(ZeitSeitLetztemUpdate);
     ZeitSeitLetztemUpdate = .0f;
}
else ZeitSeitLetztemUpdate += DeltaZeit;

Link zum Post

Kurz google'n hat mich zu dem Blog gebracht (thx an BlueCobold für den Hint)
Eine Aussage war: mit Fixed Step läuft die Physiksimulation konstant ab, was bei meiner "Lösung" nicht der Fall wäre, wenn zB wg Debug-Purpose mal kurz (2-5s) der Prozess pausiert oder wg was-weiß-ich ein größerer Lag entsteht.
Dadurch wiederum ist die Physik deutlich stabiler, weil riesige Sprünge absehbarer sind und entsprechend eingegangen werden kann.
Hab ich das richtig kapiert, dass Fixed Step für die Stabiltät der Simulation entsprechend wichtig ist?


So meine neue Idee ist jz die:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13

//"Pseudo" Code
const float step ...; //konstante Update Zeit
const float max_advance ...; //zweite Konstante, max. Anzahl an Frames* die weiter berechnet werden dürfen
float total_time ...; //Zeit-Konto

//Im Main-Loop
if( total_time >= step )
{
     float diff = total_time - step;
     float advance = step + min(diff, max_advance);
     total_time -= advance;
     Update(advance);
}

Dadurch sollte die Physik immer noch stabil laufen, weil keine riesige Sprünger möglich sind, aber trotzdem Ungenauigkeiten auf Dauer ausgeräumt werden.
Sozusagen eine limitierte Variable Step Logik.

Was ist eure Meinung dazu?


Offtopic: Ich seh ab und zu, dass manche von euch (sry, Namen vergessen) sehr aktuell über die Neuerungen C++ Bescheid wissen.
Gibt's vom Commitee sozusagen eine offizielle Seite mit den "Patch Notes" und wichtigen Terminen oder wie wird das nach außen kommuniziert?
Freu mich auch über Tipps wie ich mich generell up2date halten kann. Meistens passiert das durch Zufall 2-3 Monate nach dem die News war.



* Frames ist dafür die falsche Bezeichnung. Ich meine damit um wieviel Prozent der derzeitige Update in der Pause zw. dem eigtl fixed Update und dem Nächsten steht.
Substeps wäre der richtige Name.
max_advance gibt dann einen Threshold an bis wie weit in diesen Bereich reinge'steppt werden darf.
-------|----------------------------|----------------------------------------------|
fixed Update___________hier befindet sich der Code_______________Zeitpunkt des nächsten Updates


Edit1: Grad über die Zahl 2 Frames extra nachgedacht, bei einer Updaterate von 60Hz wären das 8,333..% mehr. Die Zahl scheint mir deutlich zu extrem angesetzt.
Ich denke, dass .25-.5 Frames max. mehr deutlich stabiler wären, aber dennoch Langzeitungenauigkeiten ausgleicht. Die Updaterate würde dann nur noch um max. ~1-2% verfälscht werden.

Edit2: Links korrigiert.

Edit3: Genauere Beschreibung zu 'max_advance' eingefügt.

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »CentuCore« (12.10.2016, 14:19)

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

2

12.10.2016, 12:46

Auch an dieser Stelle der Hinweis auf den Wiki-Artikel, der die Vor- und Nachteile fester bzw. dynamischer Zeitschritte diskutiert: https://www.spieleprogrammierer.de/wiki/…gige_Spiellogik
David Scherfgens Website | Konzentrationstest Polizei

CentuCore

Frischling

  • »CentuCore« ist der Autor dieses Themas

Beiträge: 43

Wohnort: Wien

  • Private Nachricht senden

3

12.10.2016, 14:12

Im Endeffekt muss man bei starkem Lag* mehrere Teilschritte machen oder teilt sie auf mehrere Durchgänge auf.
Das war mir schon klar und löst der Algo auch nicht.
Da wäre dann eine Fallunterscheidung mit 'diff' vonnöten.

Ich wollte Fixed Step erweitern um den Unterschied zw. Dargestelltem und "Wirklichem" zu verringern.
Momentan merke ich bei Dead By Daylight, was ein paar Millisekunden Lag für einen Unterschied machen.
Der Lag zwischen Update und dem nächsten ist dann nicht weg, sondern eben verkleinert.

Ich les heute seit langem wieder von Fixed Step und mich interessiert ob meine Gedankengänge richtig sind, weil ich noch nicht so in der Materie drinnen stecke und langsam reinwachsen will.


* wenn Δt sehr groß ist

Edit1: Korrekt wäre es einen Substep einzufügen, aber das will ich ja verhindern.
Edit2: Lag genauer spezifiziert.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »CentuCore« (12.10.2016, 14:39)

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

4

12.10.2016, 14:20

Wenn du von "Lag" redest, meinst du aber nicht wirklich Lag, oder? Lag ist ein Begriff aus dem Netzwerkumfeld.
David Scherfgens Website | Konzentrationstest Polizei

CentuCore

Frischling

  • »CentuCore« ist der Autor dieses Themas

Beiträge: 43

Wohnort: Wien

  • Private Nachricht senden

5

12.10.2016, 14:27

Mit Lag meine Mir geht's bei dem Algo um folgendes:
Im normalen Fixed Step wird konstant geupdated "vollkommen egal" wo der Code sich zu der Zeit befindet.

Grafisch:
-------|------------------|-----------------------------------------------|
jetziges Update_____hier befindet sich der Code*_______________Zeitpunkt des nächsten Updates

Edit: Oder ist diese Zeit in der Praxis so irrelevant, dass ich mir da keine Sorgen machen muss?

*mit dem Update("veraltete Daten")

Edit2: Sorry, für die vielen Edits. Ich hoffe ihr kommt nicht durcheinander.
"Im Endeffekt muss man bei starkem Lag..." da meinte ich wenn Δt ungemein groß ist. Ich fügs mal ein.

Edit3: Ich kannte Lag nur von Spielen/Spielern und da wurde der Begriff universell für Input-Lag, also die Zeit die das Programm braucht um Inputs zu verarbeiten oder eben Netzwerklag.

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »CentuCore« (12.10.2016, 14:55)

Werbeanzeige

Ähnliche Themen