Zeitgesteuertes Programmieren

[Hellhound66]

o deswegen solltest Du eher überprüfen, ob die Strecke beider Sprites (jeweils PunktA und PunktB) sich schneidet, und nicht, ob die Sprites sich überlappen.

Eher einen Mindestabstand haben, der Abhängig von den Radien der Bounding Boxes ist. Ihr redet von 2D? Gut, dann geht auch schneiden. Durch diese Art des Collision castings kannst du auch vorberechnen, wann eine Kollision eintritt, wenn keine Paramter was mehr am Verlauf ändern. Sowas kann nützlich sein.

[dllfreak2001]

ich kann mir vorstellen das es so ziemlich fuselig wird.

[Hellhound66]

Klar, niemand sagt, dass es einfach ist ^^.
Aber so hast du halt fast alle zeitbedingten Fehler eliminiert.

[ZeHa]

Ich würde eher bei einfachen Spielen eine Maximalgrenze für den zeitausgleich angeben. So das ab einer bestimmten grenze das game doch langsamer läuft. Denn irgendwann wird das sowieso unspielbar.

Das ist vielleicht wahr für langsame Rechner. Aber auch auf schnellen Rechnern kann es mal einen "Ruckler" geben, weil auf einmal im Hintergrund der AntiVirus anfängt zu rödeln oder ein Download fertig ist oder was weiß ich. Und dann wird es fatal, sofern das Spiel z.B. über Netzwerk-Multiplayer verfügt für Singleplayer natürlich weniger dramatisch, da wäre sowas schon denkbar. Letztendlich aber unschön, wenn man auch weiß, wie es besser geht, und zudem erleichtert es einem später das Adden von Features, wenn man es von Anfang an richtig macht und nicht hier und da mal 'nen kleinen Hack einbaut.

[Hellhound66]

Selbst "Gems4" schlägt Obergrenzen vor. Ich halte das für eine gute Lösung.

[a14xerus]

Bei mir wird ab einer bestimmten Framerate ein großes Rotes Ausrufezeichen angezeigt (im mom noch testphase)
bei mir (1GH, windowed mode) ´tritt dieses Zeichen vll 2 mal pro minute aus verschieden gründen vll für 1-5 frames auf, also nicht dramatisch.
Für eine Untergrenze wäre ich auch
Soetwas wie mindestanforderungen

[dllfreak2001]

Also die meisten Spiele erzeugen ab einer bestimmten Grenze echte Slowdowns. Das ist eigentlich so Gang und gebe.
Und das voraus brechnen dürfte bei vielen sich gleichzeitig bewegenden
Objekten recht viel Rechenleistung beanspruchen, da in jedem Moment
das eine Objekt mit seiner Flugbahn mit dem anderen Kolidieren könnte...
Im Lan hat man dann beim Ruckler einen Lag. Hatte ich übrigens schon oft das ich an sehr seltsame stellen gekommen bin mit dem lag.

Außerdem wenn du ein Spiel mit Tilesets hast die alle mindestens 32x32
groß sind, dann machste einfach eine maximale grenze von 31pixeln die er springen darf. Da ist so ein Spiel sowieso schon unspielbar.

[a14xerus]

jo, soviele pixel sisd unzumutbar, ist aber sehr praktisch, wenn der pc nur einen kurzen hänger hat (also das "ausbremsen")
weil vll öffnet icq ja garde ein fenster oder antivir fängt an zu suche, dann hängt das spiel kurz, und wenn man dann direkt "wegspringt" wäre schlecht,
Aber mit den tips aus diesem thread funktioniert das bis jetzt ziemlich gut
(konnte es heute auch mal an den EXTREM lahmen schul pc's ausprobieren)

danke an alle

[Kaeru Gaman]

noch was zu dem "hänger haben".

gut fand ich persönlich die lösung, die in Black&White praktiziert wurde:

wenn durch ein Lag der rechner hing, wurden die Frames "nachgeholt".

also, wenn die spielfigur eine sekunde stockte, weil irgendein Lag auftrat,
hat sie danach sich für ne sekunde doppelt so schnell bewegt.

das kann man lösen, indem man wartezeiten in seine berechnungsschleife setzt,
also gleich beim konzept von z.b. 50 Berechnungs-Frames ausgeht,
und diese wartezeiten aufaddiert.

..is jetzt schwer zu erklären, ich häck mal fix ein kleines beispiel... brb..

[edit]
so, mal ein kleines beispiel:

Code: Alles auswählen

OpenWindow(0,0,0,160,60,"Timer-Demo 1")

TimeStep = 40
Timer = ElapsedMilliseconds() + TimeStep

Repeat
  Event = WindowEvent()
  If ElapsedMilliseconds() >= Timer
  
  ; *** und hier der Knackpunkt:
  ; dies ist der richtige Weg:
  Timer = Timer + TimeStep
  ; dies wäre der falsche Weg:
  ;Timer = ElapsedMilliseconds() + TimeStep

  CircX + 2 : If CircX > 160 : CircX = 0 : EndIf
  StartDrawing(WindowOutput(0))
    Box(0,0,160,60,$C06030)
    Circle(CircX,30,24,$20C0FF)
  StopDrawing()
  EndIf
  Delay(0)
Until Event = #PB_Event_CloseWindow

ich weiß, das ist grundsätzlich schlechter stil, und die CPU wird trotz Delay(0) gebraten,
aber es soll auch nur mal den unterschied in der timer-behandlung verdeutlichen.

so auf den ersten blick ist der effekt nicht so gut erkennbar,
aber wenn man beide versionen parallel laufen läßt, kann man es gut sehen.

[Hellhound66]

wenn durch ein Lag der rechner hing, wurden die Frames "nachgeholt".

Das ist das Ergebnis, von dem was ich zu Anfangs mal eingeworfen habe. Verschiedene Interpolationsmethoden, wobei diese eine (meiner Meinung nach) eher schlechte ist.