Understanding the chathud.gui
by Flybynight Studios · in Torque Game Engine · 12/16/2006 (3:02 pm) · 5 replies
I've been working with Torque for over 2 years now. I've developed (with alot of help) an MMO sub-system based on Torque. I've got a server farm of 6 systems all talking to each other with zone servers/ auth servers and patch servers.... BUT I STILL CANT FIGURE OUT THE chathud.gui!! ;)
So I decided this weekend would be the end of the darkness. I want to compile everyones feedback and knowledge on the chat HUD system, hell just the GUI system in general, and write a clear and well documented resource on it and post it to the community.
This isnt just for the chat screen btw, this allows for complex gui manipulation of any kinds of custom GUIs you want to implement in the future.
First: Changing the Chathudborderarray.PNG
There is alot of stuff going on in the array graphic that the average person might not catch at first. It is described in detail here:
http://www.garagegames.com/mg/forums/result.thread.php?qt=13808
And a better base PNG example to work off of is given here: http://www.mogshade.com/torque/sample/border_05.psd
PS: if this link ever breaks I can make the file avail.
Short description of how the borderarray is parsed: (To the best of my limited understanding)
The PNG file is scanned by the Torque engine from left to right Looking for a pixel breaks to define the border elements. The border elements are broken down as follows:
Top Left | Top Right | Top Middle
Left | Right | Bottom Left | Bottom Middle | Bottom Right
I dont understand completely how the parsing works but suffice to say there is a background layer (that appears to be 255,0,0 (red) that must be present or the parse will crash the engine. This can not be off even a single color degree (IE it can not be 254,0,0). Therefore when building your borderarrays always use new layers for the elements and masking so your artwork doesnt bleed into the background or the alpha channel..
Alpha channel *sigh* another I dont understand well but what I do know is that it is also used somehow during the parsing and to make matters even more complex, alot of graphics software saves PNGs differently when it comes to alpha chans etc.. Read the first link above for more specifics on this and there are instruction in that thread for most of the mainstream graphics apps including Photoshop, photopaint, Gimp and Corel. PLEASE NOTE: Alot of those applets will NOT save your PNG the way Torque expents it for the border array to parse correctly without crashign your engine. Please read the entire thread for specifics on that.
Step 2: Ok cool I have a custom border array. How do I manipulate the actual GUI implementation?
(Caveat: Some of this I am starting to understand but a lot more I do not so please please add your input to this thread if there is anything I have not explained or am missing)
The ChatHud.GUI file should be under your UI folder. (I have an entirely custom folder structure so do a search if you can't find it.) What I dont understand is the structure of the GUI.
Why is there a top part tagged:
//----------------------------------
// Chat edit window
//----------------------------------
And why is there a bottom part called Object write begin? I do not understand why these are seperated and not just have a bunch of child objects off the parent..
Also, the file MessageHud.CS is the control script for the Popup box when you type in chat.. This is somehow binding itself (through the messageHud_Frame.position call) to the chathudGUI but when I move chat hud GUI it doesnt move the popup box for entering new text...
If someone could assist in breaking down the chathudGUI (As I noted above) I'm sure we could get some clearly defined ways to handle the rest of it.
Thanks in advance for contributing.
Mark
So I decided this weekend would be the end of the darkness. I want to compile everyones feedback and knowledge on the chat HUD system, hell just the GUI system in general, and write a clear and well documented resource on it and post it to the community.
This isnt just for the chat screen btw, this allows for complex gui manipulation of any kinds of custom GUIs you want to implement in the future.
First: Changing the Chathudborderarray.PNG
There is alot of stuff going on in the array graphic that the average person might not catch at first. It is described in detail here:
http://www.garagegames.com/mg/forums/result.thread.php?qt=13808
And a better base PNG example to work off of is given here: http://www.mogshade.com/torque/sample/border_05.psd
PS: if this link ever breaks I can make the file avail.
Short description of how the borderarray is parsed: (To the best of my limited understanding)
The PNG file is scanned by the Torque engine from left to right Looking for a pixel breaks to define the border elements. The border elements are broken down as follows:
Top Left | Top Right | Top Middle
Left | Right | Bottom Left | Bottom Middle | Bottom Right
I dont understand completely how the parsing works but suffice to say there is a background layer (that appears to be 255,0,0 (red) that must be present or the parse will crash the engine. This can not be off even a single color degree (IE it can not be 254,0,0). Therefore when building your borderarrays always use new layers for the elements and masking so your artwork doesnt bleed into the background or the alpha channel..
Alpha channel *sigh* another I dont understand well but what I do know is that it is also used somehow during the parsing and to make matters even more complex, alot of graphics software saves PNGs differently when it comes to alpha chans etc.. Read the first link above for more specifics on this and there are instruction in that thread for most of the mainstream graphics apps including Photoshop, photopaint, Gimp and Corel. PLEASE NOTE: Alot of those applets will NOT save your PNG the way Torque expents it for the border array to parse correctly without crashign your engine. Please read the entire thread for specifics on that.
Step 2: Ok cool I have a custom border array. How do I manipulate the actual GUI implementation?
(Caveat: Some of this I am starting to understand but a lot more I do not so please please add your input to this thread if there is anything I have not explained or am missing)
The ChatHud.GUI file should be under your UI folder. (I have an entirely custom folder structure so do a search if you can't find it.) What I dont understand is the structure of the GUI.
Why is there a top part tagged:
//----------------------------------
// Chat edit window
//----------------------------------
And why is there a bottom part called Object write begin? I do not understand why these are seperated and not just have a bunch of child objects off the parent..
Also, the file MessageHud.CS is the control script for the Popup box when you type in chat.. This is somehow binding itself (through the messageHud_Frame.position call) to the chathudGUI but when I move chat hud GUI it doesnt move the popup box for entering new text...
If someone could assist in breaking down the chathudGUI (As I noted above) I'm sure we could get some clearly defined ways to handle the rest of it.
Thanks in advance for contributing.
Mark
#2
http://www.garagegames.com/mg/forums/result.thread.php?qt=25885
12/17/2006 (12:18 am)
Not much.. but it's a starthttp://www.garagegames.com/mg/forums/result.thread.php?qt=25885
#3
Thanks for taking on this challenging topic. :-)
12/17/2006 (7:06 am)
Ken Finney explains some aspects of the chat hud, namely, how to make a new graphic for it, I think Ed Maurina explains a little about it in his book as well. I'd help you, but have no clue how it works.Thanks for taking on this challenging topic. :-)
#4
Maybe I was absent the day this was discussed (read: I can't find this mentioned on the forums) but I think it's pretty important to note and it helped me alot.
I think most people working with the GUIs know that the top layer parent object in the GUI scales to the actual resolution the client is running in.
Example: Please note the bold part below. Although the GUI will scale based on what the client screen pref is set to, the 'extent=' part of the GUI is the resolution that the child object position and extents will be based on. The engine will try to make it's "best guess" at resizing the GUI on the fly.
Because the above code is the top parent object of that GUI file, it sets the video layer properties. Let me clarify. The position and extent statments are basically making a screenwide, modeless video "layer" of 800 by 600 starting at position 0,0 (x,y) in the upper left hand corner of the screen that the child objects will be inserted into. (Note: I am fooling around with partial screen layers but I don't want to say anything about them yet as I'm having some goofy positioning problems with them I havent nailed down yet.)
It's important to note here that changing resolution (as I'm sure most of us have experienced) can result in the frustrating destruction of the GUIs in so much as nothing lines up anymore, but fiddling around with the horizsizing and vertsizing as well as the base parent resolution can assist with correcting that.
Because my own application that I'm building GUIs for is fairly extensive and contains a lot of obecjts in it I require alot of precision in the placement and unfortunately for me I havent figured out yet exactly how to stop the engine from auto-scaling the elements of the GUI.. What I am going to do for now is lock the client rez at 1024 and leave it there. Build my gui based on 1024 and try and work on mastering the resizing later.
That said, most games people are working on will want to be able to flip resolutions so hopefully someone will have some more help to offer on that subject =).
Hope this makes sense I'm still groggy from last night ;)
12/19/2006 (9:54 am)
Just wanted to update this:Maybe I was absent the day this was discussed (read: I can't find this mentioned on the forums) but I think it's pretty important to note and it helped me alot.
I think most people working with the GUIs know that the top layer parent object in the GUI scales to the actual resolution the client is running in.
Example: Please note the bold part below. Although the GUI will scale based on what the client screen pref is set to, the 'extent=' part of the GUI is the resolution that the child object position and extents will be based on. The engine will try to make it's "best guess" at resizing the GUI on the fly.
new GuiControl(MainChatHud)
{
profile = "GuiModelessDialogProfile";
horizSizing = "width";
vertSizing = "height";
position = "0 0";
[b]extent = "800 600";[/b]
minExtent = "8 8";
visible = "1";
helpTag = "0";
noCursor = "1";
new GuiControl()
{
profile = "GuiDefaultProfile";
horizSizing = "width";
vertSizing = "height";
etc etc etc.....Because the above code is the top parent object of that GUI file, it sets the video layer properties. Let me clarify. The position and extent statments are basically making a screenwide, modeless video "layer" of 800 by 600 starting at position 0,0 (x,y) in the upper left hand corner of the screen that the child objects will be inserted into. (Note: I am fooling around with partial screen layers but I don't want to say anything about them yet as I'm having some goofy positioning problems with them I havent nailed down yet.)
It's important to note here that changing resolution (as I'm sure most of us have experienced) can result in the frustrating destruction of the GUIs in so much as nothing lines up anymore, but fiddling around with the horizsizing and vertsizing as well as the base parent resolution can assist with correcting that.
Because my own application that I'm building GUIs for is fairly extensive and contains a lot of obecjts in it I require alot of precision in the placement and unfortunately for me I havent figured out yet exactly how to stop the engine from auto-scaling the elements of the GUI.. What I am going to do for now is lock the client rez at 1024 and leave it there. Build my gui based on 1024 and try and work on mastering the resizing later.
That said, most games people are working on will want to be able to flip resolutions so hopefully someone will have some more help to offer on that subject =).
Hope this makes sense I'm still groggy from last night ;)
#5
This is mickey mouse but I think it's working for me. By operating off of more GUI controls based in the lower numbers it throws your larger numbers out of whack less.. IE if you can use GUI ctrls to "anchor" your 0,0 positions it keeps the engine from autoscaling too too much at runtine..
Example:
I have a fullscreen playgui with 2 chat boxes at the bottom of the screen. The chat box on the bottom left is sized correctly but the exact same cut/paste/copy of the chat box GUI on the right is noticeably larger... Fix: Anchor the right GUI with a GUICtrl at midscreenish.. Now the numbers arent so large and thusly the scaling isnt exponentially screwy =). I am sure there are better ways to do this but it's working for me so till I figur eout better I'm using this.
Mark
12/19/2006 (9:01 pm)
Work around to deal with the autoscaling of guid stuff:This is mickey mouse but I think it's working for me. By operating off of more GUI controls based in the lower numbers it throws your larger numbers out of whack less.. IE if you can use GUI ctrls to "anchor" your 0,0 positions it keeps the engine from autoscaling too too much at runtine..
Example:
I have a fullscreen playgui with 2 chat boxes at the bottom of the screen. The chat box on the bottom left is sized correctly but the exact same cut/paste/copy of the chat box GUI on the right is noticeably larger... Fix: Anchor the right GUI with a GUICtrl at midscreenish.. Now the numbers arent so large and thusly the scaling isnt exponentially screwy =). I am sure there are better ways to do this but it's working for me so till I figur eout better I'm using this.
Mark
Torque Owner Flybynight Studios
horizsizing
and
vertsizing
work.. Are they relational to the parent above them? Are they associated with child GUIs? I am really astounded with all the years of posts there is so little break down of the GUI syntax =/ Probably most people just fight through it like Im doing now but gee it'd benice to have some colaboration on the forums for others coming after us =)
Cheers.