GuiShapeNameHud functionality discussion
by Daniel Buckmaster · in Torque 3D Professional · 10/09/2013 (4:56 pm) · 8 replies
I submitted a pull-request that changes the way GuiShapeNameHud works. If you haven't used that control, it's a piece of GUI that renders the name of any ShapeBase object inside its rectangular area on the screen.
At the moment, these names are rendered as plain text (you can configure it a little bit using profiles, I think). There is also the ability to add a fill and border - to the entire screen area the profile covers, rather than to each tag. My pull request changes this so that the border and fill happen around each text tag, rather than filling the entire control area.
IMO, this makes the control far more useful. You can, for example, make black text on a white fill label so that your shape names are readable whatever's going on in the game world. I think that if you actually want a border/fill in the entire area the name rendering is performed in, it should be done with a separate control that does that, rather than lump the functionality into the GuiShapeNameHud.
Thoughts, anyone? Who's using GuiShapeNameHud? Who's using the fill and border?
At the moment, these names are rendered as plain text (you can configure it a little bit using profiles, I think). There is also the ability to add a fill and border - to the entire screen area the profile covers, rather than to each tag. My pull request changes this so that the border and fill happen around each text tag, rather than filling the entire control area.
IMO, this makes the control far more useful. You can, for example, make black text on a white fill label so that your shape names are readable whatever's going on in the game world. I think that if you actually want a border/fill in the entire area the name rendering is performed in, it should be done with a separate control that does that, rather than lump the functionality into the GuiShapeNameHud.
Thoughts, anyone? Who's using GuiShapeNameHud? Who's using the fill and border?
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
10/09/2013 (7:06 pm)
Quote:I use it when prototyping.That's exactly what I do with it - in vlrtt I use it as a quick way to provide keyboard prompts. I could see it being useful for displaying debugging information, as well (I thought UAISK did that).
#3
10/10/2013 (3:05 am)
Oooo ... this sounds quite interesting and very useful. +1 8-} 
#4
10/10/2013 (9:51 am)
I agree that this is useful. My only hesitancy in automatically doing the merge was that it changes the stock default behavior that has been associated with that control for years. When we've done that in the past there has been dissent... but since noone appears to be objecting I'll give it another couple of days and then perform the merge.Quote:My Tribes clone uses the fill and border for the control itself, which is toggled on to provide a HUD overlay. Why would I want to include another seperate control just to provide the fill/frame overlay when I could use just one? On the other hand there is this other game I'm working on and the usage for the shapename HUD would take advantage of Daniel's changes. The committee has to think about both sides of a situation like this... Personally I would rather see the functionality expanded to both fill/frame the text label and the HUD object -- best of both worlds don't you think?
IMO, this makes the control far more useful. You can, for example, make black text on a white fill label so that your shape names are readable whatever's going on in the game world. I think that if you actually want a border/fill in the entire area the name rendering is performed in, it should be done with a separate control that does that, rather than lump the functionality into the GuiShapeNameHud.
Thoughts, anyone? Who's using GuiShapeNameHud? Who's using the fill and border?
#5
As I said, I'll get around to adding both functions to the pull-request. I just hesitate to constantly add functionality to things in the engine, piling stuff on top of other stuff instead of refactoring it. Down that path lie blobjects...
10/10/2013 (2:04 pm)
Quote:Why would I want to include another seperate control just to provide the fill/frame overlay when I could use just one?The logical conclusion of this argument is that GameTSControl should include GuiShapeNameHud's functionality, as well as a health bar, timer, etc. A single control should provide a single piece of functionality. On the other hand, if you wanted to, say, resize your shape name overlay, you'd need to resize both controls. Which is a pain.
As I said, I'll get around to adding both functions to the pull-request. I just hesitate to constantly add functionality to things in the engine, piling stuff on top of other stuff instead of refactoring it. Down that path lie blobjects...
#6
Absolute not! This is what is called feature bloat and should be avoided at all costs. Not only that but you're complicating the control with features that have nothing to do with its actual purpose, of which is to just render the 3D scene.
For what you're wanting is EXACTLY the whole reason for the GUI subsystem in the first place! You place controls ON TOP of the GameTSControl and can toggle HUD objects on/off on the fly. No need to make things more complicated by making them fixed function inside of a single control. It just doesn't make any sense.
As for the GuiShapeNameHud just leave it alone. If you want to modify it or replace it with your own control in your own projects, or release them as resources in the resource section of this site, then that's fine. But don't expect your preferences to be forced upon vanilla Torque 3D users.
10/10/2013 (5:07 pm)
Quote:The logical conclusion of this argument is that GameTSControl should include GuiShapeNameHud's functionality, as well as a health bar, timer, etc. A single control should provide a single piece of functionality.
Absolute not! This is what is called feature bloat and should be avoided at all costs. Not only that but you're complicating the control with features that have nothing to do with its actual purpose, of which is to just render the 3D scene.
For what you're wanting is EXACTLY the whole reason for the GUI subsystem in the first place! You place controls ON TOP of the GameTSControl and can toggle HUD objects on/off on the fly. No need to make things more complicated by making them fixed function inside of a single control. It just doesn't make any sense.
As for the GuiShapeNameHud just leave it alone. If you want to modify it or replace it with your own control in your own projects, or release them as resources in the resource section of this site, then that's fine. But don't expect your preferences to be forced upon vanilla Torque 3D users.
#7
It's a really petty example, but then why don't we add border rendering to SelectHud (which actually has a lot of overlapping functionality with ShapeNameHud anyway)? ClockHud actually already has a fill and border, which is a duplicate of the same features in ShapeNameHud. It's the start of the slope.
10/10/2013 (10:39 pm)
Nathan, I didn't say that my 'logical conclusion' was a good one; quite the opposite! It was a reduction to absurdity, if I'm using that term correctly. A single control should provide a single piece of functionality is what I continued to say. Rendering the border in the ShapeNameHud is not that.It's a really petty example, but then why don't we add border rendering to SelectHud (which actually has a lot of overlapping functionality with ShapeNameHud anyway)? ClockHud actually already has a fill and border, which is a duplicate of the same features in ShapeNameHud. It's the start of the slope.
Quote:But don't expect your preferences to be forced upon vanilla Torque 3D users.I don't, I had hoped this pull-request would make the engine more sensible for new users. When I first applied the border and fill I was stupefied... why would you want a border around the whole control, with no way to add borders to the text elements which actually need borders? The point of this thread is to discuss what would be most useful for the most people.
#8
Though Michael does give an example where it might be useful so I guess the right thing to do is let it be configurable with a flag. It's not a huge amount of difference in code anyway.
10/11/2013 (1:43 am)
That was my initial reaction too. Why would anyone want a huge border around text that fills up only a fraction of that? If a new user adds a GuiShapeNameHud, I think they usually expect each text "box" to resize with the contents.Though Michael does give an example where it might be useful so I guess the right thing to do is let it be configurable with a flag. It's not a huge amount of difference in code anyway.
Torque Owner Stefan Lundmark
I use it when prototyping.