Using 2 Window GUI method
by Eric Sapp · in Torque 2D Beginner · 02/12/2013 (5:34 pm) · 9 replies
In 1.5, I created a 2nd window & scene to be the GUI. This doesn't seem to work on Torque 2D now.
Has this been deprecated?
Thanks for your help.
-Eric
Has this been deprecated?
Thanks for your help.
-Eric
About the author
#2
02/13/2013 (4:49 am)
@Eric - As Richard stated, that still works. Can you post the code you are using? Additionally, it might help to explain why you want a 2nd SceneWindow.
#3
02/13/2013 (12:10 pm)
Keep in mind one of the main reasons to use a second SceneWindow in the old tech was to use sprites for a nicer GUI. You don't have to do this anymore for Torque 2D MIT. Check out GuiSpriteCtrl and GuiImageButtonCtrl. These both use assets and can provide really nice GUIs without having to create a SceneWindow.
#4
Main reason for using this method is I need the GUI elements to move around and be draggable. If those two GUI objects can move then I'll convert. I also need a separate Window since my camera changes pos/zoom during the course of the game.
Thanks,
Eric
02/13/2013 (12:32 pm)
I'll have to post the code tonight, but I couldn't get both windows and scenes to show up. Only the last one loaded would display.Main reason for using this method is I need the GUI elements to move around and be draggable. If those two GUI objects can move then I'll convert. I also need a separate Window since my camera changes pos/zoom during the course of the game.
Thanks,
Eric
#5
02/13/2013 (12:42 pm)
Ah, in that case you will probably still want to use a SceneWindow then. Advanced interaction is not a strong point for the Torque GUI system. I'll wait to see your code. 
#6
02/13/2013 (1:15 pm)
I know once behaviors were introduced in TGB, there were examples of behaviors that enabled sprites or scene objects to be used as GUI elements (having drag-able things is no problem) . I see nothing stopping us from continuing that in the MIT release, but are there any specific benefits to using the Torque GUI system over scene objects?
#7
That decision is no longer up to us, though. It would have to be a steering committee and community decision.
02/13/2013 (1:30 pm)
@Mike - Currently? The only edge the GUI system has over the Sprite system is the number of controls it has, such as a slider or PopUpMenu. Honestly, Melv and I have talked about ripping the GUI system out entirely. With a little extra effort, you can replicate all of the GUI controls using the Sprite system. We just did not have time to put all those examples together. We could replace the entire Sandbox GUI with sprites and scenes if we had the time.That decision is no longer up to us, though. It would have to be a steering committee and community decision.
#8
02/13/2013 (10:23 pm)
Aw, gui elements can be dragged - that's how the Three Step animation editor worked. It is a bit more work than the scene window method though.... And the gui system can't use particle systems as it is now.
#9
If I wanted to build, say, a sprite-based multiline text area control what would be a good starting point?
02/15/2013 (11:28 am)
Going off on a tangent here but how would a sprite-based UI handle more advanced controls (things like input fields, multline text areas, etc.)? In the legacy tech you could get some basic UI controls working fairly easily (buttons, checkboxes, text labels) but constructing more advanced controls out of scene objects was typically more trouble than it was worth. You'd often end up with this weird, unwieldy mixture of sprites and default GUIs. Has this changed in the new tech?If I wanted to build, say, a sprite-based multiline text area control what would be a good starting point?
Torque Owner Richard Ranft
Roostertail Games