Greetings. In order for my application to (logic-layer wise) perform in the same manner independent of the system it is being run on I wish to better understand how to do timing in a jme3 application. Short version of current situation is as follows;
Using simple application. Locked FPS to monitor refresh rate (60Hz). Calculating time-per-frame using System.nanoTime(). simpleUpdate() handles all updates of scene graph actors. Multiple callable/runnable threads that do logic-layer calculations independent of main thread. Goal is to have everything synced to one common āclockā.
Specific questions;
What is the best practice when doing timing in the above situation?
How do I handle the above situation when unlocking FPS?
There should not be any difference in timing between fixed tpf and ārun as fast as possibleā as long as you already include tpf in your calculationsā¦
I think I understand what you mean but Iām not sureā¦ and alternate interpretations give wildly different answers. Can you better describe what you mean and why you are trying to do it?
@pspeed: Main thread runs capped at 60 fps. According to my own calculation using System.nanoTime(), each frame takes on average ~15 us to render. The tpf variable in simpleUpdate() reports a time per frame being roughly half of that ~8 us. Callable/Runnable threads run uncapped yielding variable results based on the host hardware.
I wish to have āfullā timing (same timing) control over both main thread and all callables/runnables but I am unsure of which method to use. What is the best practice? Way back in the day I used to program in assembler and used the timing of the analog monitor to sync the actions of the software to certain events such as audio. Right now I am looking for the most appropriate way of syncing the logical backend with the movement of actors in the scene graph, sound effects and music.
If you want me to explain in more detail please let me know. Thank you.
tpf shouldnāt vary so much from nanoTime() since it uses nanoTime() to calculate. So maybe there is something wrong with the code or with your test/assumptions.
Back in assembler, it was often the case that games would speed up and slow down with the speed of the computer (or with the frequency of the monitor). This is why the proper way is to base things on the time elapsed and not require such rigid frame timingā¦ youāll never get it anyway since we donāt run realtime operating systems.
So I have to believe your use-cases must be more malleable than that. If you really require lock-step synchronization between threads then cyclic barrier can be a way to do that. It forces either thread to wait on the otherā¦ though itās still no guarantee of 60 FPS (in fact depending on timings it can make it worse)ā¦ but they will definitely run one frame each at the same time. Itās such a rare use-case that this is required, thoughā¦ which was why I was curious as to use-cases.
It also sounds like maybe your front end and back end are coupled at too low of a levelā¦ or you have āViewā (as in MVC) slipping into your game logic too far.
Thank you for your lengthy reply. However I am not sure exactly what to make of it.
I have two projects that I would like to use jme3 in.
Primarily as an Android app which will process and present measurement data being communicated via Bluetooth from a Atmel-based built-in system i created. The external system requires a persistent connection with the host and that the transferred data is processed and presented in as close to real-time as possible.
Secondly and more of a pet project at this stage is a card game the likes of Hearthstone and Magic the Gathering; where I would like to have accurate timing of audio and networking features.
What would you have me read in order to better understand how to work with the model view controller concept in jme3? Any relevant links that can help me get started other than what is presented in the Tutorials & Docs section of this website?
So far all I have found is the page on Multi Threading (which in part contained outdated links) I am unable to find examples that use timing across multiple threads.
For the measurement system, some kind of background thread processing the data and posting it to a shared data structure is probably best. I donāt know if you need interpolation or whatever. They donāt really need to be lockstep, you just need to make sure that the shared data structure is thread safe (either volatile, AtomicWhatever, or [shudder] synchronized).
As to the other, it seems like conventional mechanisms would work. If you even need a background thread at all then it would enqueue commands for the rendering thread. At 60 FPS, a single frame is very small so you donāt really need to worry about perfect latency. Even a full frame delay for a card gameās sound is not going to be noticed.