GameTaskQueueManager use

Hey darkfrog, I read all your tutorials and stuff on GameTaskQueueManager and how to use it, but I've still got some questions. Right now I've got a few things I need to pass into the queue. (at least, when I try these tasks outside the opengl thread stuff messes up) To do this passing I've created classes dedicated to being put in the queue and doing specific tasks.

Basically, one of these classes would take in whatever objects it is effecting in the constructor. Then it gets passed to the TaskQueue where it does whatever it should on those objects. But, I've got a lot of common task classes that get sent to the Queue. Things like "CreateTextureState", or "MoveCamera", etc. It seems that it would be much easier (for us at least, not for you ;)) if for all really common tasks there was simply a method in StandardGame that would take care of it by internally working with the GameTaskQueueManager. This would also help others with the fact that currently we ALL have to identify (individually) what commands are OpenGL thread dependent and what aren't.

Perhaps, the jME team should consider creating a util class dedicated to these common tasks…

I was also wondering if there was an effort going to list all the commands that require the OGL thread? It would be really useful to have a reference of that sort instead of building one up myself (not that I'm completely averse to the idea of doing that, but…  :-o yeah…).

Wow, I've rambled… I started this thread with the intention of asking you if this dedicated Callable class system was the kind of system you are using. I just can't see a good way of getting these OpenGL things done without them. Especially since you can't send in non-final Objects without using that class.

Well, the intention to handle this easier was with StandardGame's lock/unlock methods, but there's a problem with it in that it only works for certain things.  I'm exploring ways to make this work better because it is MUCH easier than creating a Callable since you can just call game.lock() before you start doing that work and then game.unlock() when you're done.

We definitely need to evaluate how to better inform developers about what has to be done in the OpenGL thread, it just hasn't been done yet.  If you wanted to take on that task I'm sure it would likely get done before it would otherwise be accomplished.

Note though that there are quite a few things in jME you can do outside of the OpenGL thread and it might just be that because you are either not updating properly or can't concurrently be modifying the scene-graph that it is causing problems.