Using StandardGame?

As much as we all love polls, I thought I'd make one to get some feedback about StandardGame.  Any constructive criticism about how useful it is/isn't as well as ideas about making it better are appreciated.

sorry df, I hit the poll and wasn't paying attention.  I thought this was referring to StandardGameState.



I don't use it b/c it has too many things I don't need.  Some are great, but IMHO, I don't use it b/c I want each portion to be in it's own class definition.  E.g. there can be only one camera at a time, so I use a CameraManager.  I don't need the FPS and other things, so I've taken BaseSimpleGame and made my own changes.  I'll go through StandardGame today and see what I notice.



sorry for dorking up your poll.



timo

It's okay, perhaps I'll just shut it down now that it's all "dorked up". :stuck_out_tongue:



The FPS thing is going to be removed…that was primarily for debugging in the first place and i just keep forgetting to delete it.

I'm using StandardGame because I don't know any better.  Also, it made it extremely easy to set up a fast demo application. shrugs

We're not allowed to vote twice!?  :?

I surely will try it, darkfrog. But before I have to understand all aspects of subclassing BaseGame.

Interested in how GameState develops, but there seam to be many issues with it.



What im working on requires so much memory, that having other states hanging around isnt viable. The last state needs to be completly cleaned up.


theprism said:

Interested in how GameState develops, but there seam to be many issues with it.

What im working on requires so much memory, that having other states hanging around isnt viable. The last state needs to be completly cleaned up.


What issues? To my knowledge there are no direct "issues" with GameStates.

Actually, I've found when well developed, using GameStates can provide much better memory management since when you are done with the GameState that contains various children you just remove it and null it and the whole thing becomes available for gc.  In the game I'm currently working on, I keep the main menu game state loaded but hidden when not in use.  The actual game states get removed when they are no longer in use which makes them available for gc so it keeps me from having to worry about explicitly removing things from my scene and dealing with all of that mess but gives me the efficiency to provide the menu without having to load anything again.  However, if you were particularly concerned about memory you could disregard the main menu as well and have it reload again.

How does it clean out textures ???

Well, the textures issue is an issue whether you're using GameStates or not.  With GameStates at least you might be able to create a cleanup() method to clean up the textures (there was a posting about that quite recently I believe) specifically for that state.  That will at least give you the benefit of separating it out.

One other thing im using is a timer object thats used insead of passing the float interpolation, this in its self interfaces a throttling mechanism so that if the JMEDesktop is in focus - its get a little more of the update portion. This aids in performance of scroll panes.


Interesting…if we were able to figure out a way to make StandardGame support you there is that the only reason you won't consider using it?

Hmmm, i also allow runtime editing so users can add new objects ( Nodes and models ) to the scene. This also takes the form of various widgets to show where the user can add things.



New players may join the scene - so that is also handled…



Its one of those things, I started to write the thread code before game states, what i do like is the effects built in - fade in and out, and if its not done then shoudnt be too much trouble to do a morph from one scene to the next.


Im sooo tempted to wrap textureManager to eliviate the issues, in essence, each node would have its on addition cache, ( just a refererence to each texture it uses ), it cached along with an int to indicate wether the texture should be cleaned up on being cleaned.

theprism said:

Hmmm, i also allow runtime editing so users can add new objects ( Nodes and models ) to the scene. This also takes the form of various widgets to show where the user can add things.

New players may join the scene - so that is also handled...

Its one of those things, I started to write the thread code before game states, what i do like is the effects built in - fade in and out, and if its not done then shoudnt be too much trouble to do a morph from one scene to the next.


All of that is supported in StandardGame now....in fact, I do a lot of that in my game already.  :P

Also, technically you can do ANYTHING in any thread you want if you use StandardGame with the addition of the lock() unlock() methods....the possibilities are endless...well....it can't make you breakfast in bed yet, but I'm still working on it. ;)
Also, technically you can do ANYTHING in any thread you want if you use StandardGame with the addition of the lock() unlock() methods


Can you eleborate more on this please, are you suggesting that lock makes it all thread safe ????

Well, the primary reason you encounter thread-safety issues in jME is because you have the OpenGL thread that is continuously updating while another thread is doing things.  Say if the game is cycling through elements in a scenegraph and half-way through that your other thread removes an item from that scenegraph.  That is a thread-safety issue because now the OpenGL thread thinks there are more elements in the scenegraph than there are and will throw an exception with the friendly ArrayIndexOutOfBoundsException.  With my new lock feature you don't have to worry about things like this.  If you're doing something that might cause thread-safety issues call game.lock() and the invoking thread will wait for the OpenGL thread to be "locked" (which means that when it hits the beginning of update() in the OpenGL thread it will stop processing until it is unlocked) and then will return control back to the thread.  The OpenGL will be stopped at a "safe place" so you can do any work you need to do (even invoke direct LWJGL calls if you like) and then when you invoke game.unlock() the OpenGL thread picks up where it left off and goes about its business and the invoking thread can continue with its own processing.  This is a good alternative for GameTaskQueueManager since you aren't creating any new objects, it's less cluttering, and the code is significantly more simplistic.  For operations that are dependent on something that must execute in the OpenGL thread this is a very good option.  However, I would still recommend using GameTaskQueueManager in most cases since it lets you "fire and forget" a task for situations where something must be done, but all you care about is that it happens eventually, not  that it happens right now.  That leads to better performance and consistency in your game when possible.

I've never dealt with multiple cameras at the same time.  Someone suggested earlier they had a CameraManager system that they used.  How useful would people find this to be a feature of StandardGame?



I am going to try to get some time to go through and clean up StandardGame a bit more and move out the FPS to a "FPSGameState" so it can be enabled or disabled based on an option.  Any other requests for while I'm working on this?


It's been 2days i'm trying to use StandardGame and GameStates.

Anoying things :

- Configuring it!
Most gameType use propertiesIO class for configuration,
standardGame use GameSettings...
why?

- how do we stop a GameState from being render?
(exemple : open the menu -> stop rendering the game)

- I use JMEDesktop,
I tried to add it as a node like basicGame
But i failed, so i used the JMEDesktpState.

Eclesia said:

- how do we stop a GameState from being render?
(exemple : open the menu -> stop rendering the game)


Disable it (using the state directly or the GameStateManager) or remove it from the GameStateManager.