[JAVA] High Performance Timers

[JKVA]

Voor school moeten we een game maken. Als projectgroep wilden we een (eenvoudige) RTS maken.
Nu leert wat vooronderzoek dat hiervoor bijna altijd de J3D Timer klasse wordt gebruikt omdat de standaard java.util en swing timers niet accuraat zijn.
Java 3D is echter niet standaard Java en staat dus niet op elke computer.
Op internet heb ik ook wel wat andere, 3th party timerklasses gezien, maar nu komt het probleem:

Deze klasses maken allemaal gebruik van een DLL waardoor de klasse niet cross-platform is. (lees: alleen Windows)

Weet iemand of er nog andere high performance cross-platform timerklasses zijn?

[RayNbow]

System.nanoTime() , Java 1.5?

[Alarmnummer]

Wat versta jij onder high performance? (dit heet trouwens geen high performance.. maar de juiste naam hiervoor is realtime) Voor een game hoef je echt niet op de nanoseconde nauwkeurig je tick binnen te krijgen. Een standaard Timer zal ook volstaan.

Dus wat ben jij precies nodig? En ga jij niet expres moeilijk lopen doen omdat je ergens iets hebt gelezen maar geen idee hebt hoe dit zich laat vertalen naar de praktijk?

[ Voor 13% gewijzigd door Alarmnummer op 13-04-2005 20:54 ]

[.oisyn]

Alarmnummer schreef op woensdag 13 april 2005 @ 20:40:
Wat versta jij onder high performance? (dit heet trouwens geen high performance.. maar de juiste naam hiervoor is realtime)

Nee, realtime zegt niets over snelheid, slechts dat je garanties kunt geven over hoe lang iets duurt. Wat de TS echter wilt is een timer met een hele kleine granulariteit (< 1 ms), dat heet wel degelijk een high performance timer.

Voor een game hoef je echt niet op de nanoseconde nauwkeurig je tick binnen te krijgen. Een standaard Timer zal ook volstaan.

nanoseconde nauwkeurig heb je idd niet nodig, je wilt echter wel iets dat nauwkeuriger is dan een milliseconde. System.currentTimeMillis() zal dus niet voldoen, sowieso al niet omdat het geen garanties geeft over de granulariteit.

[Daos]

In de PC is de standaard timer 18.2 Hz. In dos kon je dat opvoeren door een clockdivider te veranderen. Volgens mij ging ook je klok er sneller van lopen

Ik ben bang dat het opvoeren via Java niet zal lukken.

[RayNbow]

Daos schreef op woensdag 13 april 2005 @ 21:51:
In de PC is de standaard timer 18.2 Hz. In dos kon je dat opvoeren door een clockdivider te veranderen. Volgens mij ging ook je klok er sneller van lopen

Ik ben bang dat het opvoeren via Java niet zal lukken.

Beetje off topic, maar goed

quote: http://www.bitbanksoftware.com/Programmers/code4.html

3) The 'high performance' timer functions - These functions reside in KERNEL32.DLL and allow you access to the countdown timer used to trigger the 'low performance' Windows tick counter. In the standard PC-compatible hardware architecture, there is a 1.19Mhz crystal oscillator connected to an Intel timer chip. The timer chip has a 16-bit countdown timer which is loaded with 0 at the start of each cycle. 1.19Mhz divided by a countdown value of 65536 gives 18.2 Hz or 55ms. This is the basis for the PC's tick counter and the timing of the WM_TIMER messages. The 'high performance' functions allow you to directly read the countdown timer value. The value returned is a 64bit integer with the upper 48-bits being the system tick counter and the lower 16 bits being the 1.19Mhz countdown timer value. Microsoft says that this timer is not supposed to exist on all versions of Windows or on all PC's, but every PC I have tried has these functions and they work on Win95, Win98, and Windows NT.

[.oisyn]

Nou ja, als je toch al een dll gebruikt zou je wellicht een interface kunnen maken voor windows' QueryPerformanceCounter()

[JKVA]

Dan toch maar de Java 3D versie. Die werkt in ieder geval goed en dan zetten we de API er wel bij.

[pdkoning]

De Timer van de Java3D api gebruikt getNativeTimer();
Deze roept zoals de naam als doet vermoeden zaken van het operating system aan, namelijk van
kernel32.dll de functiesQueryPerformanceCounter() QueryPerformanceFrequency()

Het valt dus te overwegen hier een eigen klasse of klassen voor te schrijven, die afhankelijk van het OS bovengenoemde (of respectievelijk andere) functies aanroept. Het is dan alleen even uitzoeken hoe en wat bij welk besturingssysteem.

Voordeel als je zoiets hebt gemaakt is dat je niet het 3D gedeelte apart hoeft te installeren op elke machine waar je de game wilt draaien, maar de timer gewoon zelf in de JAR meegeeft.

[Alarmnummer]

.oisyn schreef op woensdag 13 april 2005 @ 21:43:
[...]
Nee, realtime zegt niets over snelheid, slechts dat je garanties kunt geven over hoe lang iets duurt.

Precies. En dat was ook de reden dat ik realtime zei.

Wat de TS echter wilt is een timer met een hele kleine granulariteit (< 1 ms), dat heet wel degelijk een high performance timer.

Dat hoort bij mij toch meer in het hoekje realtime thuis. Het heet 'realtime' als je garanties moet geven mbt tijdscontracten.

nanoseconde nauwkeurig heb je idd niet nodig, je wilt echter wel iets dat nauwkeuriger is dan een milliseconde. System.currentTimeMillis() zal dus niet voldoen, sowieso al niet omdat het geen garanties geeft over de granulariteit.

Kan jij mij uitleggen wat een game moet met zo`n preciese timer?

*denkt eens goed na.. je kunt dan met kleinere tijdsfragmenten wel beter bepalen of een object aangeraakt moet gaan worden voor bv een nieuwe locatie*

[ Voor 10% gewijzigd door Alarmnummer op 14-04-2005 07:51 ]

[JKVA]

Volgens een hoop forums is het grootste probleem als je met de standaard timer werkt, dat in een aantal besturingssystemen de timer werkt met intervallen van circa 50 ms, en dat is erg traag. Dan heb je namelijk een framerate van max 20 fps. Dit haal je echter nooit omdat er nog vanalles bijkomt aan berekenen en graphics op het scherm zetten. Dat is een beetje jammer.

Overigens is dat weer geen probleem met apple en linux, want die triggeren gewoon elke 1 ms.

[RayNbow]

JKVA schreef op donderdag 14 april 2005 @ 12:51:
Volgens een hoop forums is het grootste probleem als je met de standaard timer werkt, dat in een aantal besturingssystemen de timer werkt met intervallen van circa 50 ms, en dat is erg traag. Dan heb je namelijk een framerate van max 20 fps.

Onder Windows 9x is de time granularity 55 ms -> max 18.18 fps.
Onder Windows NT/2k/XP is het 10-15 ms -> max 66.67-100 fps

Dit haal je echter nooit omdat er nog vanalles bijkomt aan berekenen en graphics op het scherm zetten. Dat is een beetje jammer.

Hoezo dat? Je moet aan het einde van een frame niet (1/framerate) secondes wachten, maar (1/framerate - tijd die nodig was voor de berekeningen) secondes.

[Salandur]

RayNbow schreef op donderdag 14 april 2005 @ 13:12:
[...]

Hoezo dat? Je moet aan het einde van een frame niet (1/framerate) secondes wachten, maar (1/framerate - tijd die nodig was voor de berekeningen) secondes.

Dit kan alleen als je een vast aantal frames per seconde wilt, wil je een variabel aantal frames dan gebruik je onder java Thread.yield() en lees je daarna zo exact mogelijk de tijd uit. En dat laatste kan zoals uit de voorgaande berichten blijkt beter niet met System.currenttimeMillis() gedaan worden wanwege de onnauwkeurigheid.

[JKVA]

Maar het komt er dus op neer dat je geen generieke cross-platform timer kan maken in Java 1.4 begrijp ik, tenzij je J3D gebruikt? Of bestaat er in Java 1.4 een functie die geen last heeft van die granulariteit?

[.oisyn]

Alarmnummer schreef op donderdag 14 april 2005 @ 07:48:
[...]

Precies. En dat was ook de reden dat ik realtime zei.

Je wil inderdaad tijdgaranties, maar realtime zegt niets over de snelheid, terwijl die snelheid hier juist wel belangrijk is. En dat soort timers heten in de volksmond gewoon high performance timers

Kan jij mij uitleggen wat een game moet met zo`n preciese timer?

*denkt eens goed na.. je kunt dan met kleinere tijdsfragmenten wel beter bepalen of een object aangeraakt moet gaan worden voor bv een nieuwe locatie*

Het punt zit 'm in afrondingsfouten. Je wil berekenen hoe lang een frame geduurd heeft, de zogenaamde 'frametime', zodat je die kunt gebruiken in je simulatiestap, dus bijvoorbeeld hoeveel objecten vooruit bewogen moeten worden gegeven hun snelheid. Als je een 1 ms nauwkeurige timer gebruikt, en je haalt daaruit dat de tijd tussen de huidige en de vorige frame 16 ms bedraagt, dan zal de snelheid in fps ergens tussen de 59 en de 62 liggen. Met andere woorden, bij 59 frames per seconde zul je 16 ms frametimes krijgen, maar met 62 fps ook. Het gevolg is dat de snelheid waarmee alles reageert in de wereld niet overeen komt met de werkelijkheid, aangezien zowel voor 59 als voor 62 frames per seconde dezelfde frametime eruit komt, maar er in de 62 fps situatie wel 3 meer beeldjes per seconde naar de videokaart wordt gestuurd. Bij 62 fps zal de game dus sneller verlopen dan bij 59 fps, en dat zou niet moeten.

[.oisyn]

Salandur schreef op donderdag 14 april 2005 @ 13:18:
[...]

Dit kan alleen als je een vast aantal frames per seconde wilt, wil je een variabel aantal frames dan gebruik je onder java Thread.yield() en lees je daarna zo exact mogelijk de tijd uit. En dat laatste kan zoals uit de voorgaande berichten blijkt beter niet met System.currenttimeMillis() gedaan worden wanwege de onnauwkeurigheid.

Een thread yielden is alleen nuttig als je je framerate wilt cappen adhv een bepaalde threshold. Zolang je die framerate niet haalt zal ik ook niet gaan yielden, dat betekent namelijk dat het voor de wat tragere PC's nog moeilijker is om een hoge framerate te halen omdat je steeds elke keer de rest van de timeslice in zit te leveren terwijl je die dondersgoed kunt gebruiken. Een game hoeft wat dat betreft ook niet zo aardig te zijn voor resources aangezien het meestal de enige app is waarmee de user interact.

[JKVA]

Maar die verschillen in snelheid bij 59 en 62 fps is volgens mij in principe wel te corrigeren door met system.currentTimeMillis te werken.
Eventueel doe je dat om de paar seconden, omdat currenttimemillis niet erg precies is. Dan is het voor de game geen probleem meer volgens mij. Zien doe je het in ieder gaval niet. (toch???)

[.oisyn]

Hmmja, het is natuurlijk wel zo dat het zich na een aantal frames weer corrigeert. Maar bij een constante framerate worden dan wel verschillende frametimes gerapporteert (bij 60 fps zal dat de ene keer 16 ms zijn, de nadere keer 17 ms), wat je physics weer kan beinvloeden (dat systeem heeft het meeste last van afrondingsfouten). Bottom line is dat je gewoon niet vrolijk wordt van een 1 ms nauwkeurige timer

[JKVA]

Dat maakt overigens bij onze game niet uit. Het wordt maar een eenvoudige top-down rts zonder geavanceerde physics. Daar zijn wij niet goed genoeg voor en we hebben ook maar 10 weken, inclusief documentatie en ontwerp .

[misfire]

Ik ben wel benieuwd waarom System.nanoTime() (de suggestie in de eerste reactie) geen oplossing is voor jouw probleem?

[JKVA]

Omdat die pas in java 1.5 is geimplementeerd en ik daar nog niet echt een hoge dunk van heb, zowel qua stabiliteit alsmede het aantal mensen dat momenteel JRE 1.5 gebruikt. Als er een aantal goede updates geweest is, is het misschien een betere oplossing.

Bovendien is het geen timer, maar haalt deze alleen het aantal nanoseconden op. Er moet wel nog steeds een event getriggerd worden elke keer en daar is die timer voor nodig.

[ Voor 26% gewijzigd door JKVA op 14-04-2005 19:48 ]

[Salandur]

JKVA schreef op donderdag 14 april 2005 @ 19:44:
Omdat die pas in java 1.5 is geimplementeerd en ik daar nog niet echt een hoge dunk van heb, zowel qua stabiliteit alsmede het aantal mensen dat momenteel JRE 1.5 gebruikt. Als er een aantal goede updates geweest is, is het misschien een betere oplossing.

Ik heb even gebruik gemaakt van 1.5 en het draait stabiel genoeg hoor. Er zitten wat uitbreidingen in de collections api, maar daar valt omheen te werken dmv een optie.

[JKVA]

Ik heb het even met een aantal andere projectleden overlegd en we gaan toch voor Java 1.5. Dat scheelt ook weer een berg megabytes omdat die J3D er dan niet bij hoeft. Ook qua stabiliteit zal het wel steeds beter worden.
Het enige probleem is nog dat geen mens (lees Jan met de pet) 1.5 draait, maar die leveren we er wel bij.