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.)

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.

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

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.

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

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.

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.