State Manager

UrsaMajor · Post by **UrsaMajor** » Fri Mar 11, 2011 8:05 pm

Hi all,

I've problem with projecting of State Manager. Should I use a different Scene Manager for each state? Earlier I use one Scene Manager and when I was changing states I was setting Visible = false; for each Scene Node used in previous state. What do you think about it? Thanks for answers and sorry for my english

randomMesh · Post by **randomMesh** » Fri Mar 11, 2011 8:36 pm

UrsaMajor wrote:Hi all,

I've problem with projecting of State Manager. Should I use a different Scene Manager for each state? Earlier I use one Scene Manager and when I was changing states I was setting Visible = false; for each Scene Node used in previous state. What do you think about it? Thanks for answers and sorry for my english

The one by vitek works very well.

serengeor · Post by **serengeor** » Fri Mar 11, 2011 9:45 pm

UrsaMajor wrote:Hi all,
... I was setting Visible = false; for each Scene Node used in previous state. What do you think about it?

Do you need your nodes to stay in the manager for later use or what? I would clean up the scene. tough if you need them to stay there, than I guess its ok, as long as you know what you're doing.

UrsaMajor · Post by **UrsaMajor** » Sat Mar 12, 2011 1:45 pm

Do you need your nodes to stay in the manager for later use or what?

Yes, I need them because when I change state from Level to Menu and then from Menu to Level I don't want reload them.

sudi · Post by **sudi** » Sat Mar 12, 2011 1:57 pm

well you could make that way simpler. just create a "state" node which is basicly just an empty scenenode and use that node as root for all the nodes in a specific state. when you than change the state just call remove on that state node. and all nodes will not be rendered nor processed. When you than come back to the state just call setParent(SceneManager->getRootSceneNode()) on the state node.

of course you will have to grab the state node otherwise it will be deleted on remove.

serengeor · Post by **serengeor** » Sat Mar 12, 2011 2:01 pm

UrsaMajor wrote:
Do you need your nodes to stay in the manager for later use or what?
Yes, I need them because when I change state from Level to Menu and then from Menu to Level I don't want reload them.

I had the same problem, I think it would be better to have menu in the same state. Tough I don't really know what your project configuration is, so its better to decide on your own how to do this.

Sudi wrote:well you could make that way simpler. just create a "state" node which is basicly just an empty scenenode and use that node as root for all the nodes in a specific state. when you than change the state just call remove on that state node. and all nodes will not be rendered nor processed. When you than come back to the state just call setParent(SceneManager->getRootSceneNode()) on the state node.

of course you will have to grab the state node otherwise it will be deleted on remove.

Erm, yeah lets hack irrlicht to do all the game engine job.

sudi · Post by **sudi** » Sat Mar 12, 2011 2:06 pm

Actually that is not hacking the system its using the nature of a tree system...

serengeor · Post by **serengeor** » Sat Mar 12, 2011 2:14 pm

Now how about loading/unloading resources for every state?

sudi · Post by **sudi** » Sat Mar 12, 2011 2:20 pm

Well that depends is the state actually left/closed? or is just put to sleep/backround?

if its closed sure delete all resources. but if it is just sleeping like your game is running and you open the ingame menu which actually should be a different state. then gamestate is just sitting in the background maybe even still running and waiting to be top state again.

serengeor · Post by **serengeor** » Sat Mar 12, 2011 2:28 pm

For me it looks like using a rock to do a hammer job

Mikhail9 · Post by **Mikhail9** » Sat Mar 12, 2011 8:51 pm

Sudi's method makes perfect sense for any case where you are going to go back to the state you just left, picking up exactly where you left off. This is common in games where you might hit ESC and go into a menu screen, then return to the game.

On top of that, it's highly efficient because you just pull the empty "state" root node out of the scene graph. It doesn't consume processing resources because it doesn't get touched by the scene manager during updates. And you don't wait forever for your assets to reload when you want to go back.

Of course, if you don't need those resources anymore at all, you would choose to remove that "state" node permanently, or destroy the scene manager and create a new one.

It depends on the application.

serengeor · Post by **serengeor** » Sat Mar 12, 2011 9:01 pm

Mikhail9 wrote:Sudi's method makes perfect sense for any case where you are going to go back to the state you just left, picking up exactly where you left off. This is common in games where you might hit ESC and go into a menu screen, then return to the game.

You can also do that by just making the menu appear in the same state, thus you can have your objects visible. And making node invisible won't stop physics from not updating, unless using irrlicht animators, or doning checks if the root node is visible, but it looks way too unorganized.

sudi · Post by **sudi** » Sat Mar 12, 2011 9:23 pm

serengeor wrote: You can also do that by just making the menu appear in the same state, thus you can have your objects visible. And making node invisible won't stop physics from not updating, unless using irrlicht animators, or doning checks if the root node is visible, but it looks way too unorganized.

Making a menu in the same state as the game is actually pretty messy and unorganized. A menu is obviously a state so it deserves it own state with its own vars etc.
Besides we talked about irrlicht and not physics when you want to disable physics just don't call the physics update function while the game state is not active...simple right

serengeor · Post by **serengeor** » Sun Mar 13, 2011 9:07 am

Sudi wrote: Making a menu in the same state as the game is actually pretty messy and unorganized. A menu is obviously a state so it deserves it own state with its own vars etc.
Besides we talked about irrlicht and not physics when you want to disable physics just don't call the physics update function while the game state is not active...simple right

Messy eh? And Making entities do the game framework job is not messy ? ok..
And by talking about menu, I was thinking of pause menu, and not many games really allow you to enter the main menu without quiting your game state.

UrsaMajor · Post by **UrsaMajor** » Sun Mar 13, 2011 9:28 am

well you could make that way simpler. just create a "state" node which is basicly just an empty scenenode and use that node as root for all the nodes in a specific state. when you than change the state just call remove on that state node. and all nodes will not be rendered nor processed. When you than come back to the state just call setParent(SceneManager->getRootSceneNode()) on the state node.

of course you will have to grab the state node otherwise it will be deleted on remove.

It looks pretty good.

Thanks.
And I have another question. I want make a simple transitions. I made a texture(rectangle 640x480 - for my default resolution) with half-transparent borders. It works good for 640x480, but when I change resolution, texture have the same resolution. How can I change resolution of this texture? I wrote this:

Code: Select all

	video::SMaterial material;
	material.setTexture(0,texture);
	core::matrix4 matrix = material.getTextureMatrix(0);
	matrix.setTextureScale(2.1f,2.0f);
	material.setTextureMatrix(0,matrix);
	texture = material.getTexture(0);

But, It doesn't work at all. Any ideas?

//EDIT: I managed to do that. I used gui::IGUIImage instead of video::ITexture. Here is the link for property usage of SetAlingment if someone have the same problem: http://irrlicht.sourceforge.net/phpBB2/ ... scaleimage

Irrlicht Engine

State Manager

State Manager

Re: State Manager

Re: State Manager