Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Where are all the good GUI libraries?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
40 replies to this topic

#21 Kylotan   Moderators   -  Reputation: 3346

Like
0Likes
Like

Posted 08 April 2013 - 09:25 AM

do you mean you store a large set of possible text responses and the dialogue GUI can dynamically resize itsellf based on the amount of text?

 

Even more general than that - I need a dialogue to be whatever size it needs to be to hold its content. I should never need to specify its size. HTML does this - elements grow to the correct size for their contained elements.

 

So to create a grid like inventory system GUI for example, the children entities would have a 90 degree step and 0 degree random variation.

 

This sounds rather more complex than what a GUI should typically need to do. If I want a grid, I just want to be able to create a Grid object, and then feed it several rows of data.

 

 

So, a scrollable panel parent should either be able to dynamically resize itself or force a dynamic rescaling of the children objects to fit a fixed parent size. The input system is all based on one ray cast to determine where your mouse is currently located and which actions are available depend on the GUI prefab your on. I'm pretty surprised this requires custom shaders in NGUI. Are the items you want to fit within a scrollable parent all different sizes or something?

 

Usually when you have a scrollable region, you render everything within that region (optimisations aside) but the renderer can restrict the actual drawing operations to the viewport through which you view the region. Unity lacks that exact functionality so it's hacked in by using a custom shader on scrollable regions to achieve the same effect.

 

That's a separate issue from NGUI using colliders to stop you accidentally clicking on the objects that are invisible. That just implies that their input handling system is completely different to pretty much any other sensible GUI, which would propagate mouse clicks down through the GUI hierarchy to see what was clicked on, which would reject clicks on objects scrolled outside the viewport by design.

 

The size and shape of the items on the scrollable region should be irrelevant to how to implement the scrolling behaviour.



Sponsor:

#22 Rorakin   Members   -  Reputation: 618

Like
0Likes
Like

Posted 08 April 2013 - 06:33 PM

Even more general than that - I need a dialogue to be whatever size it needs to be to hold its content. I should never need to specify its size. HTML does this - elements grow to the correct size for their contained elements.

 

Yea, that makes sense.

 

This sounds rather more complex than what a GUI should typically need to do. If I want a grid, I just want to be able to create a Grid object, and then feed it several rows of data.

 

Yea, I realized I was trying to make one thing be generic enough to work for a multitude of things, but it will be better to create a bunch of different simpler parent panel type scripts / prefabs.

 

That's a separate issue from NGUI using colliders to stop you accidentally clicking on the objects that are invisible. That just implies that their input handling system is completely different to pretty much any other sensible GUI, which would propagate mouse clicks down through the GUI hierarchy to see what was clicked on, which would reject clicks on objects scrolled outside the viewport by design.

 

Ok, yea what I am doing currently is RaycastAll() on the entire GUI and then sending event messages for every GUI hit using an event handler system. The GUI elements themselves in addition to the editor can receive and process the input events.



#23 swiftcoder   Senior Moderators   -  Reputation: 11730

Like
0Likes
Like

Posted 08 April 2013 - 07:53 PM

That's a separate issue from NGUI using colliders to stop you accidentally clicking on the objects that are invisible. That just implies that their input handling system is completely different to pretty much any other sensible GUI, which would propagate mouse clicks down through the GUI hierarchy to see what was clicked on, which would reject clicks on objects scrolled outside the viewport by design.T

To be fair, most GUIs propagate events both top-down and bottom-up, and if you are raycasting in 3D, it's often easiest to find the deepest widget in the hierarchy and walk back up.

You do need some kind of clipping in either case, to handle scrolling containers. The clipping is really simple in a purely 2D GUI, but it's a bit more involved in a 3D GUI, and their clipping-via-colliders may be the best they can do in Unity.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#24 Kylotan   Moderators   -  Reputation: 3346

Like
1Likes
Like

Posted 09 April 2013 - 05:23 AM

What I meant with the top-down processing is that traditionally in 2D you go top-down to find out what was actually clicked on, and then from there you go bottom-up to find a handler for that click. The 3D aspect does change things, but I'm sure there are often pretty trivial ways of implementing clipped areas. For example, Unity has a RayCastAll() which returns all the objects hit, not just the first. To implement clipping to a parent you can discard any object in that list whose parent is not also in that list.

 

To be fair, that's only one of my complaints about NGUI - I hate the fact that you're expected to manually set up materials and atlases and sliced sprites and all kinds of other graphical esoterica that I think should be handled by the engine, but most of that is Unity's fault. You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.



#25 swiftcoder   Senior Moderators   -  Reputation: 11730

Like
0Likes
Like

Posted 09 April 2013 - 07:23 AM

You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

Aye. 3D strikes me as largely unnecessary for GUIs - plus, you want anything interactive to be flat to the screen anyway...

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#26 Zipster   Crossbones+   -  Reputation: 1031

Like
0Likes
Like

Posted 09 April 2013 - 11:05 AM

You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

Aye. 3D strikes me as largely unnecessary for GUIs - plus, you want anything interactive to be flat to the screen anyway...

On PCs, yes, you'd want it to be flat for sane interaction with a mouse cursor. But on a console, you don't have to worry about that with 3D UI since your interaction is via focus and not mouseover, so you can do more interesting stuff in 3D space. Think of the Borderlands 2 inventory UI... not necessarily saying I'm a huge fan, but there's not as much as a usability issue in that case.



#27 Nypyren   Crossbones+   -  Reputation: 5529

Like
0Likes
Like

Posted 09 April 2013 - 12:58 PM

You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

Aye. 3D strikes me as largely unnecessary for GUIs - plus, you want anything interactive to be flat to the screen anyway...

On PCs, yes, you'd want it to be flat for sane interaction with a mouse cursor. But on a console, you don't have to worry about that with 3D UI since your interaction is via focus and not mouseover, so you can do more interesting stuff in 3D space. Think of the Borderlands 2 inventory UI... not necessarily saying I'm a huge fan, but there's not as much as a usability issue in that case.
Well, you have to worry if your game is cross-platform with a PC version like Borderlands 2 is. And even Borderlands 2's PC UI **still** has several bugs in the vending machine and bank/shared stash UIs.

#28 Rorakin   Members   -  Reputation: 618

Like
0Likes
Like

Posted 09 April 2013 - 05:48 PM

You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

Aye. 3D strikes me as largely unnecessary for GUIs - plus, you want anything interactive to be flat to the screen anyway...

It's unnecessary?! Come on now we all know making games isn't about what is or isn't necessary, it's about what's AWESOME. No wants to interact with a boring lifeless 2d GUI.

I think the main point here is that the GUI is largely functional only in 2D, but can do some cool 3d animations for the wow factor. I don't think anyone is actually designing a functional 3d scrolling component for example, that would be craziness.

This is the kinda GUI that I want to make very quickly through an editor->

Skip to 3 minutes 30 seconds

To make that should only take 10 minutes tops, if I can't make that in the editor I'm creating for Unity in 10 minutes then I've failed because it took me a whole lot longer than 10 minutes to manually code what you see in that video, and the whole point of the editor is to greatly reduce the manual coding smile.png


Edited by Rorakin, 09 April 2013 - 05:49 PM.


#29 Kylotan   Moderators   -  Reputation: 3346

Like
1Likes
Like

Posted 10 April 2013 - 06:43 AM

See, that looks slick and you might think it's awesome, but I notice 2 things:

  1. The skill popup windows are all exactly the same size. This implies someone has had to hand-make that specific window with some fixed-size labels inside. And it means that if I ever write a skill with too much text, I have to go back and edit the GUI, and that's exactly what you don't want.
  2. Earlier in the video (1:30) I see a portrait with left and right buttons next to it. Again, it's just an implication, but that is the classic thing you implement if you aren't able to support a scrolling selection area (which is usually preferable since a player can more easily compare potential choices).

If I can have cool 3D effects - great. But they're secondary to gameplay and usability, and often these 3D GUIs come with compromises that affect those aspects.

 

And even Borderlands 2's PC UI **still** has several bugs in the vending machine and bank/shared stash UIs.

 

This just reminded me of several UI bugs in XCOM, which uses Scaleform. Trivial things like mouse-overs not working first time, or buttons apparently being unable to stretch to contain their text. Why are these simple things still problems in 2013? Baffling.



#30 Rorakin   Members   -  Reputation: 618

Like
0Likes
Like

Posted 10 April 2013 - 04:34 PM

See, that looks slick and you might think it's awesome, but I notice 2 things:

The skill popup windows are all exactly the same size. This implies someone has had to hand-make that specific window with some fixed-size labels inside. And it means that if I ever write a skill with too much text, I have to go back and edit the GUI, and that's exactly what you don't want.
Earlier in the video (1:30) I see a portrait with left and right buttons next to it. Again, it's just an implication, but that is the classic thing you implement if you aren't able to support a scrolling selection area (which is usually preferable since a player can more easily compare potential choices).

 

Yes this video is a few months old when I was just quickly prototyping my GUI from scratch. The editor I'm making will of course allow 3d animations in addition to the diverse functionality of GUI elements that can scroll / resize / etc. I was just pointing out the 3d stuff smile.png


Edited by Rorakin, 10 April 2013 - 04:35 PM.


#31 Alpha_ProgDes   Crossbones+   -  Reputation: 4696

Like
0Likes
Like

Posted 10 April 2013 - 11:33 PM

How about the new guy on the block? OtterUI.


Beginner in Game Development? Read here.
 
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
 
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts Posted Image
 
Spoiler

#32 Kylotan   Moderators   -  Reputation: 3346

Like
0Likes
Like

Posted 11 April 2013 - 04:57 AM

Might be good, but is Yet Another C++ GUI Library though, ie. what I'm not looking for. (Also, needs proper docs, browsable online. Had to dig through the repo, found at least one dead link to online docs, and an MS Word file which I can't be bothered to download and open.)



#33 Hodgman   Moderators   -  Reputation: 34943

Like
0Likes
Like

Posted 11 April 2013 - 05:31 AM

What about taking any of the C GUI libraries and generating a wrapper for the language of your choice for them?

#34 Zipster   Crossbones+   -  Reputation: 1031

Like
0Likes
Like

Posted 11 April 2013 - 11:15 AM

Well, you have to worry if your game is cross-platform with a PC version like Borderlands 2 is. And even Borderlands 2's PC UI **still** has several bugs in the vending machine and bank/shared stash UIs.

True, I noticed quite a few bugs in the UI as well, but that isn't specific to it being 3D versus 2D. They appeared to be in the business layer mostly. In truth, most of the interactable "3D" UI I've seen in Borderlands (and lots of other games) is just a 2D scene rendered to a texture and slapped on a billboard. I don't think they're using any of Flash's built-in 3D capabilities.

 

This just reminded me of several UI bugs in XCOM, which uses Scaleform. Trivial things like mouse-overs not working first time, or buttons apparently being unable to stretch to contain their text. Why are these simple things still problems in 2013? Baffling.

I'm just as baffled. Pretty much anything dealing with text/fonts in Flash, especially when content needs to be resized, is a major headache. I've never had too much trouble with input handling/detection, so that might just be their particular UI implementation.



#35 Kylotan   Moderators   -  Reputation: 3346

Like
0Likes
Like

Posted 12 April 2013 - 05:31 AM

What about taking any of the C GUI libraries and generating a wrapper for the language of your choice for them?

It couldn't just be a wrapper as the renderer and event handling surely has to cooperate with the rest of the app. So it could be as much extra effort as deciding to abandon the language of choice and develop in C++. I don't even know if it would be practical at all given the need to have control over rendering, which isn't always very practical (eg. in Unity) and I'm not immediately sure which UI libraries do let you inject a renderer of your choice.

#36 l0calh05t   Members   -  Reputation: 871

Like
0Likes
Like

Posted 12 April 2013 - 08:11 AM

What about taking any of the C GUI libraries and generating a wrapper for the language of your choice for them?

It couldn't just be a wrapper as the renderer and event handling surely has to cooperate with the rest of the app. So it could be as much extra effort as deciding to abandon the language of choice and develop in C++. I don't even know if it would be practical at all given the need to have control over rendering, which isn't always very practical (eg. in Unity) and I'm not immediately sure which UI libraries do let you inject a renderer of your choice.

libRocket lets you use your own renderer (in fact you basically have to provide your own!), so does OtterUI from the description.



#37 swiftcoder   Senior Moderators   -  Reputation: 11730

Like
0Likes
Like

Posted 12 April 2013 - 09:26 AM

libRocket lets you use your own renderer (in fact you basically have to provide your own!), so does OtterUI from the description.

And, of course, the frankenstein creation that is Crazy Eddie's...


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#38 Grafalgar   Members   -  Reputation: 548

Like
2Likes
Like

Posted 14 April 2013 - 04:49 PM

Hi folks,

 

I'm the creator of OtterUI.  Thanks for pointing out the old-ass Word doc file - that's a remnant from a time gone by ;)   I've cleaned things up a tad more.  Let me know if you run into anything else.  And, of course, feel free to reach out if you have any questions.

 

Also, l0cal05t is correct - OtterUI does not provide its own built-in renderer.  I provide a rudimentary one just as a starting point, but after that it's up to you integrate it into your pipeline.  That's done on purpose - I got tired of UI libraries competing against my renderers for whatever reason.  Same goes for File IO, audio, and so on.

 

-Graf



#39 Rorakin   Members   -  Reputation: 618

Like
0Likes
Like

Posted 15 April 2013 - 05:47 PM

Alright so I spent most of my weekend reading NGUI code, and I understand the business with the shaders clipping the textures for scrollable panels because to do scrollable panels with Unity camera's would require creating both a separate camera AND a separate layer for EACH scrollable panel. Since only 32 layers are ever allowed in a Unity game, it would not be possible to create an arbitrary number of scrollable panels using cameras in Unity. I was thinking the camera approach would be viable if you set a limit on the number of scrollable panels that are active in the game at any given moment to some number, say 10.

I want to go with this more simple camera based approach for my GUI editor rather than recreate the graphical complexity of using custom shaders, can anyone think of an actual gaming use case that would require more than 10 scrollable panels needing to be used on a single screen in a game? I can't think of any game that does this, so I think I will proceed this way.

 

EDIT: Hmm I just realized the camera approach would work for an arbitrary number of simultaneous scrollable panels if the GUI were 2d only, because then the z axis could be treated as the layer, and separate cameras could be made on different z layers for scrollable panels. Then panel content would be on that z layer but would be contrained by the camera viewport for that layer, but then we lose the ability to do 3d sadly.


Edited by Rorakin, 15 April 2013 - 06:28 PM.


#40 Kylotan   Moderators   -  Reputation: 3346

Like
0Likes
Like

Posted 16 April 2013 - 09:14 AM

 

What about taking any of the C GUI libraries and generating a wrapper for the language of your choice for them?

It couldn't just be a wrapper as the renderer and event handling surely has to cooperate with the rest of the app. So it could be as much extra effort as deciding to abandon the language of choice and develop in C++. I don't even know if it would be practical at all given the need to have control over rendering, which isn't always very practical (eg. in Unity) and I'm not immediately sure which UI libraries do let you inject a renderer of your choice.

libRocket lets you use your own renderer (in fact you basically have to provide your own!), so does OtterUI from the description.

 

Noted. Still, it's far too much work really, when you look at how much you'd have to wrap in the first place before you even start on implementing a renderer.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS