I am just starting out using jME. I am just playing around with it now to get experience and figure out its structure and design.
In BaseGame.java, I noticed that the render call comes after the update call. Would it be better to have it the other way around? That is, send the data to video card (render), and then update the game state while it draws?
Cool engine, btw. 8)
That is, send the data to video card (render), and then update the game state while it draws
Jme is a single threaded engine. What your asking is to have two threads, a render thread and an update thread. And when engines becomes multi-threaded, they become complicated. Just have a look at Java3D and how that turned out...
I mean there is no reason for you not to have another thread doing the updating of everything and keeping the update method in basegame empty, but that would require you to implement and live with the headaches ;)
Hope that helps!
Hmm, I didnt mean multi-threading.
What I meant is (and Im not sure about this), if we send the data out to the card, then do the update, then while the card is drawing we will be updating our game state. So both the GPU and the CPU will be working on their data.
But now that I think about it, does the order of execution really matter?
render() - GPU starts drawing stuff
update() - CPU updates stuff while GPU is drawing stuff
update() - CPU updates stuff
render() - GPU waits on CPU, then starts drawing after
But now Im wondering whether going either way helps since after the data is sent to the GPU, the loop goes to the next iteration anyway.
I dont believe it matters as all jme does is send data down to opengl and it does all its internal stuff. So in reality, both the GPU and the CPU are being used at the same time…
The original logic behind the update() -> render() structure is that an application would first update its state, then that new state would be rendered by the engine.
In the end, as you noted, the loop structure means its mostly irrelevant if update() or render() gets called first.