Hi!
Sorry I am new to all of this never really used JOGL before but I've been looking through several examples of how to set up things typically but I have noticed that everyone mentions how NEWT is the faster way to do things. However I really struggle to find anything about it and how it works / what it is / how you typically lay out things - like what does it even require? How does it render? What is a typical loop? Does anyone have any fairly decent docs for it? OR a tutorial showing the ideal way to create a window and then set up a render loop for it and accept user input? Hope I've not missed anything obvious that could help me but I see other people have had the same issue with the lack of available material. Kind regards, iexus. |
Administrator
|
I'm not sure if the docs or tutorial are ready yet... I guess Sven will have to answer that However, you might look at the NEWT tests at https://github.com/sgothel/jogl/tree/master/src/test/com/jogamp/opengl/test/junit/newt to see if there's something similar to what you want to do.
|
Thanks I will give those a peruse! I hadn't realised NEWT was on the bleeding edge of being made :D
|
Administrator
|
For an example of how to get a NEWT window for rendering up and running with keylisteners attached u can take a look at my Github repository:
https://github.com/demoscenepassivist/SocialCoding/blob/master/code_demos_jogamp/src/framework/base/BaseGlobalEnvironment.java#L83 API wise NEWT isn't really different from using JOGL with AWT. Generally it's easy to migrate code from AWT/GLCanvas to NEWT. Just a few search'n'replace operations and ur good to go. For a "cross reference" example of nearly the same JOGL window setup using the good old AWT u can take a look here: https://github.com/demoscenepassivist/SocialCoding/blob/master/code_demos_jogamp/src/framework/base/BaseGlobalEnvironment.java#L373 |
Thank you I will give all of those a look!
One question I did have about using an Animator... I tried using an FPSAnimator and a simple GLCanvas (walk before you run :D) however when I set the FPS to 60 .. it seemed to run at 125 ish. I do my timings using System.nanoTime(); and have done in all the thing I make in Java so I am a little confused. I then saw somewhere that using FPSAnimator was not recommended as it behaves differently on windows / linux and can have drift / innacurate results. Is this true? In which case do I simply enforce my own timings using Animator and thread.sleep(); methods on animator? If so, then what is the point of animator? It just seems to be a thread that ticks and calls display ... although I guess it is creating GLEvents? Could I not simply not use the Animator and instead write a simpler Thread class with my own timings? Unsure if animator provides any other functionality and how people acheive accurate frame rates. |
Administrator
|
>I then saw somewhere that using FPSAnimator was not recommended
> as it behaves differently on windows / linux and can have drift / innacurate results. Is this true? I only have experience with the FPSAnimator on Windows XP/Vista/7 and its works ok'isch there. The timing difference/inaccuracy is ~20ms wich is ~1-2 frames if u assume 60 frames per second. So its ok but not perfect. I would recommend using Animator in conjunction with v-sync to get accurate timings for ur rendering and only use FPSAnimator as a fallback, when v-sync is not available on the platform. The code snippet I referred to in my previous posting contains code for both methods (vsync+fpsanimator). >In which case do I simply enforce my own timings using Animator and thread.sleep(); >methods on animator? If so, then what is the point of animator? It just seems to be a >thread that ticks and calls display ... although I guess it is creating GLEvents? Could I >not simply not use the Animator and instead write a simpler Thread class with my >own timings? I would not recommend using a "custom" thread for ur display() loop as there are some subtle multithreading issues involved when calling methods on a GLAutoDrawable. So better leave the threading stuff to the JOGL helper classes or be 120% sure u know what u do |
Administrator
|
In reply to this post by iexus
On Wednesday, December 29, 2010 00:29:48 iexus [via jogamp] wrote:
> > Thanks I will give those a peruse! I hadn't realised NEWT was on the bleeding > edge of being made :D > Well, actually we have more test for NEWT than for AWT. NEWT is also more stable than AWT due to it's concept and implementation details, which is far 'easier' and has much less complications and sideffects than AWT. But since I like the expression 'bleeding edge' I won't argue it :) ~Sven |
Administrator
|
In reply to this post by Demoscene Passivist
On Thursday, December 30, 2010 00:23:57 Demoscene Passivist [via jogamp] wrote:
> > >I then saw somewhere that using FPSAnimator was not recommended > > as it behaves differently on windows / linux and can have drift / > > innacurate results. Is this true? > > I only have experience with the FPSAnimator on Windows XP/Vista/7 and its > works ok'isch there. The timing difference/inaccuracy is ~20ms wich is ~1-2 > frames if u assume 60 frames per second. So its ok but not perfect. > > I would recommend using Animator in conjunction with v-sync to get accurate > timings for ur rendering and only use FPSAnimator as a fallback, when v-sync > is not available on the platform. Exactly. If you don't want to render every frame, than you can toggle every other frame etc using the set swap buffer interval method (see the Gears example in the unit tests). Only with vsync you are guaranteed to have correct timings anyways. > > The code snippet I referred to in my previous posting contains code for both > methods (vsync+fpsanimator). > > >In which case do I simply enforce my own timings using Animator and > thread.sleep(); > >methods on animator? If so, then what is the point of animator? It just > seems to be a > >thread that ticks and calls display ... although I guess it is creating > GLEvents? Could I > >not simply not use the Animator and instead write a simpler Thread class > with my > >own timings? > > I would not recommend using a "custom" thread for ur display() loop as there > are some subtle multithreading issues involved when calling methods on a > GLAutoDrawable. So better leave the threading stuff to the JOGL helper > classes or be 120% sure u know what u do If neither animator suits you, feel free to implement your own GLAnimatorControl implementation. This would allow seamless integration of your custom animator thread to the GLAutoDrawable lifecycle. ~Sven |
Free forum by Nabble | Edit this page |