at the moment I placed the following line in my simpleUpdate() method - extending the SimpleCanvasImpl class:
Thread.currentThread().setPriority(Thread.MIN_PRIORITY);
Latest approach ( and sun reccomendation ) is to leave thread priorities alone and use a queue based approach which has throttling.
this isnt to say however that all the threads in your game are not bumped up to more than normal, its just to keep them the same priority otherwise there is no guarantee as to when lower priority ones get called ( if at all )
I suppose in a game the only throttling you can do is limit the framerate. Have you considered that? Or is there a particular reason why you need to set priority on the thread?
thanks, is there an example how to realize this using jmonkey? I can hardly imagine how to do this using jmonkey…
You can also have several threads doing different things eg background loading of files, networking, constructing of meshes and the main lwjgl thread
the problem limiting the framerate is that this also slows down my swing GUI… that sounds odd, but if I limit the framerate to 1, my whole application is almost unusable… if I set the framerate higher, the whole application runs smoother, but consumes more cpu load… putting all this effects together, there would be a ideal framerate setting for each computer. The thing is: the 3d Rendering is way not that important as the swing GUI is. If I render just 2 times a second, if the computer is slow - I don't care, as long as the gui is smooth to use.
So far, what I really want is a higher priority for handling gui events and processing data than for the rendering and the 3d view. That;s why I started to change the thread priority - but at least, setting the thread priority in every render loop seems like a complete fail… I hope this makes thing a little clearer…
A vdu runs at 60hz or more, A hertz is a cycle a second, so you want your framerate to at least equal the vdu hertz. If you have logic that is dependant on running faster - its should not be dependant on how often the graphics are drawn.
hmm, what I guess is that limiting the framerate also slows down the awt.eventDispatch thread. therefore the GUI starts to react slower to user actions when the framerate is set too low. can anyone confirm that?
3dAwt said:
hmm, what I guess is that limiting the framerate also slows down the awt.eventDispatch thread. therefore the GUI starts to react slower to user actions when the framerate is set too low. can anyone confirm that?
Swing in jme in my opinion is a genious effort to take it wher it is. Unfortunately sun havent delivered on a decent Ui system, Crikey - the standard layout mnagers speak for themselves.
IMHO you cannot rely on catching user actions within a limited timeframe within swing …
yeah - I'm using a canvas… like it is done in the jmetest.util.JMESwingTest
using JME 2 this works a lot better as in JME1, but the problem still is, that adding more content to the scene graph slows down my GUI more and more because the framerate gets to low…
is there a way to use an independent render thread, which doesn't depend on the GUI and still embed everythin into a swing frame?
You need to be able to control how often the scene graph is rendered. In your render method, you get a TPF value, add that to some counter until it reaches 1, then reset it to 0 and render a frame. This way you only limit your scene graph rendering to 1 frame/sec while everything else is updated at full speed.
thanks, that helped…
another question… does jme still use 3d acceleration of my graphic card, when using a canvas in an swing environment? the whole rendering process is getting so slow, even though I just use basic boxes without any material states or textures at the moment…
Yes, jME uses full hardware acceleration in canvas or display always. You don't need super shaders or effects to slow down rendering… How many boxes are you rendering? You might want to consider batching if there's a whole lot of them.
it should be about 200 to 300…
what do I need to do in order to use batching?