Konstante Framerate mit WaitTimer - Ja oder nein?

Übersicht BlitzBasic Allgemein

Gehe zu Seite 1, 2  Weiter

Neue Antwort erstellen

x-pressive

Betreff: Konstante Framerate mit WaitTimer - Ja oder nein?

BeitragSo, Jan 18, 2004 21:34
Antworten mit Zitat
Benutzer-Profile anzeigen
Gibt ja verschiedene Methoden, eine konstante Framerate zu erzielen, da ich aber auch meinen Code so sauber wie möglich halten möchte, würde ich (allein von der Einfachheit her) die mit CreateTimer/WaitTimer bevorzugen. Aber dazu mal ein paar Fragen:

1. WaitTimer sollte doch mal abgeschafft werden, wurde dann aber wieder übernommen, soviel ich weiss. Heisst das nun, daß diese Methode im Grunde genommen nicht zu empfehlen ist? Und wieso? Scheint doch extra für diesen Zweck da zu sein (laut Online-Hilfe SEHR zu empfehlen)

2. Werden Prozessorressourcen während dem Warten an andere Programme abgegeben?

3. Gibt es da irgendwelche Nachteile, die ich übersehen habe?
• BLITZ SHOWCASE:
PARTICLE CANDY • PARTICLE CANDY FOR iPHONE • SPRITE CANDY • DON'T GET ANGRY! 2-3 • CLICK CLACK XL
 

sven123

BeitragSo, Jan 18, 2004 21:36
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich glaube es kommt auf deinen code an,also ich verwende createtimer() und waittimer() und es funktioniert hervoragend.Naja mein Programm ist auch sehr bescheiden und klein. Laughing 8)
Amd Athlon 2200+,Saphire Atlantis Radeon9800pro,1024 MB DDR RAm,40 Gb Festblatte.
'in shâ'a llâh=so Gott will
Fertiges Projekt:Invasion der Heuschrecken
 

BIG BUG

BeitragSo, Jan 18, 2004 22:12
Antworten mit Zitat
Benutzer-Profile anzeigen
Waittimer hat halt den Nachteil, dass die Framerate z.B. gleich um die Hälfte sinkt, wenn ein Zyklus nur knapp nicht reicht. Außerdem sieht man nicht, wie schnell das Spiel wirklich läuft(nützlich um Systemanforderungen abzuschätzen).

Nach meine Erfahrungen bekommt man damit aber einen sehr sauberen Takt hin(MilliSecs kommt mir zumindest im Windowsmodus nicht ganz so genau vor).
Für einfache Games ist WaitTimer komplett ausreichend.(Zeitmessung im Spiel solltest du dann aber auch anhand deines Taktes errechnen und hier auf MilliSecs verzichten)

Bei aufwändig zu berechnenden Spielen sollte man aber gleich lieber eine Framerateunabhängige Bewegung einbauen.
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

TheShadow

Moderator

BeitragSo, Jan 18, 2004 22:29
Antworten mit Zitat
Benutzer-Profile anzeigen
WaitTimer hat nur einen Nachteil:

wenn du es ohne machst und du hast sehr sehr hohe Frameraten, dann wird FLIP durchgepowert - soll heißen dein prog synchronisiert sich mit der Monitor-refreshrate - und es gibt kaum dropped-frames

Wenn du jedoch eine WAITTIMER-Zeit einstellst, die unter Monitrorrefresh-Rate liegt, dann werden garantiert einige Frames gedroppt - das heißt Flip-Umschaltung wird machnmal 1, manchmal 2 Refreshzyklen dauern - das hat einen Nachteil bei schnellen Bewegungen - sehen dann ruckelig aus - dafür läuft es auf allen SYSTEMEN gleich schnell

Einige würden jetzt sagen - mach Bewegung mit Delta-Time-Kalkulation - hat auch einen Nachteil - wenn du z.B. ein Auto hast, das du mit rechts/links drehen kannst, dann musst du Delta-Time nicht nur bei bewegung, sondern auch bei Drehung des Autos mit Tasten beachten (je höher die Framezahl, desto kleiner der Drehwinkel) - sonst rotiert es bei 100fps 10x schneller als bei 10fps - bei manchen sachen ist es zudem schwerer - man denke nur an jump&run und sprung
AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2
 

HOT-BIT

Gast

BeitragSo, Jan 18, 2004 23:41
Antworten mit Zitat
Hi,

ich habe in jedem meiner Programme WaitTimer.

Und bei diesen hat es immer prächtig funktioniert !

Toni
 

MasterK

BeitragMo, Jan 19, 2004 0:10
Antworten mit Zitat
Benutzer-Profile anzeigen
framebremse is meistens ungut (wenn nicht sogar lamerhaft), zumindest bei grafik. bei KI über netzwerk zB muss man oftmals syncronisieren, aber darum gehts hier ja sicher nicht.

framebremsen haben nämlich ein absolut beschissenes problem:
schonmal ein spiel mit framebremse auf einem rechner gespielt, der nicht schnell genug ist? dann hast du bullet-time-modus als standard.

wo liegt das problem, die bewegungen in abhängigkeit von der framerate zu berechnen?
angenommen, du ermittelst ständig deine framerate, dann kannst du doch super damit arbeiten. am besten ist, man legt sich selbst eine framerate fest, welche man als ausgangbasis benutzt (um die geschwindigkeiten abschätzen zu können). am besten bieten sich da 100fps an.
die fps kannst du auf verschiedene arten ermitteln. entweder errechnest du die fps anhand der zeitänderung seit dem letzten frame, oder du zählst die frames, die innerhalb einer sekunde gerendert werden.

um nun zB deine spielfigur pro sekunde 100 pixel zu bewegen, reicht diese rechnung:
PosX = PosX + (100 / fps)

bei 100 fps würde pro sekunde um 1 pixel bewegt, also 100 pro sekunde. bei 200 fps würde pro sekunde um 0.5 pixel bewegt (achtung, erst beim rendern rundern, sonst wirkt sich der fehler auf spätere berechnungen aus), wieder 100 pro sekunde. bei 50 fps wärens 2 pixel pro frame. uswusf.
 

walski

Ehemaliger Admin

BeitragMo, Jan 19, 2004 1:37
Antworten mit Zitat
Benutzer-Profile anzeigen
Wo das Problem dabei liegt?

Das nicht alle Spiele so simpel sind, dass
PosX = PosX + 100/FPS
ausreicht!

Wenn du aber 3 Listen mit 3D Objekten hast die alle frei beweglich sind, zusätzlich noch die Kamera, den Player und 5 weitere Objekte, dann überlegt man sich verdammt nochmal, ob man umbedingt bei 60 mal diese dumme blabla/FPS Kacke schreibt.

walski
buh!
 

MasterK

BeitragMo, Jan 19, 2004 2:03
Antworten mit Zitat
Benutzer-Profile anzeigen
ja.... XYZ/fps zu schreiben ist ja auch SOOOOOOOOOOOOO anstrengend Rolling Eyes

wenn man ein spiel nur eingermaßen sinnvoll plant, ist sowas absolut kein problem. man sollte eben nur nicht wild drauflos hacken

edit: und wieso 60mal? es sollte doch EINE funktion für das zeichen der 3d-objekte reichen, oder?
 

furbolg

BeitragMo, Jan 19, 2004 5:18
Antworten mit Zitat
Benutzer-Profile anzeigen
ausserdem is MasterK's methode falsch ...

Man muss die Zeit die der Vergangene Frame gebraucht hat mit der Bewegung multiplizieren. (* fDelta) Bestes Beispiel Diablo2, aber diese Technik ist nicht Perfekt, sie kann bei zu starken Schwankungen zu Ruckel Effekten führen.
 

lettorTrepuS

BeitragMo, Jan 19, 2004 7:34
Antworten mit Zitat
Benutzer-Profile anzeigen
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger.
 

MasterK

BeitragMo, Jan 19, 2004 11:24
Antworten mit Zitat
Benutzer-Profile anzeigen
furbolg hat Folgendes geschrieben:
ausserdem is MasterK's methode falsch ...

Man muss die Zeit die der Vergangene Frame gebraucht hat mit der Bewegung multiplizieren. (* fDelta) Bestes Beispiel Diablo2, aber diese Technik ist nicht Perfekt, sie kann bei zu starken Schwankungen zu Ruckel Effekten führen.

du hast nur nicht richtig gelesen. ich rechne mit den FPS, du mit der zeitänderung seit dem letzten frame.

@shadowturtle: ja, eine grenze nach oben in kombination mit fps-unabhängiger berechnung kann durchaus sinnvoll sein. u.A. wegen dem von dir angesprochenen problem
 

BIG BUG

BeitragMo, Jan 19, 2004 11:40
Antworten mit Zitat
Benutzer-Profile anzeigen
Bei variabler Framerate ist auch die Kollisionsabfrage aufwändiger. Sonst kann es passieren, dass man auf langsamen Rechnern(wenig FPS->große Sprünge) durch Wände durch kann...
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)
 

Till

BeitragMo, Jan 19, 2004 12:08
Antworten mit Zitat
Benutzer-Profile anzeigen
ich lasse den "main-loop" immer so schnell
laufen wie es eben geht und code funktionen
die z.b. verteilt auf 1 sek. 30 mal durchgeführt
werden.

im main-loop lasse ich dann noch ne variable
hochzählen die jede sek wieder auf 0 gesetzt
wird somit kann ich recht gut sehen wie schnell
das game läuft im sinne von wieviele loop's
schaft der rechner pro sek.

sehr praktisch wird das ganze um zusehen wieviel
cpu power einzelne game funktionen verschlingen.

x-pressive

BeitragMo, Jan 19, 2004 13:27
Antworten mit Zitat
Benutzer-Profile anzeigen
Till hat Folgendes geschrieben:
sehr praktisch wird das ganze um zusehen wieviel
cpu power einzelne game funktionen verschlingen.


Klingt sinnvoll -hast du ein kleines Beispiel dafür parat?
• BLITZ SHOWCASE:
PARTICLE CANDY • PARTICLE CANDY FOR iPHONE • SPRITE CANDY • DON'T GET ANGRY! 2-3 • CLICK CLACK XL
 

MasterK

BeitragMo, Jan 19, 2004 13:50
Antworten mit Zitat
Benutzer-Profile anzeigen
BIG BUG hat Folgendes geschrieben:
Bei variabler Framerate ist auch die Kollisionsabfrage aufwändiger. Sonst kann es passieren, dass man auf langsamen Rechnern(wenig FPS->große Sprünge) durch Wände durch kann...

natürlich ist es etwas aufwändiger. aber willst du dir alles vorkauen lassen? dafür kann man mit variablen fps das spiel auch auf schwächeren rechnern sinnvoll spielen.

Till hat Folgendes geschrieben:
im main-loop lasse ich dann noch ne variable
hochzählen die jede sek wieder auf 0 gesetzt
wird somit kann ich recht gut sehen wie schnell
das game läuft im sinne von wieviele loop's
schaft der rechner pro sek.
was du da machst, ist das zählen der frames, nix weiter Wink

Till hat Folgendes geschrieben:
sehr praktisch wird das ganze um zusehen wieviel
cpu power einzelne game funktionen verschlingen.
eigentlich misst du da nicht die cpu-auslastung sondern lediglich wie schon gesagt die frames. wenn du durch unnötige bzw sinnlose berechnungen unnötig viel zeit verschenkst, verzerrt das die aussagekraft der fps recht deutlich. ausserdem verstehe ich nicht ganz, wie du die zeit, die einzelne funktionen benötigen, anhand der fps (die du in der main-loop bestimmst) erkennen willst.

Markus2

BeitragMo, Jan 19, 2004 13:53
Antworten mit Zitat
Benutzer-Profile anzeigen
Das hier finde ich gut ,
kann man auch kürzer schreiben .
Und noch time4 > 0 einbauen und dann erst delay -

Code: [AUSKLAPPEN]

;This code will delay main loop execution to provide accurate frame limiting
;"on the fly" based on how long the main loop takes to execute each cycle.

fRate = (1000/30) ;*set second number to desired frame rate*

While Not KeyHit(1)
   ;this code must go at the very start of the loop
   time1 = MilliSecs() ;time at start of processing loop
   
   ;***********************************
   ;all processing loop code goes here*
   ;***********************************
   
   ;this code must go at the very end of the loop
   time2 = MilliSecs() ;time at end of processing loop
   time3 = time2 - time1 ;number of miiliseconds to process loop
   time4 = fRate - time3 ;number of milliseconds to delay each processing loop to achieve dynamically accurate framerate
   Delay time4 ;delay execution
Wend

;Use any "frame per second" code to verify correct frame speed.
;Frame speed variance is usually within 1 fps. Not bad, eh? :)

 

OJay

BeitragMo, Jan 19, 2004 15:06
Antworten mit Zitat
Benutzer-Profile anzeigen
Markus2 hat Folgendes geschrieben:
Code: [AUSKLAPPEN]

;This code will delay main loop execution to provide accurate frame limiting
;"on the fly" based on how long the main loop takes to execute each cycle.

fRate = (1000/30) ;*set second number to desired frame rate*

While Not KeyHit(1)
   ;this code must go at the very start of the loop
   time1 = MilliSecs() ;time at start of processing loop
   
   ;***********************************
   ;all processing loop code goes here*
   ;***********************************
   
   ;this code must go at the very end of the loop
   time2 = MilliSecs() ;time at end of processing loop
   time3 = time2 - time1 ;number of miiliseconds to process loop
   time4 = fRate - time3 ;number of milliseconds to delay each processing loop to achieve dynamically accurate framerate
   Delay time4 ;delay execution
Wend

;Use any "frame per second" code to verify correct frame speed.
;Frame speed variance is usually within 1 fps. Not bad, eh? :)



genau diese methode verwende ich auch in meinen anwendungen. es gibt nämlich tatsächlich cpu-zeit frei, im gegensatz zu waittimer(), welches anscheinend eine schleife im hintergrund laufen lässt und und daher nachwievor 100% cpu-last verursacht.
für spiele würde ich das aber nicht empfehlen...

x-pressive

BeitragMo, Jan 19, 2004 15:40
Antworten mit Zitat
Benutzer-Profile anzeigen
Hä? Bei meinen Experimenten habe ich festgestellt, das es genau andersrum ist: Delay gibt keine CPU-Ressourcen frei. Wenn ich jedoch WaitTimer benutze, schon.
• BLITZ SHOWCASE:
PARTICLE CANDY • PARTICLE CANDY FOR iPHONE • SPRITE CANDY • DON'T GET ANGRY! 2-3 • CLICK CLACK XL
 

lettorTrepuS

BeitragMo, Jan 19, 2004 15:54
Antworten mit Zitat
Benutzer-Profile anzeigen
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger.
 

OJay

BeitragMo, Jan 19, 2004 16:08
Antworten mit Zitat
Benutzer-Profile anzeigen
OJay hat Folgendes geschrieben:
genau diese methode verwende ich auch in meinen anwendungen. ... für spiele würde ich das aber nicht empfehlen...


ich glaube, du verstehst nicht, was ich geschrieben habe Wink

selbstverständlich ist delay, oder waittimer oder jede andere art der frame begrenzung im multiplayer tödlich. aber im singleplayer ist es eine einfache möglichkeit das spiel auf einer konstanten geschwindigkeit zu halten.


ich hoffe du liest und verstehst, und liest nochmal langsam die posts anderer menschen! *daumendrück*

Gehe zu Seite 1, 2  Weiter

Neue Antwort erstellen


Übersicht BlitzBasic Allgemein

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group