Serv,

ich versuch grad nen Tilebased Platformer zu schreiben, habe aber probleme mit der Physik.
So wie ich es jetzt grad mache, kann man jederzeit wenn man von einer platform runterfällt wieder zurück, was aber nicht möglich sein sollte.

Kann mir einer sagen was ich falsch mache?

Omg es war so simpel:

Falsch:
for (int i = tileleft; i <= tileright; i++)

Richtig:
for (int i = tileleft; i <= tileright; ++i)

So hab nun das ganze nochmal mit OpenGL und Glut und C++ geproggt und es funktioniert zwar,
aber die "Frametime" spinnt völlig und ich weiß nicht wieso.

Normalerweise liegen meine frametimes weit über 0 ms, hier in meinem Platformer Spiel aber bleiben sie fast immer bei 0
mit heftigen einbrüchen. Lass ich die Frametime weg beim bewegen ist alles sehr smooth, das ist aber falsch.

Bitte schaut euch mal den Rendercode an. ich seh keinen Fehler Die FPS werden richtig berechnet!



bewegt wird relativ einfach:

x += velx * frametime;

Danke für die Hilfe,
Final

PS: Bei bedarf lad ich den VC++ 2010 source mal hoch.

Das erste Problem, was ich sehe ist die umwandlung von UInt64 in Float64, dann in Float32 und rechnest dann fleißig mit Float32. Dabei geht soviel genauigkeit flöten, dass spielt sich schon im ms Bereich ab. Von Daher bleib bei UInt64 und wandel nur für delta time in Float64.

Das zweite Problem ist, dass der Code sehr Anfällig gegen die Verfügbare Zeit auf der CPU ist und schon kleinste Änderungen der Prozessorzeit oder abweichen von regelmässigen Ausführen, zu Rucklern, kaputte Physik und Animationen führt.
Es ist besser mit Konstanter delta time zu arbeiten und die Updateloop entsprechend x mal auf zu rufen, bis die Zeit vom letzten Timestamp bis zu aktuellen nachgeholt wurde. So hast du auch nicht das ungenauigkeitsproblem von 1., da ja delta time ein Konstante ist, die nicht berechnet wird und der TimeStamp, vom Performancecounter mit UInt64 nur noch eine subtraktion braucht, statt mehrere floatingpoint multiplikationen und divisionen.

Das letzte und wohl dein eigentliches Problem ist, dass du diesen Thread auf ein Prozessorkern fest nageln musst, da und CPU Core abhängig sind und dein thread per default auf den hin und her springt und damit total falsche Werte raus kommen. Damit das korrekt ist, musst du mit ihn auf ein bestimmten Kern fest nageln. Mask kannst du auf 1 stellen, dann wird immer der erste Logische Prozessor verwendet, den gibt es immer ^^.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also ich habe nun einiges umgestellt, aber es hat sich nichts geändert.
Gleiches problem wie vorher noch, kann es sein das GLUT für genaues Timing nix taugt?

Hier die sachen die ich geändert habe, zu erst den Perf Counter:



Was echt komisch ist, das ich schon viele QPC Anwendungen gebaut habe, aber noch keine mit GLUT und alle hatten kein Problem mit "float" als DeltaTime/Frametime, aber GLUT schon.

Meine Fluid Simulation nutzt übrigens auch das gleiche verfahren und hat auch entsprechende Timing problem,
die aber nicht so auffallen wie hier in meinem Platformer.

Was macht eigentlich das reinterpret_cast ?

Ich hab den source hochgeladen mit kompilierter debug version.
http://xenorate.com/tl_files/somekram/Platformer_Cpp_Glut.zip

Nicht wundern, das ding ist alles andere als fertig.

Du hast frametime als ms statt sekunden übergeben, daher ist es 1000 mal größer als es sein sollte.
Dann kommt noch ein unverständliches verhalten/bug hinzu, da zu zwischen renderstart und swap buffer misst und glutSwapBuffers nicht wie es eigentlich sollte noch die restliche Zeit, bis zum VSync, wartet, sind die Messwerte sehr klein, ungenau und falsch.
Du solltest lieber folgenden Code benutzten.

Das hat es wesentlich stabiler gemacht aber ist natürlich immer noch den Problemen von nicht konstanten delta times unterlegen.
In Spielen sind folgendes GameLoops wesentlich besser.

Sleep mit 0 sorgt dafür, dass dieser Prozess pausiert wird, das System nun andere Prozesse, in der Queue, verarbeiten kann und wenn das passiert ist wieder zurück springt.
Passend zum Sleep muss ich noch sagen, wenn du SetThreadAffinityMask benutzt, dann mach danach noch ein Sleep, erst dann kannst du sicher sein, dass die Funktion greift. Denn Sleep ist eine der wenigen Funktionen,in der OS API, die dem Sheduler erlauben den Prozess an zu halten.

Stabiler gehts nicht mehr und wenn man physik macht, dann kann man mit der Lösung auch extrapolation weg werfen und kann bullet time, vowärts, rückwärtsspulen easy realisieren(syncTime*2 wäre doppelt so scnell, -syncTime wäre rückwärts spulen).
Der Grund dafür ist, diese Loop ist Deterministisch.

Hier mal eine komplexe aber auch exakte Variante, mit verschiedenen Geschwindigkeiten.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Habe das ganze nun im XNA Framework 4.0 nachgebaut und ich komm weit besser vorran als ich erwartet habe,
vor allem muss ich mich nicht mit low level kram rumschlagen. Geht alles leicht von der Hand.
Eventuell werd ich es nochmal mit OpenTK probieren, aber erstmal bin ich mit meinem ergebnis ganz zu zufrieden.

Ich hab nochmal ein paar Tests gemacht mit GLUT und habe es nicht hinbekommen, eine brauchbare Gameloop zu bauen die
sauber ein Delta/Frametime erzeugt. Immer sind heftigste Schwankungen drin.
Vermute hier stark das die mainloop von GLUT irgendwie dafür unbrauchbar ist.

Whatever, wie ich geschrieben habe, habe ich das ganze eh in XNA gebaut und dieses Framework ist wirklich nicht schlecht.

Das gibts übrigens auch für mono in verbindung mit OpenGL: http://code.google.com/p/monoxna/
Allerdings nachdem ich mir den Source davon angeschaut habe musste ich leider feststellen, dass das Projekt alles andere als abgeschlossen ist. Es sind noch sehr viele NotImplementedExceptions in den Implementierungen

Allerdings könnte man das Grundgerüst von dem Framework recht schnell nachbauen mit OpenTK.

Was recht interessant an dem Framework ist, das laden von Content Assets.
Das läuft folgendermassen ab: Es gibt eine art Content-Projekt indem man alle Assets ablegt. Beim Kompilieren der Anwendung werden alle Assets über einen Content-Loader geladen und dann über Content-Writer als Binärdatei in den Output Ordner geschrieben und dann in der Anwendung mit dem Content-Reader gelesen.
Das bedeutet das man immer gezwungen ist, als End-Format ein Binärformat hat, indem die Assets abgelegt sind.

Nur so aus Neugierde.. damit hast du einen Fehler behoben?
Der einzige unterschied den ich sehe ist das i++ und ++i, das dürfte aber maximal eine Auswirkung auf die Performance der Schleife haben, nicht auf den Code der in der Schleife abgearbeitet wird - oder übersehe ich etwas?

Aya

Moment, jetzt wo dus erwähnst klingt das schon merkwürdig.
Womöglich ist da noch ne andere Stelle die ich geändert habe, damit es lief.
Aber ich schaus mir nochmal an und änders auf i++ wieder ab und geb bescheid ^^

Ja hast recht gehabt, irgendwas muss ich noch geändert haben damit es lief.
Habs auf i++ umgestellt keine änderung.