[C/C++/Win32] Constante framerate en v-sync

[Verwijderd]

Ik ben bezig met het maken van een emulator voor verschillende retro consoles/arcades door middel van een plugin based systeem. Om er voor te zorgen dat de framerate (50 FPS, 60 FPS of wat de plugin wil) constant is, synchroniseer ik met de directsound buffer (gebruik makend van read/write cursors). Dit blijkt in de praktijk zeer goed te werken en dezelfde code heeft in andere hobby projecten nog nooit problemen opgeleverd. Het enige nadeel van deze methode is dat de CPU op 100% belasting gaat om voor de synchronisatie te zorgen. Dit is natuurlijk niet echt gewenst in een multi-tasking OS (Vista in dit geval).

Daarom heb ik besloten om een andere manier van timing te gebruiken die niet de volle 100% van de CPU nodig heeft. Namelijk d.m.v de QueryPerformance counters bereken ik hoeveel tijd mijn code nodig heeft om een volledig frame te emuleren en te renderen (geluid en beeld). Ik weet hoeveel tijd mijn code maximaal mag gebruiken (1000 / TargetFPS millisec.) dus weet ik ook hoeveel tijd ik kan slapen (Sleep()) voordat ik aan het nieuwe frame begin. Dit blijkt erg goed te werken, al verwacht ik wel wat problemen met Sleep() omdat de resolutie hiervan niet echt goed is.

Het probleem waar ik nu tegen aanloop is dat zodra ik v-sync inschakel de framerate zakt. Dit omdat de Sleep() ervoor zorgt dat ik de v-sync mis en dus moet wachten tot de nieuwe v-sync.

Hoe kan ik dit probleem oplossen ? Heeft iemand ooit zelf ook tegen dit probleem aangelopen ? Zijn er eventueel andere manier om te zorgen voor een vaste framerate ?

[Verwijderd]

Is een semaphore misschien een oplossing? Blijf wachten tot de tijd verstreken is, of zodra je een schop krijgt (van bijvoorbeeld v-sync).

[Verwijderd]

Het probleem is dat alles op dezelfde thread draait (in dit geval de main thread, of "GUI thread"). Dit is wel iets wat ik in de toekomst wil veranderen (main, rendering en geluid allemaal hun eigen thread) maar mijn kennis betreffende threads is erg minimaal.

Het v-sync signaal komt van Direct3D9Ex in dit geval, dus om te kunnen werken met semaphores zal ik in een aparte thread moeten pollen op v-sync. Dit komt de CPU belasting niet ten goede.

[.oisyn]

Hoe ga je sowieso 50 FPS vsyncen met een 60Hz monitor?

[Verwijderd]

Dat gaat inderdaad niet lukken, maar ik wil het wel zo goed mogelijk benaderen. Op dit moment zakt de framerate met ongeveer 10-15 % (schatting) als de v-sync aangaat, wat ongewenst is. Wat ik wel kan doen is de v-sync helemaal vergeten en dus wat screen tearing voor lief nemen.

Edit: Er is geen tearing in windowed mode, omdat de DWM hier voor zorgt. Ik denk dat het in fullscreen mode wel voor problemen kan zorgen (afhankelijk van de monitor refresh rate)

[ Voor 24% gewijzigd door Verwijderd op 22-04-2009 13:37 ]

[Zoijar]

Real-time image-warping zou prima werken [Smit et al. 2007,2008,2009] http://www.xs4all.nl/~smit Zie ook http://www.microsoft.com/whdc/archive/TempRate.mspx. Als je het echt goed wilt doen, dan moet je iets aan temporal rate conversion doen in een extra laag. Je probleem is net zoiets als 24Hz film op een 60Hz TV afbeelden; daar is 3:2 pulldown voor.

[ Voor 20% gewijzigd door Zoijar op 22-04-2009 19:53 ]

[.oisyn]

Maar een game is geen film . Je kunt het wel uit gaan smeren, maar moet je ten eerste 1 frame verder vooruit rekenen (dus extra input lag), en daarnaast is de inputafhandeling ook niet constant.

[Zoijar]

.oisyn schreef op woensdag 22 april 2009 @ 20:09:
Maar een game is geen film . Je kunt het wel uit gaan smeren, maar moet je ten eerste 1 frame verder vooruit rekenen (dus extra input lag), en daarnaast is de inputafhandeling ook niet constant.

Die frame vooruit predict je, meestal op basis van optic flow, of op basis van nieuwe input; dat is wat ik in die papers doe. 6Hz rendering met 60Hz input.

[Matis]

Zoijar schreef op woensdag 22 april 2009 @ 19:48:
Je probleem is net zoiets als 24Hz film op een 60Hz TV afbeelden; daar is 3:2 pulldown voor.

Ja of de PAL 4% speedup

Anyway ff ontopic:

Hoe ik mijn applicaties altijd cap op fps is de meest fatsige doch werkende methode.

Je pakt de currenttime aan het begin van de methode en aan het einde.

Het verschil daarvan trek je van 1000000/60 af en dat usleep je. Dus geen sleep!


Edit:
Zorg wel dat je tussen de twee timers ALLES hebt gedaan, immers *locked* je applicatie (wat ik overigens erg lelijk vind, maar dat terzijde)

[ Voor 13% gewijzigd door Matis op 22-04-2009 21:22 ]

[vdvleon]

Ik weet vrij weinig van grafies programmeren (eigenlijk zo goed als niets), maar zou je niet gewoon met bijv. 2 threads kunnen werken. De ene thread werkt gewoon op de max fps als hij kan, per frame schijft hij dit weg in een buffer. De andere thread die op, in dit geval, 50 fps draait (50hz) haalt per frame dan het huidige frame uit de buffer en stuurd die door naar je scherm... Zou dat niet kunnen werken?

[roy-t]

vdvleon schreef op donderdag 23 april 2009 @ 17:11:
Ik weet vrij weinig van grafies programmeren (eigenlijk zo goed als niets), maar zou je niet gewoon met bijv. 2 threads kunnen werken. De ene thread werkt gewoon op de max fps als hij kan, per frame schijft hij dit weg in een buffer. De andere thread die op, in dit geval, 50 fps draait (50hz) haalt per frame dan het huidige frame uit de buffer en stuurd die door naar je scherm... Zou dat niet kunnen werken?

Dat zou nog best eens goed kunnen werken, maar je moet wel zorgen dat er maximaal 1 of 2 frames in de queue kunnen staan of dat er 1 frame is dat telkens overschreven gaat worden. Wel heb je dan een aantal concurrency problemen (read/write lock op dat frame). En hoe zorg je ervoor dat het "teken naar scherm frame" act op het v-sync signaal, en snel genoeg zodat het niet '1hz' moet wachten.

Ook is het zo dat je een ongelijke frame rate gaat krijgen (teken thread bijvoorbeeld op 50fps en het scherm thread op 75fps/hz ivm 75hz scherm) zou er voor zorgen dat 1 op de 3 plaatjes 2x getekend worden, ik weet alleen niet of dat merkbaar is.

Maar goed dit zijn problemen waar ik zelf normaal geen last van heb (ivm geen vaste fps eis). Ik ben benieuwd hoe deze oplossingen gaan werken en hoe oa. .Oisyn en Zoijar hier over denken (denk ik de mensen met de meeste ervaring hierover @ got).

[Verwijderd]

vdvleon schreef op donderdag 23 april 2009 @ 17:11:
Ik weet vrij weinig van grafies programmeren (eigenlijk zo goed als niets), maar zou je niet gewoon met bijv. 2 threads kunnen werken. De ene thread werkt gewoon op de max fps als hij kan, per frame schijft hij dit weg in een buffer. De andere thread die op, in dit geval, 50 fps draait (50hz) haalt per frame dan het huidige frame uit de buffer en stuurd die door naar je scherm... Zou dat niet kunnen werken?

Nee dat zal helaas niet werken in dit geval: aangezien het hier een emulator betreft, kan je deze niet op max fps laten werken. Als je bv 600 fps kan halen (een Sega Master System emuleren op een moderne CPU moet dit zeker kunnen halen) betekend dat je ge-emuleerde machine al 10 seconde verder is, terwijl dit in werkelijkheid maar 1 seconde mag zijn. Oftewel je gaat 10x te snel. Daarom heb ik een constante framerate nodig.

[roy-t]

Verwijderd schreef op donderdag 23 april 2009 @ 21:03:
[...]


Nee dat zal helaas niet werken in dit geval: aangezien het hier een emulator betreft, kan je deze niet op max fps laten werken. Als je bv 600 fps kan halen (een Sega Master System emuleren op een moderne CPU moet dit zeker kunnen halen) betekend dat je ge-emuleerde machine al 10 seconde verder is, terwijl dit in werkelijkheid maar 1 seconde mag zijn. Oftewel je gaat 10x te snel. Daarom heb ik een constante framerate nodig.

De kern van zijn idee is niet 1 op max snelheid, maar dat 2 threads op verschillende snelheden lopen, je kunt in het "render thread" (3e naam voor het beestje) dus wel die waits e.d. blijven gebruiken maar het vsync probleem los je op door een thread die op v-sync snelheid loopt en op die momenten pas naar het scherm tekent.

[Verwijderd]

roy-t schreef op donderdag 23 april 2009 @ 22:04:
[...]


De kern van zijn idee is niet 1 op max snelheid, maar dat 2 threads op verschillende snelheden lopen, je kunt in het "render thread" (3e naam voor het beestje) dus wel die waits e.d. blijven gebruiken maar het vsync probleem los je op door een thread die op v-sync snelheid loopt en op die momenten pas naar het scherm tekent.

Ok, dus als ik het goed begrijp hebben we 2 threads. Thread 1 is de gui/application thread waar het eigenlijke emuleren gebeurd. Deze thread loopt dus op de constante framerate (60, 50 FPS) en deze Sleep()-ed waar mogelijk (zoals ik in de topic start al aangaf). Thread 2 is de render thread, en loopt dus eigenlijk op de monitor refresh rate en swapped de backbuffers op het moment dat er een v-sync signaal is. Dit zou inderdaad wel eens goed kunnen werken, echter wordt het hoognodig tijd om mijn kennis over multi-threaded progammeren iets te verbeteren In ieder geval bedankt voor de tip, dit is zeker iets wat ik uit ga proberen.

[roy-t]

Verwijderd schreef op donderdag 23 april 2009 @ 22:12:
[...]


Ok, dus als ik het goed begrijp hebben we 2 threads. Thread 1 is de gui/application thread waar het eigenlijke emuleren gebeurd. Deze thread loopt dus op de constante framerate (60, 50 FPS) en deze Sleep()-ed waar mogelijk (zoals ik in de topic start al aangaf). Thread 2 is de render thread, en loopt dus eigenlijk op de monitor refresh rate en swapped de backbuffers op het moment dat er een v-sync signaal is. Dit zou inderdaad wel eens goed kunnen werken, echter wordt het hoognodig tijd om mijn kennis over multi-threaded progammeren iets te verbeteren In ieder geval bedankt voor de tip, dit is zeker iets wat ik uit ga proberen.

Nouja het was vdvleon's idee, maar het klinkt op het eerste gezicht wel goed. Maar ik weet niet of je later ineens tegen iets aan gaat lopen van "oooh shit nee!". Laat even horen of het gelukt is (mogelijk met een stukje relevante code). Ik ben erg benieuwd!

[vdvleon]

Ok, lol. Ik heb toch nog wat goeds bedacht zonder dat ik uberhaupt iets weet van grafisch programmeren.

Met thread moet je er op letten dat je niet tegelijkertijd leest en schrijft (of andere combinaties) op 1 variable. Je kunt hiervoor gebruik maken van Mutex's. Zoek daar maar naar op internet. Succes. Lijkt me inderdaad leuk als je nog eff meld of het heeft gewerkt.

[ Voor 0% gewijzigd door een moderator op 26-04-2009 12:14 . Reden: ..... ]

[bobo1on1]

Je huidige implementatie van een timer kan stukken beter, wat je moet doen is de timestamp berekenen wanneer je wat moet gaan doen en tot aan dat moment sleepen, zo ongeveer:

C:

long long int target;
LARGE_INTEGER now, freq;
int sleeptime, fps = 50;

QueryPerformanceCounter(&now);
QueryPerformanceFrequency(&freq);
target = now.QuadPart;

while(1)
{

  //do something here

  target += freq.QuadPart / fps;
  QueryPerformanceCounter(&now);
  (sleeptime = (target - now.QuadPart) * 1000 / freq.QuadPart) > 0 ? Sleep(sleeptime < (1000 / fps) ? sleeptime : (1000 / fps)) : 0;
}

Kijk ook eens naar timeBeginPeriod om de Sleep nauwkeuriger te maken.

[Zoijar]

Dat met die buffers is zeker een goed idee; dat is ook de manier waarop ik het doe Voor de algemeenheid heb ik een interprocess producer/consumer buffer waar de 60Hz display frames "consumed" en de applicatie nieuwe frames "produced". Meestal zal er voor de display geen nieuwe frame beschikbaar zijn. Om dat te testen poll je de producer/consumer buffer non-blocking. Als er een nieuwe frame beschikbaar is, dan beeld je die direct af. Als er geen nieuwe frame beschikbaar is, dan moet je een nieuwe frame maken op basis van de vorige frames en timing informatie. Je zou dat kunnen doen door gewoon de laatste frame te kopieren. Geavanceerdere technieken extrapoleren een nieuwe frame op basis van de vorige frames. Dat kan je doen door een 2D optic flow field te berekenen met de pixel informatie, en dan de pixels iets "verder schuiven" op basis van de beweging. Die techniek zit in veel moderne TVs die op 100Hz draaien; meestal heet dat motion flow (sony) of natural motion (philips). Het voordeel dat een TV heeft (zoals oisyn al opmerkte) is dat ze frames kunnen bufferen en dus nieuwe, tussenliggende frames kunnen produceren op basis van de vorige en de volgende frame. In feite is dat een soort real-time MPEG compressie, waar ook tussenliggende frames worden aangemaakt op basis van keyframes. In applicaties kan je geen frames bufferen zonder extra latency (lag, vertraging) op de input te introduceren. Latency is de root-of-all-evil in interactieve applicaties, dus dat wil je niet (hoewel het je zal verbazen dat veel LCD displays zonder pardon iets van 100ms extra latency introduceren ten opzichte van een CRT; ook door buffering om de response tijden omlaag te krijgen... dat is erg kwalijk, en niemand schijnt daar op te letten. Vooral voor games is dat funest; dan staat er 2ms response tijd op, denken ze een snel scherm te hebben, maar worden er ondertussen 4 frames gebuffered met 100ms extra latency... ) In ieder geval, in een applicatie moet je dus een nieuwe frame maken alleen op basis van vorige frames.

[Soultaker]

bobo1on1 schreef op zondag 26 april 2009 @ 03:15:
Je huidige implementatie van een timer kan stukken beter, wat je moet doen is de timestamp berekenen wanneer je wat moet gaan doen en tot aan dat moment sleepen, zo ongeveer:

Juist, dit is ook wat ik zou doen (en gedaan heb voor spelletjes). Het probleem is niet zozeer dat sleep niet nauwkeurig genoeg is (Windows draait op 300 Hz ofzo) maar dat je de doeltijd vrijwel altijd overschrijdt; als je daar geen rekening mee houdt dan raak je na verloop van tijd dus out-of-sync, maar je kunt daar makkelijk voor compenseren door.

Overigens is het ook zinnig om ná een sleep call te kijken hoeveel frames je achter loopt; als dat meer dan b.v. 5 ofzo is, is het waarschijnlijk beter om je timer te reseten, om te voorkomen dat je in een busy loop veel te veel frames probeert in te halen. (Als dat consequent voorkomt, dan kun je blijkbaar geen 60 FPS renderen.)

[R4gnax]

Zomaar wat advies:

Raadpleeg 'ns bestaande game-console emulators als zsnes. Die hebben immers al jaren werkende oplossingen voor dit probleem. Er is daar vast wel een developer die je hier even mee wil helpen.

[leuk_he]

ipv van sleep de multimedia timers gebruiken?

http://msdn.microsoft.com/en-us/library/ms704986(VS.85).aspx

[bobo1on1]

Die multimedia timers doen zo ongeveer hetzelfde alleen dan in een aparte thread.

Wat ook een goede oplossing is (en zo'n beetje de standaard bij games) is kijken hoe laat het is voor je elk frame gaat renderen zodat je weet wat je moet doen.

[leuk_he]

bobo1on1 schreef op zondag 26 april 2009 @ 22:10:
Die multimedia timers doen zo ongeveer hetzelfde alleen dan in een aparte thread.

Volgens msdn draaien die mulitmedia timers op een hogere resolutie, en juist zijn probleem is dat de resolutie van sleep niet goed genoeg is.

Het probleem dat windows helemaal niet real-time is blijft uiteraard gewoon.

[Verwijderd]

OK, even wat feedback over de goede reacties die er gepost zijn:

bobo1on1 schreef op zondag 26 april 2009 @ 03:15:
Je huidige implementatie van een timer kan stukken beter, wat je moet doen is de timestamp berekenen wanneer je wat moet gaan doen en tot aan dat moment sleepen, zo ongeveer:

Inderdaad, mijn huidige timer kan een stuk beter. De code die je gaf lijkt me erg toepasbaar in dit geval, en zal ik dus ook zeker uitproberen. Het lost het probleem met het missende v-sync signaal niet op, maar dat is wel te verhelpen door het producer/consumer verhaal.

Zoijar schreef op zondag 26 april 2009 @ 11:47:
*knip.. goed verhaal over motion-flow*

In applicaties kan je geen frames bufferen zonder extra latency (lag, vertraging) op de input te introduceren. Latency is de root-of-all-evil in interactieve applicaties, dus dat wil je niet.

Inderdaad, latency is hier dus niet gewenst. Zowel op de input, beeld en geluid.

Soultaker schreef op zondag 26 april 2009 @ 12:20:
Overigens is het ook zinnig om ná een sleep call te kijken hoeveel frames je achter loopt; als dat meer dan b.v. 5 ofzo is, is het waarschijnlijk beter om je timer te reseten, om te voorkomen dat je in een busy loop veel te veel frames probeert in te halen. (Als dat consequent voorkomt, dan kun je blijkbaar geen 60 FPS renderen.)

Op dit moment zorg ik ervoor dat de ge-emuleerde machine geen frame berekend (oftewel een framedrop). Hij zorgt wel dat de interne status van de VDP (Video Display Processor) gewoon geupdate wordt (bv. sprite collisions, sprite overflow etc) maar hij tekend geen nieuw beeld. In de praktijk blijkt dat het renderen van een frame veel tijd kost binnen een emulator (afhankelijk van wat je emuleert natuurlijk) en door dit over te slaan kun je meestal goed terug in sync komen. Als het blijkt dat je gewoon veel te veel framedrops krijgt dan is de CPU niet krachtig genoeg om de machine te emuleren.

R4gnax schreef op zondag 26 april 2009 @ 20:45:
Zomaar wat advies:

Raadpleeg 'ns bestaande game-console emulators als zsnes. Die hebben immers al jaren werkende oplossingen voor dit probleem. Er is daar vast wel een developer die je hier even mee wil helpen.

Ik heb zelf al enige jaren ervaring met emulators (Xega, SMaSher, DreamVMU) en had een concept dat altijd goed werkte, maar tegenwoordig niet meer gewenst is vanwege de CPU load. Ik heb ook veel contact met mede emulator developers (Steve Snake anyone ?).

leuk_he schreef op zondag 26 april 2009 @ 23:27:
[...]
Het probleem dat windows helemaal niet real-time is blijft uiteraard gewoon.

Inderdaad, het zou mooi zijn om een dedicated OS te hebben voor emulators/games. Zodoende heb je alle resources tot je beschikking (kijk bv. naar de Xbox360: De dynarec die ze gebruiken voor de orginele xbox is een knap staaltje programmeer werk maar zal niet goed toepasbaar zijn op de PC omdat er zoveel resources nodig zijn)

Afijn, ik heb nu veel info waar ik mee aan de slag gaan. Voor de mensen die geinteresseerd zijn, mijn project heet Triton (www.eidolons-inn.net site heeft alleen wat hosting problemen denk ik)

[BigDplayboy]

Beetje mieren-neukerig misschien, maar ik zou bij die timer implementatie wel al die delingen eenmalig vantevoren buiten de loop doen. In de voorbeeld-code zijn de variablen <fps> en <freq.QuadPart> vaste waardes. Nu zullen deze in de praktijk geen hardcoded waarden worden, maar vast wel waardes die niet iedere loop wijzigen. Het is dan een beetje zonde van cpu-power om die "1000 / fps" en "1000/ freq.QuadPart" iedere loop opnieuw te bereken. Vooral omdat delingen het meeste kosten.

[/mierenneuk-mode off]

[bobo1on1]

Daar zou ik me helemaal niet druk over maken, de meeste compilers doen dat soort optimalisaties al.
Plus dat de winst extreem klein is vergeleken met wat er voor de rest allemaal draait.

[.oisyn]

Sorry BigDplayboy maar dat gaat echt helemaal nergens over . Op het moment dat een enkele deling in je gameloop de dienst aan het uitmaken is ben je eigenlijk niets anders aan het doen in die loop dan die ene deling. Je hebt het nu over een paar cycles winst op een iteratie die waarschijnlijk miljoenen cycles kost. Effectief dus een optimalisatie van 0.00001%. Woei

[Matis]

.oisyn schreef op dinsdag 28 april 2009 @ 22:54:
Sorry BigDplayboy maar dat gaat echt helemaal nergens over . Op het moment dat een enkele deling in je gameloop de dienst aan het uitmaken is ben je eigenlijk niets anders aan het doen in die loop dan die ene deling. Je hebt het nu over een paar cycles winst op een iteratie die waarschijnlijk miljoenen cycles kost. Effectief dus een optimalisatie van 0.00001%. Woei

offtopic:
doet me denken aan de discussie op het werk, dat wanneer je een for-loop maakt je beter kunt aftellen dan optellen, dit scheelt namelijk 1 assembly instructie per loop!

[bobo1on1]

Daar komt trouwens nog bij dat * 1000 / freq.QuadPart niet vereenvoudigd kan worden zonder verlies van precisie (ja ik weet dat QueryPerformanceFrequency altijd 1000000 teruggeeft maar daar kun je volgens microsoft niet vanuit gaan).

[Snake_Y_]

Dit artikel kwam ik toevallig vandaag tegen Fix Your Timestep!