Zeitabhängige Bewegungsberechnung

Übersicht

BlitzBasic

Allgemein

	Gombolo Betreff: Zeitabhängige Bewegungsberechnung	So, Nov 27, 2011 19:40 Antworten mit Zitat
Hallo, Problem: Die Aktivierung und Steuerung der Feind, in einem Spiel, erfolgt über die Zeit. Jeder Gegener hat eine bestimmte Zeit ab Spielstart in dem es aktiviert wird. Wenn es nun aus irgend einem Grund passiert, dass die Anwendung (das Spiel) für einen Durchlauf länger braucht, stimmt der Startzeitpunkt für die Gegner nicht mehr. Frage: Wie könnte eine Überwachung der Zeit erfolgen? Und wie könnte eine Korrektur der Zeit seit Spielstart erfolgen? cu
Heute ist der erste Tag vom Rest deines Lebens http://gombolo.go.funpic.de/

Gombolo

Betreff: Zeitabhängige Bewegungsberechnung

So, Nov 27, 2011 19:40
Antworten mit Zitat

Hallo,

Problem: Die Aktivierung und Steuerung der Feind, in einem Spiel, erfolgt über die Zeit. Jeder Gegener hat eine bestimmte Zeit ab Spielstart in dem es aktiviert wird. Wenn es nun aus irgend einem Grund passiert, dass die Anwendung (das Spiel) für einen Durchlauf länger braucht, stimmt der Startzeitpunkt für die Gegner nicht mehr.

Frage: Wie könnte eine Überwachung der Zeit erfolgen? Und wie könnte eine Korrektur der Zeit seit Spielstart erfolgen?

cu

Heute ist der erste Tag vom Rest deines Lebens
http://gombolo.go.funpic.de/

	ZEVS	So, Nov 27, 2011 19:44 Antworten mit Zitat
Kontrolle der Zeit? MilliSecs! Die Frage ist, ob du die Gegner nicht lieber nach der Anzahl der Frames aktivierst... ZEVS

ZEVS

So, Nov 27, 2011 19:44
Antworten mit Zitat

Kontrolle der Zeit? MilliSecs

!
Die Frage ist, ob du die Gegner nicht lieber nach der Anzahl der Frames aktivierst...

ZEVS

	BladeRunner Moderator	So, Nov 27, 2011 19:46 Antworten mit Zitat
Ich denke es ist eher gemeint wenn die Applikation den Fokus verloren hat - Millisecs rotiert fröhlich weiter, doch das Spiel war ja in der Zwischenzeit pausiert. Das führt zu lecker Problemen.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

So, Nov 27, 2011 19:46
Antworten mit Zitat

Ich denke es ist eher gemeint wenn die Applikation den Fokus verloren hat - Millisecs rotiert fröhlich weiter, doch das Spiel war ja in der Zwischenzeit pausiert. Das führt zu lecker Problemen.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	Gombolo	So, Nov 27, 2011 19:47 Antworten mit Zitat
Was ist wenn ich einen schwachen PC habe? oder einen stärkeren? Die Frames sind ja nicht Konstant. Die Bewegungen der Objekte im Spiel erfolgen unabhängig von der PC-Leistung. @BladeRunner. Korrekt!
Heute ist der erste Tag vom Rest deines Lebens http://gombolo.go.funpic.de/

Gombolo

So, Nov 27, 2011 19:47
Antworten mit Zitat

Was ist wenn ich einen schwachen PC habe? oder einen stärkeren?

Die Frames sind ja nicht Konstant. Die Bewegungen der Objekte im Spiel erfolgen unabhängig von der PC-Leistung.

@BladeRunner. Korrekt!

Heute ist der erste Tag vom Rest deines Lebens
http://gombolo.go.funpic.de/

	ZEVS	So, Nov 27, 2011 20:05 Antworten mit Zitat
OK, du willst es also nach realer Zeit machen (ist auch besser so). Die normale Kontrolle erfolgt normalerweise anhand der Differenzen zwischen den Frames. Wenn du mal nach FPS suchst, wirst du alles finden. Das Problem das BladeRunner geschildert hat, ist aber gravierend: Woher soll das Spiel erkennen, dass es sich um eine Fensterverschiebung handelt, und ergo halt nicht die Frames nachberechnet werden sollen? Es ist einfach die Differenz. Wenn diese so hoch ist, dass ein Nachberechnen der Frames zu nicht nachvollziehbaren Unterschieden führt, soll einfach "akzeptiert" werden, dass diese Frames ausfallen. Je nach Ansatz (wiederholtes Aufrufen der Animationen oder Erhöhung dieser durch einen Faktor), sieht das ganze wie folgt aus: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] ;wiederholtes Aufrufen (exakt gleich): Global frameTimer = CreateTimer(60);oder was auch immer Repeat ;... zeichnen, Flip 0, Cls... Local no = WaitTimer(frameTimer) If no > 6 Then no = 6 ;Mehr als 6 Frames übersprungen - lieber nicht zu viel For Local i=1 To no ;update Next Until/Forever ;Verwenden eines Faktors (schneller, kann aber z.B. mit KIs zu Differenzen führen) Global frameTimer = CreateTimer(60) Global lastFrame = MilliSecs() Global speedFactor# = 1.0 Const FRAME_TIME = 16 Repeat ;... zeichnen, Flip 0, Cls... WaitTimer frameTimer speedFactor = FRAME_TIME/Float(MilliSecs()-lastFrame) If speedFactor > 10 Then speedFactor = 10 ;Nicht mehr als 10-fache Geschwindigkeit lastFrame = MilliSecs() ;update Until/Forever Der Vorteil dieses Ansatzes ist, dass das Programm nun auch auf einem alten, schwachen PC mit 30 anderen Tasks läuft, ohne den Benutzer graphisch zu überfordern. Wenn man diesen Fall auslässt, kann man aber z.B. nach eine Fensterverschiebung automatisch in einen Pause-Modus wechseln oder noch weniger Frames überspringen. Das würde aber beim ersten Fall entweder zu ständigen ungewollten Pausen oder einem extrem langsamen Spiel führen. ZEVS

ZEVS

So, Nov 27, 2011 20:05
Antworten mit Zitat

OK, du willst es also nach realer Zeit machen (ist auch besser so).
Die normale Kontrolle erfolgt normalerweise anhand der Differenzen zwischen den Frames. Wenn du mal nach FPS suchst, wirst du alles finden.
Das Problem das BladeRunner geschildert hat, ist aber gravierend: Woher soll das Spiel erkennen, dass es sich um eine Fensterverschiebung handelt, und ergo halt nicht die Frames nachberechnet werden sollen?
Es ist einfach die Differenz. Wenn diese so hoch ist, dass ein Nachberechnen der Frames zu nicht nachvollziehbaren Unterschieden führt, soll einfach "akzeptiert" werden, dass diese Frames ausfallen. Je nach Ansatz (wiederholtes Aufrufen der Animationen oder Erhöhung dieser durch einen Faktor), sieht das ganze wie folgt aus:
BlitzBasic: [AUSKLAPPEN]

;wiederholtes Aufrufen (exakt gleich):
Global frameTimer = CreateTimer(60);oder was auch immer
Repeat
  ;... zeichnen, Flip 0, Cls...
  Local no = WaitTimer(frameTimer)
  If no > 6 Then no = 6     ;Mehr als 6 Frames übersprungen - lieber nicht zu viel
  For Local i=1 To no
    ;update
  Next
Until/Forever

;Verwenden eines Faktors (schneller, kann aber z.B. mit KIs zu Differenzen führen)
Global frameTimer = CreateTimer(60)
Global lastFrame = MilliSecs()
Global speedFactor# = 1.0
Const FRAME_TIME = 16

Repeat
   ;... zeichnen, Flip 0, Cls...
  WaitTimer frameTimer
  speedFactor = FRAME_TIME/Float(MilliSecs()-lastFrame)
  If speedFactor > 10 Then speedFactor = 10    ;Nicht mehr als 10-fache Geschwindigkeit
  lastFrame = MilliSecs()
  ;update
Until/Forever

Der Vorteil dieses Ansatzes ist, dass das Programm nun auch auf einem alten, schwachen PC mit 30 anderen Tasks läuft, ohne den Benutzer graphisch zu überfordern.
Wenn man diesen Fall auslässt, kann man aber z.B. nach eine Fensterverschiebung automatisch in einen Pause-Modus wechseln oder noch weniger Frames überspringen. Das würde aber beim ersten Fall entweder zu ständigen ungewollten Pausen oder einem extrem langsamen Spiel führen.

ZEVS

	Midimaster	Mo, Nov 28, 2011 10:49 Antworten mit Zitat
zu dem Thema "Zeitsteuerung" gibt es ein Tutorial von mir. Es könnte Dir helfen: https://www.blitzforum.de/foru...hp?t=34436
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

Midimaster

Mo, Nov 28, 2011 10:49
Antworten mit Zitat

zu dem Thema "Zeitsteuerung" gibt es ein Tutorial von mir. Es könnte Dir helfen:

https://www.blitzforum.de/foru...hp?t=34436

Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

	BladeRunner Moderator	Mo, Nov 28, 2011 12:09 Antworten mit Zitat
Nur dass ihm das nicht in seinem aktuellen Fall hilft, da es ihm ja darum geht dass die Anwendung den Fokus verloren hat, und soweit ich das überblicke Midimaster deckt dein Tutorial den Fall nicht mit ab.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mo, Nov 28, 2011 12:09
Antworten mit Zitat

Nur dass ihm das nicht in seinem aktuellen Fall hilft, da es ihm ja darum geht dass die Anwendung den Fokus verloren hat, und soweit ich das überblicke Midimaster deckt dein Tutorial den Fall nicht mit ab.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	Holzchopf Meisterpacker	Mo, Nov 28, 2011 21:40 Antworten mit Zitat
Es gab doch da diese BPS #6 Aufgabe, bei der es auch um's Nachrechnen von verlorenen Frames ging Der simple Trick hierbei ist, die Berechnungen (meist Bewegungen und Kollisionsabfragen) in einer For-Next-Schleife so oft aufzurufen, wie dies nötig ist. Nötig meint in diesem Fall: Um auf eine zeitkonstante Anzahl zu kommen - also eben 60 oder 50 mal pro Sekunde. Der entsprechende Timer "tickt" dann eben diese immer gleiche Anzahl Male in der Sekunde. Im Idealfall läuft die Hauptschleife des Programms selber mit dieser Geschwindigkeit. Sollte es aber dazu kommen, dass die Hauptschleife aus irgend einem Grund (ziehen des Fensters beispielsweise) nicht so oft ausgeführt werden kann, liefert einem WaitTimer glücklicherweise gerade die Anzahl übersprungener Ticks. Gombolo hat Folgendes geschrieben: Die Frames sind ja nicht Konstant. Dieses Problem löst sich eben unter Verwendung von CreateTimer und WaitTimer. Also eigentlich ist das, was ich hier schrieb, nichts Neues, sondern nur die Erklärung zu ZEVS Code =P mfG Holzchopf
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

Holzchopf

Meisterpacker

Mo, Nov 28, 2011 21:40
Antworten mit Zitat

Es gab doch da diese BPS #6 Aufgabe, bei der es auch um's Nachrechnen von verlorenen Frames ging Rolling Eyes

Der simple Trick hierbei ist, die Berechnungen (meist Bewegungen und Kollisionsabfragen) in einer For-Next-Schleife so oft aufzurufen, wie dies nötig ist. Nötig meint in diesem Fall: Um auf eine zeitkonstante Anzahl zu kommen - also eben 60 oder 50 mal pro Sekunde. Der entsprechende Timer "tickt" dann eben diese immer gleiche Anzahl Male in der Sekunde. Im Idealfall läuft die Hauptschleife des Programms selber mit dieser Geschwindigkeit. Sollte es aber dazu kommen, dass die Hauptschleife aus irgend einem Grund (ziehen des Fensters beispielsweise) nicht so oft ausgeführt werden kann, liefert einem WaitTimer

glücklicherweise gerade die Anzahl übersprungener Ticks.

Gombolo hat Folgendes geschrieben:

Die Frames sind ja nicht Konstant.

Dieses Problem löst sich eben unter Verwendung von CreateTimer

und WaitTimer

.

Also eigentlich ist das, was ich hier schrieb, nichts Neues, sondern nur die Erklärung zu ZEVS Code =P

mfG
Holzchopf

Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018)
Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

	Gombolo	Do, Dez 01, 2011 20:14 Antworten mit Zitat
Ich habe das jetzt so gelöst. Die Bewegung ist unabhängig von der Framerate. Ich habe einen Zähler eingebaut der die zurückgelegte Strecke berechnet. Läuft die Anwendung nicht (verliert den Focus) wird die Berechnung der Strecke nicht ausgeführt. Die Steuerung der Gegner erfolgt über die Berechnung der zurückgelegte Strecke. Auf jedenfall funktioniert es cu

Gombolo

Do, Dez 01, 2011 20:14
Antworten mit Zitat

Ich habe das jetzt so gelöst.

Die Bewegung ist unabhängig von der Framerate. Ich habe einen Zähler eingebaut der die zurückgelegte Strecke berechnet. Läuft die Anwendung nicht (verliert den Focus) wird die Berechnung der Strecke nicht ausgeführt.

Die Steuerung der Gegner erfolgt über die Berechnung der zurückgelegte Strecke. Auf jedenfall funktioniert es Smile

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Zeitabhängige Bewegungsberechnung

Betreff: Zeitabhängige Bewegungsberechnung