Of course in an appstate, you have access to the parent application via “this.app”, but I find myself needing to pass application references to controls a lot of the time.
Say I’m making a weapon with a sprite attached to the guiNode, Doom style. Well, I’d create a picture node and then add the WeaponControl to it, which I would use to attach it to the application’s guiNode. Well, that means having to pass a reference to the guiNode to the constructor. Sure, that’s fine, but I also need to get the width and height of the window for proper positioning… that’s three app fields that I need just for this control. Thus, it makes sense just to pass a reference to the application.
But, somehow that doesn’t feel right. Should I really be passing the entire application to each one of my controls? That seems like overkill. Passing references to each field that I need doesn’t seem any better. Is this just common practice or am I doing something wrong?
I don’t know, I just like to move as much code as I can out of the appstate so I don’t have to keep track of what I do with each instance as much. I’m operating on the assumption that controls are what you use to do things to spatials.
@FrobtheBuilder said:
I don't know, I just like to move as much code as I can out of the appstate so I don't have to keep track of what I do with each instance as much. I'm operating on the assumption that controls are what you use to do things to spatials.
Yes, but having it attach the spatial to its parent seems a little farfetched. Like asking the wagon to hitch itself to the horse.
In general, scene setup should be external and the control should modify the spatial to which its attached (or its children). That way you could decide to attach it to something else later without having to hunt down all of the controls that might be attaching it somewhere.
guiNode.attachChild(picture);
picture.addControl(yourControl);
This one “but I also need to get the width and height of the window for proper positioning”… is also little strange. Are you sure you need this?
Maybe what you really want is an app state in this case and not a control. If this is a HUD element, that’s quite common.
@pspeed said:
Yes, but having it attach the spatial to its parent seems a little farfetched. Like asking the wagon to hitch itself to the horse.
In general, scene setup should be external and the control should modify the spatial to which its attached (or its children). That way you could decide to attach it to something else later without having to hunt down all of the controls that might be attaching it somewhere.
guiNode.attachChild(picture);
picture.addControl(yourControl);
This one “but I also need to get the width and height of the window for proper positioning”… is also little strange. Are you sure you need this?
Maybe what you really want is an app state in this case and not a control. If this is a HUD element, that’s quite common.
Okay, that makes sense.
But it seems strange to have a weapon be an appstate. I guess it would make sense to put everything that needs to be drawn as GUI in one, though. I’ll try that.
I’d add that in complex situations I found it pretty useful not to pass the app instance or asset man instance or whatever all around, but just make a singletone with all the fields static, holding these props. Yes, it somewhat breaks the “good” way, but for some apps (which were not really games though), I found just hacking around all this Java “private” stuff very useful!
@pspeed said:
Yes, but having it attach the spatial to its parent seems a little farfetched. Like asking the wagon to hitch itself to the horse.
I have a control that attaches its spatial to the parents. It extends my particle controller and removes the particle spatial from the scene graph once every particle is inactive - then as soon as you activate a particle it adds itself back again.
@zarch said:
I have a control that attaches its spatial to the parents. It extends my particle controller and removes the particle spatial from the scene graph once every particle is inactive - then as soon as you activate a particle it adds itself back again.
Is your control on the particle system or on the parent of the particle system? (I’d hope the latter… which is all the difference in this case.)
Wouldn’t be much point removing it otherwise as half the reason to remove it is to stop it needing to call the control update every frame. (the other part of the reason being to stop the system having to process the particle mesh every frame).
I’m open to alternative solutions but this is simple and works.
Wouldn’t be much point removing it otherwise as half the reason to remove it is to stop it needing to call the control update every frame. (the other part of the reason being to stop the system having to process the particle mesh every frame).
I’m open to alternative solutions but this is simple and works.
So, you add a control to the particle system that’s job is to attach the particle system to some other node… thus you must pass that node to the control that you add to the particle system.
Someone has a reference to something to get it to start again… because if you remove the particle system from the parent all normal references go away. I don’t know what that something can’t simply add and remove the control as needed. Just seems a little backwards to me.
someNode.addControl( new ParticleControl() );
Versus:
ParticleControl pc = new ParticleControl(someNodeThatIsDifferentThanTheOneTheControlWillBeAttachedTo);
pc.startItUp();