Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mi Jul 09, 2025 04:33

Foren-Übersicht » Programmierung » Einsteiger-Fragen
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: wie stark "frisst" FPS timer
BeitragVerfasst: So Dez 17, 2006 22:22 
Offline
DGL Member

Registriert: Di Dez 12, 2006 21:37
Beiträge: 30
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?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Dez 17, 2006 23:08 
Offline
DGL Member

Registriert: Sa Okt 22, 2005 20:24
Beiträge: 291
Wohnort: Frauenfeld/CH
also du möchtest zb ein Frame - basiertes movement machen?

_________________
bester uo-shard: www.uosigena.de


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Dez 17, 2006 23:12 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Die Zeit die der Aufruf von QueryPerformanceCounter einmal pro Frame kostet ist vernachlässigbar.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Dez 18, 2006 18:54 
Offline
DGL Member

Registriert: Di Dez 12, 2006 21:37
Beiträge: 30
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... :)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Dez 18, 2006 20:46 
Offline
DGL Member

Registriert: Sa Okt 22, 2005 20:24
Beiträge: 291
Wohnort: Frauenfeld/CH
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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 19, 2006 03:40 
Offline
DGL Member

Registriert: Di Aug 26, 2003 20:08
Beiträge: 81
Wohnort: Mönchengladbach
Programmiersprache: ObjPas ASM C C++ etc
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):

Code:
  1.  
  2. procedure MainProc;
  3. const TimeStep=20; // 20 ms = 1000/20 = 50 Hz bzw. hier Frames per second
  4. var LastTime,NewTime:integer;
  5. begin
  6.  ...
  7.  LastTime:=GetTickCount;
  8.  while not ProgramEnd do begin
  9.   ...
  10.   NewTime:=GetTickCount;
  11.   while LastTime<NewTime do begin
  12.    RenderFrame;
  13.    inc(LastTime,TimeStep);
  14.   end;
  15.   ...
  16.  end;
  17.  ...
  18. end;
  19.  


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.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 19, 2006 09:45 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
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.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 19, 2006 10:24 
Offline
DGL Member

Registriert: Di Aug 26, 2003 20:08
Beiträge: 81
Wohnort: Mönchengladbach
Programmiersprache: ObjPas ASM C C++ etc
Lossy eX hat geschrieben:
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?


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:

Code:
  1.  
  2. const NextTime:integer=0;
  3. procedure AutomaticFlexibleSleep:
  4. const Interval=20;
  5. var Now:integer;
  6. begin
  7.  Now:=GetTickCount;
  8.  if NextTime<=Now then begin
  9.   NextTime:=Now+Interval;
  10.  end;
  11.  Sleep(NextTime-Now);
  12. end;
  13.  


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.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Foren-Übersicht » Programmierung » Einsteiger-Fragen


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 17 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.008s | 14 Queries | GZIP : On ]