Re: [gl4java-usergroup] Errors

[Sven G. <sgo...@ja...>]

Virgil Wall wrote:
> 
> > Dear Virgil,
> >
> > I want to encourage you to use GLAnimCanvas,
> > or hte way GLAnimCanvas uses the animation update methods !
> >
> > I see it in many demos, that you use the threaded sDisplay call for
> > default !
> > This only works within a very good native multithreading JVM,
> > and does steals a lot of ressources ...
> >
> > You can see, that the GLAnimCanvas demos does have the option to
> > refresh directly (useRepaint... method), but it is disabled for default.
> >
> > I think, that the repaint method should be fast enough for us ... >= 20
> > fps :-)
> >
> > Of course, the direct way gives us quiet the same fps, like the native
> > application, but we do pay responsiveness of the JVM for it !
> >
> > Please check the PERFORMANCE mail from me to the mailinglist,
> > and the PerformanceLog's within the demos/MiscDemos directory !
> >
> > Yours, Sven
> 
> Well, the reason I have to call sDisplay in a loop is that I need to very
> accurately track how long it takes to do the display.
> GLAnuimCanvas tracks frames per second by using System.currentTimeMillis().
> This only yields timing accurate to around 16ms (on a good day).  This isn't
> really that good (for a game anyway).  Since I'm writing a game, I want very
> high frame rates and I need to know very precisely how long each update
> takes (so I can move game objects at the right rate).  To solve this
> problem, I make a call into a jni library I've written to more accurately
> calculate time.  (Using the system clock on windows to achieve near
> microsecond accuracy).
> Also, I do a Thread.sleep() once per loop (in order to set a maximum fps).
> 
> In summary, I pretty much do what GLAnimCanvas does, I just need to be able
> to very precisely track how long each update takes (and using
> System.currentTimeMillis() isn't good enough)
>

Really ?
I thought that even 50ms precision should be enough 
-> about 20 fps (more or less :-) !

Well - anyway, if you really have to be that precisous,
i wonder, how you handle the _very_ unprecise Thread.sleep() call ?
Because you are guaranteed to be woke up in the right time ...

> (For the curious, the Magician Java opengl crap has a percision timer
> call... it's pretty each to do, but one might argue that it has nothing to
> do with opengl)
> 

Ok ... so why don't you offer your native function
to GL4Java ?

If the implementation uses the Unix like time functions,
I guess we can add it for ALL OS/platforms !
I love to add it into the next release, if you are fast :-) enough ..
Currently I am working for:
	- Linux*, Solaris-, SGI/Irix*, HP-UX-
	- MacOS-
	- Win32*
ports of GL4Java !
(* well done, - some platform specific problems, but under work)

Well, please do not make OS depended stuff - if possible.
Your application should run on all of our GL4Java platforms, right ?

So just try to minimize special native things,
and offer them (the native atoms) to the gl4java project - no problem !


> Virgil

Sven
-- 
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442