Framerate begrenzen mit GetTickCount und Sleep nicht gut?
-
Original erstellt von KXII:
für mich sieht animierte grafik einfach besser aus, wenn sie mehr fps hat als die bildwiederholrate des monitor...vielleicht fällt dir das einfach nur nicht auf, oder du siehst keinen unterschied, weil du noch nie so genau hingeschaut hast. keine ahnung wieso das bei mir so ist, es ist aber so, und du kannst mir das auch ruhig glauben.Das erscheint mir einfach nicht logisch, kannst Du das irgendwie untermauern?
Original erstellt von KXII:
wieso schafft dein rechner nicht mehr fps als hertz? wenn du keine spezialhardware hast, dann sollte das bei dir auch gehen. was passiert denn, wenn du ein directx sdk demo startest, das normalerweise so 300-400 fps hat?Ich sitze hier an einem 650MHz Rechner mit einer alten GeForce256, ich bin mehr als zufrieden wenn ich Spiele mit 25FPS laufen lassen kann, obwohl ich Deiner Logik zufolge erst ab 90FPS zufrieden sein sollte. (Mein Monitor läuft mit 90Hz bei 1280x1024.)
Original erstellt von KXII:
zum thema mehr logikticks als fps. du hast recht. es macht im normalfall keinen sinn öfters die logik zu berechnen, als sie dargestellt wird.Doch, macht es (zumindest im weitesten Sinne).
Wenn diverse Egoshooter nicht seltener rendern würden als die Spiellogik überprüft wird dann gäbe es keine ruckelnden Spiele - es würde einfach alles im Zeitlupentakt ablaufen was - wenn man es sich genau überlegt - wohl noch ungünstiger wäre.
-
Original erstellt von KXII:
warum sollte, egal wo, logik durcheinander kommen? warum sollte es bei 24 fps anstatt 25 logikticks zu ungenauihkeiten kommen? für mich hört sich das schwachsinnig an (sorry). denn wenn ein rechner nicht mehr als 25 fps berechnen kann, dann wird halt alles einfach langsamer berechnet und das spiel fangt an in zeitlupe abzulaufen. aber die logik arbeitet nach wie vor genauso und wenn man es richtig programmiert, dann ergeben sich auch keine probleme bei der kollision oder so und es kommt auch nichts durcheinander!Lies Dir diesen Absatz noch einmal durch und Du wirst Deinen Denkfehler entdecken - rapso hat durchaus auch Ahnung von solchen grundlegenden Sachen, denk zumindest mal über seine Aussagen nach!
-
"Das erscheint mir einfach nicht logisch, kannst Du das irgendwie untermauern?"
ich schrieb, daß ich dafür keine genaue erklärung habe. es ist halt so. glaube es oder nicht, mir egal.
"Ich sitze hier an einem 650MHz Rechner mit einer alten GeForce256, ich bin mehr als zufrieden wenn ich Spiele mit 25FPS laufen lassen kann, obwohl ich Deiner Logik zufolge erst ab 90FPS zufrieden sein sollte. (Mein Monitor läuft mit 90Hz bei 1280x1024.)"
wenn das so ist, dann ist das schön für dich. kennst du den satz aus dem film matrix: "unwissenheit ist ein segen" ? ausserdem sagte ich nie das ich unzufrieden bin. ich sagte nur es sieht besser aus!
Doch, macht es (zumindest im weitesten Sinne).
genau meine rede, wenn das "zumindest im weitesten sinne" dazugenommen wird. im normalfall nicht. falls du das anders siehst, dann bitte eine genaue erklärung, da dies meine vorstellungskraft übersteigt.
Wenn diverse Egoshooter nicht seltener rendern würden als die Spiellogik überprüft wird, dann gäbe es keine ruckelnden Spiele ...
übersetzt heisst das:
Wenn diverse Egoshooter öfters oder genauso schnell rendern würden als die Spiellogik überprüft wird, dann gäbe es keine ruckelnden Spiele ...
genau meine rede.
... - es würde einfach alles im Zeitlupentakt ablaufen, was - wenn man es sich genau überlegt - wohl noch ungünstiger wäre
wieso denn das? wenn die grafik öftes gerendert wird als die logik neuberechnet wird, wieso sollte dann alles im zeitlupenmodus ablaufen?
Lies Dir diesen Absatz noch einmal durch und Du wirst Deinen Denkfehler entdecken - rapso hat durchaus auch Ahnung von solchen grundlegenden Sachen, denk zumindest mal über seine Aussagen nach!
ich habe mir den absatz nochmal durchgelesen, aber ich erkenne keinen denkfehler. meine programme laufen ohne logikfehler, egal wieviel frames sie haben. bei zuwenig frames wird alles langsamer, aber das ändert, wie gesagt, nichts an der berechenbarkeit von kollisionen. wenn du unbedingt ein programm schreiben willst, das auch bei wenigen frames pro sekunde die sprites immer gleichschnell über den bildschirm laufen (eher springen) lässt, und du dann irgendetwas programmierst das fehlerfaht berechnet wird, dann ist das dein problem. aber mit einer sinnvollen programmierung hat das nichts zu tun.
ich habe nie gesagt, das ich besonders viel ahnung von dem gebiet habe, oder das rapso wenig ahnung davon hat. ich kann mich auch irren, und wenn das so sein sollte, dann sag mir wie es richtig ist und ich akzeptiere es. ich höre hier oft nur anschuldigungen, aber keine GENAUEN lösungsvorschläge.
aber zurück zum thema. ich kann einfach nicht erkennen wo das problem ist etwas mit einem timer zu syncronisieren.
while(!Quit) { if (Timer.GetMilliseconds()>=TimeSpan) { Timer.Reset(); DoSomething; } }was ist daran falsch oder unlogisch und wieso sollte es probleme geben, wenn "DoSomething" mehr zeit benötigt als TimeSpan?
[ Dieser Beitrag wurde am 02.07.2003 um 03:02 Uhr von KXII editiert. ]
-
da fällt mir gerade noch was auf:
wieso beziehst du diesen satz auf dich selbst
"Original erstellt von KXII:
wieso schafft dein rechner nicht mehr fps als hertz? wenn du keine spezialhardware hast, dann sollte das bei dir auch gehen. was passiert denn, wenn du ein directx sdk demo startest, das normalerweise so 300-400 fps hat?"und gibst das als antwort:
"Ich sitze hier an einem 650MHz Rechner mit einer alten GeForce256, ich bin mehr als zufrieden wenn ich Spiele mit 25FPS laufen lassen kann, obwohl ich Deiner Logik zufolge erst ab 90FPS zufrieden sein sollte. (Mein Monitor läuft mit 90Hz bei 1280x1024.)"
der vorherige abschnitt war eindeutig auf "thetoast" bezogen, weil er sagte, daß er nie mehr fps hat als seine bildwiederholfrequenz. und weil ich mir das nicht vorstellen kann, wollte ich von ihm wissen wieso das so ist.
-
Original erstellt von KXII:
**
@rapsowarum sollte, egal wo, logik durcheinander kommen? warum sollte es bei 24 fps anstatt 25 logikticks zu ungenauihkeiten kommen? für mich hört sich das schwachsinnig an (sorry).
**das macht nichts, ich erklär's dir gerne, jeder hat das recht wat zu lernen
weil durch winzige ungenauigkeiten bei z.B. winkeln, die durch verschiedene divisoren auftretten (25 oder 24) bei der aufaddierung derer die winkel schon einges falsch sein können, wenn sich dann ein objekt 500einheiten weit bewegt, kann soeine kleine winkelungenauigkeit in einigen einheiten unterschied enden.
Original erstellt von KXII:
**
warum sollte man keine kollision erkennen? wie ich schon oben sagte, spielt das keine rolle. wenn doch dann ist es einfach schlecht programmiert, weil es nicht alle fälle abdeckt, die eintreten können.
**wenn du meinem beispiel mit der sich öfnenden tür folgen würdest, wüstest du dass die tür aufging und dabei ne gewisse rotation durchgeführt hat, wenn die framezahl total einbricht, dann kannst du das nicht mehr richtig berechnen, da du zwischen zwei positionen linear interpolierst, die punkte aber in wirklichkeit eine kreisbewegung hätten machen müssen, was zu einer kollision geführt hätte mit dem davor stehendem spieler.
Original erstellt von KXII:
**
wofür sollte man es auch vorhersehen oder abfangen? wenn eine hd in aktion tritt und daten von ihr geladen werden, dann wird das spiel halt etwas langsamer oder es bleibt sogar ganz stehen (je nach programmierung), bis die zugriffe fertig sind, das ändert aber nichts an der berechenbarkeit von kollisionen. sorry, ich sehe hier keine probleme.**
dafür abfangen, damit man nicht stumpf immer ... Bewegung*timedelta rechnet, sonst wird es beim kleinem aussetzer im system passieren, dass ein spieler extrem weit deplaziert wird
rapso->greets();
-
GOTT SEI DANK. ich glaube ich habe gelernt.
ich glaube (auch), daß deine probleme mit den ungenauigkeiten LEDIGLICH dadurch auftreten, weil du versuchst, auch bei wenigen frames pro sekunde, immer gleichgroße animationsschritte pro zeiteinheit zu realisieren.
ich finde aber, daß das nicht nötig ist. man sollte sich um diese "spezialfälle" keine gedanken machen, da sie sowieso normalerweise nicht eintreten und wenn, dann auch so realsiert werden können, daß das spiel einfach langsamer wird. dann hat man auch nicht die probleme, das man irgendetwas linear interpolieren muss... deine "winzige ungenauigkeiten bei z.B. winkeln, die durch verschiedene divisoren auftretten (25 oder 24)" fallen dann ganz weg und die problematik ensteht erst gar nicht und der code wird übersichtlicher. ich finde diese vorgehensweise besser.
DENN:
wenn jemand keinen schnellen rechner hat, dann hat er halt einfach pech gehabt, und muss alles in zeitlupe spielen! wenn man die neuesten spiele mit akzeptablen framerates zocken möchte, dann braucht man nunmal einen schnellen rechner.
[ Dieser Beitrag wurde am 02.07.2003 um 03:31 Uhr von KXII editiert. ]
-
genau hier wird es deutlich:
wenn du meinem beispiel mit der sich öfnenden tür folgen würdest, wüstest du dass die tür aufging und dabei ne gewisse rotation durchgeführt hat, wenn die framezahl total einbricht, dann kannst du das nicht mehr richtig berechnen, da du zwischen zwei positionen linear interpolierst, die punkte aber in wirklichkeit eine kreisbewegung hätten machen müssen, was zu einer kollision geführt hätte mit dem davor stehendem spieler.
wenn die framerate total einbricht, dann kann man es, nach meiner methode, IMMER NOCH genauso VOLLKOMMEN OHNE VERLUSTE berechnen, aber eben langsamer, weil keine "zeit-multiplikationen/divisionen" durchgeführt werden. es wird alles ganz normal berechnet, nur langsamer.
[ Dieser Beitrag wurde am 02.07.2003 um 03:37 Uhr von KXII editiert. ]
-
die ungenauigkeiten fallen nicht weg, sie tretten immer auf, bei einem festen logictick sind sie aber abschätzbarer. das ist auch der grund weshalb bei netzwerkspielen öfters nur fixpoint arithmetic verwendet wird, weil die ungenauigkeiten der floats stark ausfallen können.
extremfälle tretten öfters auf, z.B. bei leuten die die mindestanforderung für ein spiel haben, dann eine extreme scene, z.B. viele einheiten beim RTS, und die ruckeln da nur noch mit 2fps.
und als programmierer mußte dafür sorgen dass es richtig ausschaut und wenn du die framerate zur berechnung der zeit nutzt wird's nicht vernünftig laufen... und falls du deinem marketing ne höchere mindestsanforderung aufdrücken möchtest, werden die die hälfte der features streichen lassen, damit die käuferschicht gross genug bleibt... und selbst pech gehabt.
mit variablen zeitdeltas zu arbeiten ist ein graus und aus gutem grund macht das kaum noch jemand, und falls du mal ein system aus mehreren hundert interagierenden objekten hast und dein pc mal ruckt und das ganze system auseinander konvergiert, wirste deltas auch verabscheuen
aber für die kleinen flugsimulationen oder desgleichen, wo eh niemand genau wissen muss wo sich ein flugzeug befindet, da kann man vielleicht timedeltas verwenden... obwohl das da auch niemand macht.
rapso->greets();
-
Hast wahrscheinlich VSYNC an, dann schaffst Du auch net mehr FPS als Hz...
Also irgendwie schnall' ich dat immer noch net...
Sind da jetzt auf der einen Seite die Leute, die per HPC die vergangene Zeit im Frame berechnen und dann auf alle Bewegungen (Objekte, Partikelsysteme, ...) aufrechnen (was zwar im Spiel immer "gleich-schnelle" Bewegungen hervorruft, auf langsamen Rechnern aber ruckelt, bzw. "sprunghafte" Bewegungen auslöst) - und auf der anderen Seite die Leute, die die Logik immer fest intergriert im Mainloop verwenden, wobei dadurch auf langsameren Rechnern die Spielgeschwindigkeit "automatisch runterskaliert" wird (wie sieht's hier mit NW-Spielen aus??)?! Oder gibt es noch irgendwas dazwischen?!?
-
die spielgeschwindigkeit bleibt eigentlich immer gleich, egal welcher rechner, das ist das was logicticks ausmacht. du kannst fest davon ausgehen, dass sie alle z.B. 40ms aufgerufen werden und dass das delta 40ms ist!
um flüssige darstellung zu haben, hat man immer noch animatoren, die man im logictick einstellst.
wenn du z.B. 15ticks haben möchtest und ne framerate von 225fps hast, werden zwischen zwei logicticks 15 bilder dargestellt, damit das nicht immer das selbe ist, benutzt man einen animator, dem kannst du dann einstellen, dass sich etwas an einer position befindet und in 40ms wird es sich an der anderen position befinden, dazwischen interpoliert der animator während des renders, aber logic wird nirgenswo benutzt.
natürlich sollten animatoren nicht zu komplex werden, aber ein gutes beispiel wäre ein RTS, wenn du da 1000 einheiten hast, brauchst du sie nicht 25mal in der sekunde neu einzustellen, 5mal würde vielleicht reichen, aber damit die nicht einfach nur 5 bewegungen/s machen, kannst du dir einen animator schreiben, der mehreren linien folgt und somit die vorher berechnete route mit nem panzer abfährt, wenn der status alle 200ms geupdated wird, wird das scho ok aussehenrapso->greets();
-
Original erstellt von KXII:
ich schrieb, daß ich dafür keine genaue erklärung habe. es ist halt so. glaube es oder nicht, mir egal.Wie bereits gesagt wurde: Wie ist das denn dann bei Fernsehern? Die Dinger schaffen zwar oft 100Hz, aber glaubst Du wirklich dass jede Spielekonsole bei jedem gut aussehenden Spiel über 100fps schafft?
Original erstellt von KXII:
wenn das so ist, dann ist das schön für dich. kennst du den satz aus dem film matrix: "unwissenheit ist ein segen" ? ausserdem sagte ich nie das ich unzufrieden bin. ich sagte nur es sieht besser aus!Ich weiß zwar nicht was Du mir mit Zitat sagen willst aber "ignorance is bliss" ist schon um einiges älter als die Matrix.
Ich wage allerdings ernsthaft zu bezweifeln dass Du bei einem vernünftig programmierten Spiel einen Unterschied merken kannst.Original erstellt von KXII:
genau meine rede, wenn das "zumindest im weitesten sinne" dazugenommen wird. im normalfall nicht. falls du das anders siehst, dann bitte eine genaue erklärung, da dies meine vorstellungskraft übersteigt.Beispiel Ego-Shooter mit Multiplayer-Modus: Stell Dir mal Quaak3 würde nicht ruckeln sondern einfach immer "ein bisschen langsamer" laufen. Das wäre wirklich fatal, denn es hieße dass jeder Spieler genau die gleiche Hardware bräuchte um das Spiel halbwegs synchron genießen zu können.
Original erstellt von KXII:
Wenn diverse Egoshooter...
genau meine rede.Siehe oben.
Original erstellt von KXII:
wieso denn das? wenn die grafik öftes gerendert wird als die logik neuberechnet wird, wieso sollte dann alles im zeitlupenmodus ablaufen?Hm, kann es sein dass sich hier irgendwo ein Missverständnis zusammengebraut hat?
Allerdings: Wenn Die Grafik öfters gerendert wird als die Logik neuberechnet wird was sollte das dann Deiner Meinung nach bringen?ich habe mir den absatz nochmal durchgelesen, aber ich erkenne keinen denkfehler. meine programme laufen ohne logikfehler, egal wieviel frames sie haben. bei zuwenig frames wird alles langsamer, aber das ändert, wie gesagt, nichts an der berechenbarkeit von kollisionen.
Wenn bei zuwenig Frames alles langsamer wird dann hast Du gerade Deine eigene Frage im letzten Absatz beantwortet und solltest mittlerweile verstehen was das Problem daran ist.
wenn du unbedingt ein programm schreiben willst, das auch bei wenigen frames pro sekunde die sprites immer gleichschnell über den bildschirm laufen (eher springen) lässt, und du dann irgendetwas programmierst das fehlerfaht berechnet wird, dann ist das dein problem. aber mit einer sinnvollen programmierung hat das nichts zu tun.
siehe oben ("Fehlerhafte Berechnung" ist nicht das Problem, aber wenn mein Programm auf einmal nur mehr in Zeitlupe abläuft dann habe ich was falsch gemacht. Wenn es bei zu wenig FPS einfach nur ein bisschen ruckelt dann passt alles.)
[quote]aber zurück zum thema...[quote]
Irgendwie werde ich den Verdacht nicht los dass Du uns missverstehst - poste Doch mal (möglichst in einem neuen Thread; dieser wird zu unübersichtlich) ein bisschen von Deinem Timing-Code!
-
Original erstellt von KXII:
wieso beziehst du diesen satz auf dich selbst
...
der vorherige abschnitt war eindeutig auf "thetoast" bezogen, weil er sagte, daß er nie mehr fps hat als seine bildwiederholfrequenz. und weil ich mir das nicht vorstellen kann, wollte ich von ihm wissen wieso das so ist.Ich wollte untermauern dass thetoast recht hat und man bei aktuellen Spielen fast nie mehr FPS hat als Hz Bildwiederholrate.
-
Hi, also ich habe bis jetzt auch immer die von mir am anfang beschriebene methode angewandt, hatte aber auch einige Probleme. z.B. bei (realistisch)fallenden objekten, erst recht wenn diese auch noch springen (sollen). Die "andere Methode" klingt imho sehr überzeugend, da ja dieses Problem gelöst ist und weniger rechenzeit gebraucht wird. Was ist jedoch, wenn netzwerk spiel zB 25/s die logic aktualisieren soll, dies jedoch nicht schafft. Das würde dann doch heißen, dass das spiel langsamer liefe, was jedoch fatal wäre, oder?
MfG DasPinsch
-
schau mal hier:
http://www.bytesandmore.de/rad/da gibts ein Snippet mit Zeitmessung oder so, kannst es Dir leicht anpassen
-
"Beispiel Ego-Shooter mit Multiplayer-Modus: Stell Dir mal Quaak3 würde nicht ruckeln sondern einfach immer "ein bisschen langsamer" laufen. Das wäre wirklich fatal, denn es hieße dass jeder Spieler genau die gleiche Hardware bräuchte um das Spiel halbwegs synchron genießen zu können."
nicht für JEDEN spieler wird das spiel dann langsamer, nur für den der einen zu lahmen rechner hat, programmiersystem vorausgesetzt. wenn einer, weil sein rechner lahmt, nur 3 mal pro sekunde daten vom server empfangen und zu ihm senden kann, dann ist das halt so, aber die anderen spieler betrifft das doch nicht. jetzt kommt es halt auf die programmierung an, ob der spieler 3 mal in der sekunde rumhüpft oder 3 mal in der sekunde einen schneckenschritt macht.
diskutiert ohne mich weiter. es wurden ja schon ein paar ansätze dargestellt die funktionieren. ich mache es so wie ich es die ganze zeit mache und die anderen halt so wie sie es die ganze zeit machen. hauptsache jeder wird glücklich.
ich muss jetzt arbeiten!
[ Dieser Beitrag wurde am 02.07.2003 um 13:56 Uhr von KXII editiert. ]
-
ok, ich glaub ich verstehe so langsam, wieso manchmal doch mehr Logictics notwendig sind. Was ich mache ist aber nur ein simples 2D Spiel, eine kleine WiSim, wo nur Daten angezeigt werden, der MausCursor und ein paar Buttons. Bei dem Spiel ist es tatsächlich sinnlos, mehr LogicTics zu machen. Man kann nur ein paar Sachen kaufen und so.
[ Dieser Beitrag wurde am 02.07.2003 um 17:12 Uhr von TheToast editiert. ]
-
KXII:
Wenn die Frames höher als die Wiederholrate ist kommt das hier raus, von Google:
Der VSync sollte Ihren Augen zuliebe immer eingeschaltet sein. Diese Einstellung synchronisiert das erzeugte Bild der Grafikkarte mit dem Monitor, das heisst die Grafikkarte wartet auf den Monitor bis dieser das aktuelle Bild dargestellt hat, bevor das nächste Bild angezeigt wird. Ist diese Funktion ausgeschaltet, kann die Grafikkarte den Monitor überholen oder diesem hinterherhinken, wodurch Teile von zwei oder mehr Bildern gleichzeitig angezeigt werden können. Diesen Effekt nennt man "Tearing" und fällt meist bei Animationen und besonders bei Drehungen in Spielen auf.
VSync wird auch gerne als VBlank (= Vertikale Austastlücke = Bildanfang) bezeichnet.
Achtung! Bei vielen Leuten herrscht die Meinung durch eingeschalteten VSync würde die Performance von Grafikkarten gedrosselt. Dies ist in diesem generellen Stil nicht richtig, denn durch das eingeschaltete V-Sync werden nur Performance-Spitzen oberhalb der Monitor-Wiederholungsrate abgeschnitten. Da nicht die maximale Performance ausgenutzt wird sinken natürlich die Benchmark-Ergebnisse, dieser "Performance-Verlust" ist aber im normalen Betrieb nicht merkbar (oder können Sie 90 Bilder/s von 60 Bilder/s unterscheiden?). Das eingeschaltete V-Sync bringt sogar einen Vorteil durch das "ruhigere" Bild. Um dies zu verdeutlichen hier ein Performance-Diagramm
-
@the toast
das ist alles nicht neues für mich...
ich habe früher grafikarten mittels assembler, ports und interrupts direkt angesprochen, und sowohl vsync als auch hsync selber an und ausgeschaltet. ich weiß also ganz genau wovon ich spreche...
nichts für ungut!
-
Es ist also richtig, dass mit der methode bei der pro sekunde eine bestimmte anzahl logicupdates durchgeführt werden, und der comp dafür nicht schnell genug ist, das spiel auf dem computer langsamer läuft?? Wär ja irgendwie scheisse, denn vor allem bei netzwerkspielen kommt es ja meistens sehr stark auf geschwindigkeit an
gibt es bereits kommerzielle spiele bei denen das so ist? würd mich mal interessieren..
-
Original erstellt von rapso:
**die spielgeschwindigkeit bleibt eigentlich immer gleich, egal welcher rechner, das ist das was logicticks ausmacht. du kannst fest davon ausgehen, dass sie alle z.B. 40ms aufgerufen werden und dass das delta 40ms ist!um flüssige darstellung zu haben, hat man immer noch animatoren, die man im logictick einstellst.**
DAS kann ja nicht sein. Vielleicht ist ja der Rechner eben auch zu langsam dafür, alle 40 ms den LT aufzurufen..!! Und dann??
Und das mit den Animatoren...
Was ist denn, wenn ich unterwegs - direkt nach dem ersten LT - dem Panzer einen neuen Wegpunkt zuweise - dann müsste ja - sobald der nächste LT kommt, der Panzer etwas "springen"...
Das wär' ziemlich übel...Original erstellt von DasPinsch:
Es ist also richtig, dass mit der methode bei der pro sekunde eine bestimmte anzahl logicupdates durchgeführt werden, und der comp dafür nicht schnell genug ist, das spiel auf dem computer langsamer läuft?? Wär ja irgendwie scheisse, denn vor allem bei netzwerkspielen kommt es ja meistens sehr stark auf geschwindigkeit an gibt es bereits kommerzielle spiele bei denen das so ist? würd mich mal interessieren..Naja. CCG regelt glaub' ich alle Spieler im NW runter, wenn eine Kiste aufgrund langsamer GraKa o.ä. nicht mitkommt...