ich habe da mal ne frage zum FPS timer,
wie stark frisst er meine FPS auf?

extrembeispiel:
ein spiel mit 1600*1200 pixeln
vielen shadern und geilen Effekten,
60 FPS möglich?

ich meine, es reicht ja völlig aus 60 FPS zu haben, außerdem kann man dadurch z.B. für eine Game engine dem Spieler/Kreativling mehr kontrolle geben. is FPS timing für extremanwendungen scheiße?

also du möchtest zb ein Frame - basiertes movement machen?

_________________
bester uo-shard: www.uosigena.de

Die Zeit die der Aufruf von QueryPerformanceCounter einmal pro Frame kostet ist vernachlässigbar.

zum frame basierten Movement, Jaein

mir geht es vor allen dingen darum die FrameZahl zu begrenzen auf eine vernünftiges maß, dass auch wirklich von allen gängigen Computern noch gerendert werden kann. schaut euch mal Game Maker an. Dort kann man per properties in den einzelnen Räumen(levels) jedem raum eine maximal Frame anzahl zuordnen, die kontrolle über die framezahl ist sehr groß. Sachen wie speed sind sehr leicht zu handhaben, da sie einen per-Frame pixelsprung darstellen. letztlich ist es dann ein framebased movement. außerdem habe ich langfristig vor, Game Maker nachuproggen, aber nehmt es bitte noch nicht als projekt ernst, wer weiß wie schnell ich zugang zu delphi/freepascal bekomme, es kann gut sein dass ich bald frustriert aufgebe.... oder eben weitermache

die ganzen game engines die ich gefunden habe, gefallen mir nicht, sie sind nicht so einfach wie GM und letztlich bieten sie nicht viel mehr als GM. Mit GM bin ich schließlich ins gameproggen eingetaucht...

warum denn ein frame basiertes movement? Du kannst ja unabhängige Threads benutzen, für Bewegung usw. Wenn du es aber unbedingt begrenzen willst, fällt mir eine Möglichkeit ein:

Du probierst irgendwie experimentell oder wie auch immer herauszufinden wie lange du brauchst um ein Frame zu rendern und rechnest damit einen timeout in jedem Frame aus, zb 5-20ms pro. Damit erreichst du dann Frameraten von max. 50-200.

Ausserdem kannst du auch um die Frame Anzahl ein bisschen zu begrenzen, so um die 70 herum V-Sync einschalten.

mfg

_________________
bester uo-shard: www.uosigena.de

Hier mal ein einfaches Quick&Dirty Beispiel für FPSRateLimiting von "bis zu" max. 50 FPS (also im worstcase weniger als 50 fps, im bestcase konstant 50 FPS):



Zugegeben, sowas ist normalerweise eher in PhysikEngines (die Step für Step was verabarbeiten) im Einsatz, aber das Grundprinzip von dem Code oben sollte eigentlich auch gut fürs FPSRateLimiting (mit bisschen Feintuning) geeignet sein.

Statt GetTickCount kannst du dann näturlich auch was anders verwenden. z.B. QueryPerformanceCounter, oder wenn du SDL verwendest halt SDLGetTicks, je nach dem, wie genau du das ganze haben willst.

Und noch ein Tipp, verwende statt Integer Ganzzahlen besser Integer Fixed Point (beispielsweise 32.32bit als ein Int64), denn z.B. für max. 60 FPS sind reine Integer Ganzzahlen hier ganz unbrauchbar, denn 1000/60 = 16,666p Millisekunden für TimeStep. Ich hoffe mal, dass du weiss, wie man solchen FixedPoint Kram implementiert. Ansonsten zur Not tun es hier ja auch FloatingPoint Variablen für das einfachere Handling.

_________________
Behindert ist man nicht, behindert wird man.

Bero: Ich weiß du hattest gesagt Quick und Dirty. Aber was für einen Sinn macht es die Framerate auf 50 zu begrenzen wenn man die dadurch gewonnene Zeit mit Busywaiting verwendet?

Also wenn man die Framerate begrenzt dann doch bitte auch so, dass die gewonnene Zeit auch wirklich gewonnen bleibt. Was unweigerlich auf ein Sleep hinausläuft. Letztenendes werden es dir vor allem auch Laptopbesitzer danken. Und zwar so wie Gaukler das schon gesagt hat. Du misst die Zeit die du für das Rendern eines Frames benötigst und die Different zu dem Sollwert wartest du dann. Für das Timebased Movement solltest du die Zeit nach dem Warten messen. Das Sleep arbeitet nämlich nicht ganz genau und dadurch könnte man Abweichungen im Sleep auch schon ausgleichen. Bzw solltest du auch um deine Framerate zu "garantieren" auch 1 ms weniger an das Sleep übergeben. Eben auch schon weil Sleep immer ein bisschen länger wartet als der Werte den man übergeben hat.

Das Verhalten gilt nur für Windows. Ob Linux das Ähnlich macht weiß ich nicht. Da gehe ich aber mal von aus.

Ja, das ist nur eine Quick&Dirty Lösung, wie ich es bereits extra getont habe. Das sollte ja auch nur das Grundprinzip bzw. die Grundidee verdeutlichen.

Ich verwende lieber seit Jahren in BeRoTracker Impulse (die Variante mit einer OpenGL GUI) sowas in der Art wie dieser folgenden Lösung hier:



wobei hier GetTickCount und Sleep etwas ungenau sind, von daher hier die IF Abfrage. Und ein Sleep(0); wirkt dann wie ein einfaches Yield (=Taskswitchforcing), also wenn NextTime = Now, da dann NextTime - Now = 0.

Denn Windows arbeitet intern nur mit einer Timer Auflösung von 10 ms (100 Hz). Deswegen ist Windows auch kein richtiges Echtzeitsbetriebssystem, wo andere im Audiobereich wie ich dann oft tricksen müssen, besonders beim MIDI Outputtiming, wo es besonders wichtig ist. Steinberg geht mit Cubase etc. beispielsweise hier einen besonderen Weg, aber mehr dazu findest du, wenn du googelst, dann das wird jetzt hier ein bisschen Offtopic.

Züruck zum Thema:

Unter Linux tickt der Systemtimer unter den meisten Dists noch niedriger als unter Windows, sei denn, man hat Realtime Kernel Hacks in einen eigenen Kernel mitkompiliert, was aber meistens nur auf Linux Installationen angewandt wird, die entweder für Audioproduktion oder für andere Echtzeitanwendungen (Robotik, Messungen etc.) im Einsatz sind. Also unter einem normalen Linux Kernel ohne diese Hacks ist es hinaus viel schwieriger als unter Windows sowas möglichst genau zu timen. Dazu kommt noch, dass unter Linux bzw. generell unter *nixe bzw. reine POSIX Betriebsysteme das Thread scheduling intern meistens etwas anders als unter Windows funktioniert.

_________________
Behindert ist man nicht, behindert wird man.