Question about TransitionGameState and game design

I have been looking lately into the TransitionGameState and liked it a lot. However there is a small problem I would like some advice on.



I have the normal set-up of StandardGame initialized in the Main class and additional methods in the Main class that do the switching between different gamestates (gotoMenu, gotoGame etc.). I am using the TransitionGameState to fade from one gamestate to another. So - if I want to switch from GamestateA to GamestateB, then inside GamestateA I call Main.switchToGamestateB. And there will be a faded transition from A to B.



However the problem is that GamestateA remains completely visible until the command has finished - until GamestateB has already been completely loaded. And only then does a very quick fade in. Which beats the purpose of having a loadingscreen.



I realize it is a threading issue - I changed my code so that the command Main.switchToGamestateB is launched in a separate thread and now it works as I want it to - when I call switchToGamestateB() a new thread is created that enables the TransitionGameState. The thread is started and command finishes immediately. Nice loading bar is visible while GamestateB loads.



However I am not happy - it looks ugly. How should I do this kind of stuff with StandardGame? The examples I have seen, have put the commands in the Main class as I did - but I guess there are drawbacks to this… Do you have any advice on how I could better structure my code in this regard, or would you say the current setup is good enough?


I’ve actually moved away from managing threads at all in my code these days.  I have an open-source project I’ve been developing called xjava (http://xjava.googlecode.com) that has a class called ThreadManager that you simply give “WorkUnits” to and it sees that they are done at some point in the future.  This is similar to worker threads that are commonly used but goes way beyond it by providing the ability to lock on a specific object related to the work unit (so if another unit of work that references the same object it will not be invoked until the currently running one is finished), timeouts on work so they are interrupted if they take too long, scalability to allow scaling up and scaling back down when there is peak periods, work priority so some units will occur at a faster rate than another, delayed work to allow scheduling work to occur in the future.



I’m planning on using this in game development in the future, but for now it works very well for normal business coding as I don’t have to think about how many threads there are or managing them, but rather defining my code in units of work that get accomplished.



There’s also some really cool other features in xjava that might be appealing to game development as well. :wink:

Sounds very promising… I will certainly check it out and try to make use of it if it is really all that you promise…