Pac-Man Hilfe

[himitsu]

Beim Programmablauf ist es seltener ein Problem, aber beim Debuggen wird es spassig, außer man debuggt schneller, als die Timer zuschlagen.

Der Debugger müsste die Timer anhalten und um die Pausenzeiten verlängern.

[mkinzler]

Zitat von himitsu:

Beim Programmablauf ist es seltener ein Problem, aber beim Debuggen wird es spassig, außer man debuggt schneller, als die Timer zuschlagen.

Das können aber nur die Schweizer

[Mavarik]

Also das Game ist ausgelegt auf 60 Frames per Sekunden...
Darüber wird alles gesteuert...

Habe ich habe im Web einen netten Ansatz gefunden...

Falls die 60 Frames nicht erreicht werden, nimmt der eine Wait Array

Beispiel:

1,1,1,1,1,1,1,1,1,1 100%
1,0,1,0,1,0,1,0,1,0 50%
1,1,0,1,1,0,1,1,0,1 usw...

Bei einer 1 bewegt sich Pac Man oder eben die Geister bei einer 0 nicht...
So kann ich im Low Bereich auch die unterschiedlichen Geschwindigkeiten machen...

Dann geht das mit einem Timer...

[himitsu]

Und was ist bei 73,4%?

Man nimmt die Zeit bis vorm letzten Zeichnen und weiß, wie weit man sich jetzt bewegen muß.

[Mavarik]

Zitat von himitsu:

Und was ist bei 73,4%?

Man nimmt die Zeit bis vorm letzten Zeichnen und weiß, wie weit man sich jetzt bewegen muß.

Pac-Man ist aber Pixelorientiert und nicht darauf ausgelegt Pixel zu überspringen!

[himitsu]

Das kann man ja ändern.

* Intern mit Teilpixelrechnen
* auf ganze Pixel gerundet anzeigen
* oder intern mit ganzen Pixeln rechnen, aber über längere Zeit die Geschwindigkeit berechnen/verrechnen
* ...
* Zwischenschritte interpolieren

[Sir Rufo]

Zitat von Mavarik:

Zitat von himitsu:

Und was ist bei 73,4%?

Man nimmt die Zeit bis vorm letzten Zeichnen und weiß, wie weit man sich jetzt bewegen muß.

Pac-Man ist aber Pixelorientiert und nicht darauf ausgelegt Pixel zu überspringen!

Es gibt ein Zell-Raster und ein Schritt-Raster. Das Schritt-Raster hat zur damaligen Zeit (Auflösung) direkt auf das Pixel-Raster gepasst. Das geht heute nicht mehr, sonst braucht man eine Lupe.

Zitat von himitsu:

Beim Programmablauf ist es seltener ein Problem, aber beim Debuggen wird es spassig, außer man debuggt schneller, als die Timer zuschlagen.

Der Debugger müsste die Timer anhalten und um die Pausenzeiten verlängern.

Das kann man auch anders unterdrücken, indem man zwar die Zeiten berücksichtigt, aber egal wie lange der Zeit zwischen den Berechnungen gedauert hat, es werden maximal nur 2 Schritte berechnet.

[himitsu]

Diese Aussage bezog sich nur auf mehrere Timer. (noch ohne die Betrachtung einer Interpolation)

* Timer1 = 100 ms
* Timer2 = 500 ms

Timer1 müsste also 5 Mal so oft auslösen, wie Timer2,
aber wenn man jetzt mehr als 100 ms benötigt, zum Debuggen einer Methode (bis zum nächsten ProcessMessage), dann verschiebt sich das natürlich.

Oder besonders schön wird es, wenn man ProcessMessages im Code drin hat.
* Timer-Event benöigt 10 ms, das Timer-Intervall ist 100 ms
Das geht normaler Weise, wenn man jetzt debuggt und mehr als 100 ms bis zum ProcessMessages braucht, dann debuggt man sich in eine Endlosschleife, weil in dem ProcessMessages der Timer erneut ausgelöst wird, bevor das aktuelle Event fertig geworden ist.