Archief - Sprite tekenen zorgt voor 14000 FPS

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

ultddave

Legacy Member
Hey,

Ik heb een probleem. Ik wil in openGL een sprite op het scherm tekenen. Maar als ik dat doe begint de ventilator van mijn grafische kaart opvallend hard te draaien. Activiteit van de kaart springt naar 38%- 51% en soms hoger, en temperatuur gaat van 51 -> 57 graden.

Sprite zelf is PNG file (64x64 pixels) en wordt zonder problemen weergegeven.

De scene is dus volledig zwart met enkel de sprite die zichtbaar is, voor de rest wordt er niets getekend.

Het probleem bleek toen echter bij het aantal frames per second te liggen: 11000 - 14000.

Iemand enig idee hoe je het best het aantal frames per second limiteert?

Code waarbij ik irrelevante functies ivm keyboard/mouse input enzo heb weggelaten. [C++] C++ openGL - Pastebin.com

De tijd tussen het aantal frames wordt berekend door de functie GetElapsedTimeInSeconds. UpdateFrame gaat met die info dan kijken hoeveel FPS we hebben.

Zou ik gewoon iets simpels doen zoals die ellapsedtime of FPS gebruiken om al dan niet de "renderFrame" functie aan te roepen?

Bijvoorbeeld:

Code:
if(g_framespersecond <= 60)
  renderframe();
else
  return; // moet zelfs niet, maar kom :P;

Of kan ik dat beter op een andere manier aanpakken? ;)

PS: De code heb ik van internet gehaald, ben van plan deze beter te structureren, want in het begin stond echt alles in die ene file. Was een beetje onoverzichtelijk aan het worden. Ben nu apparte klassen voor de camera, renderer etc aant maken ;).

Dank bij voorbaat.

Mvg,
Dave

blackrabbit

Legacy Member
Ken er weinig van, maar kunt ge dat niet met vsync regelen?

Raanº³

Legacy Member
Je FPS kun je op verschillende manieren laten 'cappen'.

De 'gemakkelijkste' manier dat ik ooit heb gezien (wel enkel ervaring met DirectX & Windows, OpenGL en/of linux heb ik me nog niet met bezig gehouden en het is al reeds een goede 4-5 maand terug :crazy: ) was gebruik maken van een High Performance Timer (in Windows.h) en dan laat je je applicatie steeks 'tikken' (blijven tikken tot je je screen moet updaten). Tijdens het ticken bekijk je of er genoeg tijd is gepasseerd om opnieuw iets te doen of hem met rust te laten.

Geen idee hoe je opbouw van je applicatie eruit ziet (heb niet naar je code gekeken), doch als je nu ervan uitgaat dat al je "timing" functionaliteiten (FPS, scaling vectors, relatieve waarden mbt tijd sinds vorige frame,...) in 1 klasse zitten, kun je het zo opbouwen:

header:
Code:
class Timer
{
...
public:
...

// Publieke functie prototypen
void Tick(float fLockFPS = 0.0f);
float GetTimeElapsed() const;

...
private:
...
// private vars mbt functie prototypen
__int64 m_CurrentTime; // Huidige tijd -- performance counter
float m_TimeElapsed; // Tijd tussen huidige en vorige tijd -- voor tickberekeningen
...
}

body:
Code:
Timer::Tick(float fLockFPS)
{
	float fTimeElapsed;

	// Laten we er van uit gaan dat de Hardware Performancecounter bestaat en schrijven dit weg in current time.
	QueryPerformanceCounter((LARGE_INTEGER *) &m_CurrentTime);

	// Bereken de tijd sinds de 'laatste' tick
	fTimeElapsed = (m_CurrentTime - m_LastTime) * m_TimeScale;

	// Hebben we onze FPS gelocked?
	if (fLockFPS > 0.0f)
	{
		// Gedachte: Zolang er nog niet genoeg tijd is vertreken om 1 frame te renderen, moet hij blijven lopen
               // bvb locked op 60
               // nutteloos om hem te laten renderen voor elke 0,1 frame oid maar pas als de tijd
               // gekomen is om 1 frame te renderen
               // hence de naam frames per second :D
               // ideaal gezien zou hij dus 'eventjes' in de loop zitten tot hij 1/60'ste van een seconde
               // bereikt heeft om te renderen
               // staat onze FPS LOCK te laag, is geen probleem, game zal wel stotteren ofc
               // maar hij zal verversen aan de frequentie van je max aangegeven FPS
               // je kan misschien je FPS Lock dynamisch maken met een maximum hoogte plafond?
               // staat FPS LOCK te hoog, dan zal hij sowieso renderen van zodra hij het kan renderen
               // maar dan is zijn actuele FPS natuurlijk minder dan zijn FPS LOCK
		while (fTimeElapsed < (1.0f / fLockFPS))
		{
			// Bereken opnieuw de huidige tijd
			QueryPerformanceCounter((LARGE_INTEGER *) &m_CurrentTime);

			// bereken opnieuw tijdsinterval
			fTimeElapsed = (m_CurrentTime - m_LastTime) * m_TimeScale;
		}
	}
	
	// sla huidige tijdsframe op
	m_LastTime = m_CurrentTime;
}

Ik dacht dat het zo iets van constructie was dat ik had gebruikt (zoals ik zei: DirectX + Windows), maar kan ook beetje verkeerd zijn. Het is alweer zo lang geleden dat ik nog die boeken heb opengezwierd :D Het is ook op een 'rapke' getypt, dus er kunnen ook fouten in zitten of dingen dat ik gewoon vergeten declareren heb of ;))

*EDIT*
of dingen declareren die ik dan toch niet gebruikt heb :D

Tyfius

Legacy Member
Ik zal hier eens een voormalige collega plezieren met een link naar een artikel dat hij ooit geschreven heeft: deWiTTERS Game Loop.

Het gaat verder op Raanº³ zijn punt, het introduceren van een constante framerate.

ultddave

Legacy Member
blackrabbit zei:
Ken er weinig van, maar kunt ge dat niet met vsync regelen?

In principe wel. V-sync zorgt voor een 60 FPS cap op mijn computer. Maar v-sync wil ik standaard niet gebruiken want volgens mij doet geen enkele game dat. Bij de meeste games kan je dat optioneel "enablen", maar staat standaard altijd disabled.

Maar het is uiteraard wel handig om snel het probleem te omzeilen voor wat te kunnen testen, zonder mijn grafische kaart te belasten, waarvoor dank ;).

Raanº³ zei:

Erg bedankt voor de uitleg en code. Het is inderdaad zoals in het artikel, gelinkt door Tyfius, staat: je moet zowel met trage/snelle hardware rekening houden. Dus ik ga zien of ik een goede dynamische implementatie kan maken van hetgeen u mij gegeven heeft. *fingers crossed*, want het is één van mijn eerste openGL applicaties ^^.

Tyfius zei:
Ik zal hier eens een voormalige collega plezieren met een link naar een artikel dat hij ooit geschreven heeft: deWiTTERS Game Loop.

Het gaat verder op Raanº³ zijn punt, het introduceren van een constante framerate.

Erg bedankt, zeer informatief. ;)

Mvg,
Dave

Raanº³

Legacy Member
ultddave zei:
Erg bedankt voor de uitleg en code. Het is inderdaad zoals in het artikel, gelinkt door Tyfius, staat: je moet zowel met trage/snelle hardware rekening houden. Dus ik ga zien of ik een goede dynamische implementatie kan maken van hetgeen u mij gegeven heeft. *fingers crossed*, want het is één van mijn eerste openGL applicaties ^^.
Geen probleem ;) Als er nog vragen zijn, stel ze maar gerust ;) Wie weet zou dat een aanleiding zijn om mijn "(Graphics) Programming" zelfstudie te hervatten ^^

kwitters

Legacy Member
Tyfius zei:
Ik zal hier eens een voormalige collega plezieren met een link naar een artikel dat hij ooit geschreven heeft.

Dank u wel voormalige collega! :)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan