Konstante Framerate mit WaitTimer - Ja oder nein?
Übersicht

![]() |
x-pressiveBetreff: Konstante Framerate mit WaitTimer - Ja oder nein? |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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. ![]() |
||
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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) |
![]() |
TheShadowModerator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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-BITGast |
![]() Antworten mit Zitat |
|
---|---|---|
Hi,
ich habe in jedem meiner Programme WaitTimer. Und bei diesen hat es immer prächtig funktioniert ! Toni |
||
MasterK |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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. |
||
walskiEhemaliger Admin |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
ja.... XYZ/fps zu schreiben ist ja auch SOOOOOOOOOOOOO anstrengend ![]() 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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger. | ||
MasterK |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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
was du da machst, ist das zählen der frames, nix weiter 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. ![]() Till hat Folgendes geschrieben: sehr praktisch wird das ganze um zusehen wieviel
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.
cpu power einzelne game funktionen verschlingen. |
||
![]() |
Markus2 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger. | ||
OJay |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 ![]() 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* |
||
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group