New Irrlicht GUI

[sudi]

Hey i wanna create a new Irrlicht gui system which will offer more option then the current one. But before i start i wanna collect a wishlist from all irrlicht users.
This gui system is supposed enable you to build any gui you like as well with a new event system. the old one was nice but a little tricky with receiving events from alot of elements and you always had to write some boilerplate code so this is supposed to change. Anyways please post you wishlist for a new gui system. And maybe if i am doing a good job it might even replace the current system and not just end up as an addon.

Update:
Ok after listening to all this now it really seams you all like the current gui and would much rather like an extended/improved edition of it instead of a new start.
So what i got from this.

• truetype font
• 3D GUI
• Batching
• Shaders
• Rotating images/font
• Image animations
• Better skinning

please use double buffering for your widgets, that would be great!

All widgets are double buffered bc it rendered via irrlicht and irrlicht is double buffering....

The other option someone pointed out is making a really good integration of an existing advanced lib. I kinda like that idea as well and would like to know what you think. I would for example in that case go for libRocket. Anyway hope i got all the strong points out of the comments.

[Virion]

- GUI image which support animated sprite
- GUI movement? (linear transform, curve transform, spring transform etc.)
- GUI image that can fade in and out?

i think it's mostly related to event.

[hendu]

Eh, instead of creating another wheel, how about plugging in the EFL or any other gui lib. Creating an irrlicht plugin to something that can already draw to opengl could be more useful, IMHO.

[Darktib]

From my opinion, one of the major features of gui systems is signals and slots.
Styleable gui would also be nice

[shadowslair]

Eh, instead of creating another wheel, how about plugging in the EFL or any other gui lib.

It`s because he`ll try to create a new, improved gui system for the engine, which with a bit of luck may eventually get into it. And Irrlicht tries to minimize its external libs to a minimum AFAIK. BTW there`s absolutely nothing wrong with reinventing the wheel, if one has the time and will. This way you get sth of your style, working the way you want and the most important- you`ll have a very good idea how everything works. I do it almost for everything, indeed it slows your progress a bit, but in 90% at the end of the day it`s worth the time and efforts.

[hendu]

I believe the answer is "it depends". While having a rudimentary GUI in the engine itself can be useful, it's been there for a while and it has had many issues: general bugs, right-to-left text, truetype fonts, scalability, themeability, animations, some nowadays-expected-behavior to name a few. Even an edit box is surprisingly complex once you take into account the many scenarios that can happen.

What I want to say is that for something like a GUI, which is considered boring work by many (and such a bad target for reinventing), it doesn't make sense to me to duplicate work made in these areas. The end result tends to be something that misses many things (internationalization, or any other complex topic) and will not get them, due to lack of coder interest. For topics like right-to-left text it's usually not enough to have interest either, you need a native user/tester for it to make any sense.


The ideal solution now would seem to me to be to keep the current GUI (depless, but limited in some ways) and fully support an optional gui lib that has the bells and whistles. Of course I'm not entitled to tell anyone what to work on, but this is my view.

[3DModelerMan]

I think it would be best to remove the GUI from Irrlicht and move it into IrrExt. That way the developers don't have to worry about GUI and can instead focus on more important stuff like hardware instancing.

[serengeor]

I think it would be best to remove the GUI from Irrlicht and move it into IrrExt. That way the developers don't have to worry about GUI and can instead focus on more important stuff like fixing bugs.

[CuteAlien]

I think it would be best to remove the GUI from Irrlicht and move it into IrrExt. That way the developers don't have to worry about GUI and can instead focus on more important stuff like hardware instancing.

I'm mostly in the team to care about the GUI and I focus on it because I'm working with it. So moving the GUI to IrrExt would simply mean that writing tests and examples in Irrlicht would get harder (ergo - more work for us). If you want to disable it then it's a single define which you can pass as parameter on compiling. I won't care about stuff like hardware instancing as I'm no expert in that area. I suppose this has to do something with shaders, right? I agree another shader expert for the engine might be useful as it does not look anymore like Ahmed will add his stuff (the original idea was that he would be working on that). But leave the gui alone.

If there ever is a GUI that is really better to use (and shows that by being actually used in games already) we can talk about switching to another GUI. Although I suppose that the parts I'm missing most are maybe not identical with those missed by others. Stuff like better defined behavior for focus, visibility and enabling/disabling. A closer similarity to the ISceneNode interface in IGUIElement. An improved serialization system that makes it possible to serialize sub-elements, fonts, skins and other stuff. Easier support for stringtable (and yes, I think that has to do with gui). Some improvements in the skinning system to allow for example for more flexible borders. Maybe some buffering rendered text to improve the speed there. Animator support for the gui (but needs again an advanced serialization system first). Better support for overriding single skin-elements in every gui-element (instead of the current solution of adding more and more functions - but once again this needs support in the serialization system first). More font-types (do I need to mention? This needs a reworked serialization system first). Better support for international keyboard input. Maybe sometimes I dream of reverting all the u32 crap in the interface back to how it was (but don't have the confidence to do that). And last - a lot of wishes for detail improvements and bugfixes, which every new gui will probably have even a lot more.

[aanderse]

Anyways please post you wishlist for a new gui system.

please use double buffering for your widgets, that would be great!

[christianclavet]

Hi, Im trying to develop new GUI elements or improve the current one we have and sent it to the IrrExt or code snippet forum. I have 2 in current development, and would like to improve others. I will have to educate myself and check why and what about serialisation is needed that much. I never used it before and don't understand much about why it's needed.

I worked a little with wxWidget and I think our GUI system is much simpler to use and to tweak. (Surely less powerfull).

Now for wish list for a GUI stuff:
- Rendering could be put on a 3D plane or/and a billboard, so it could be used directly in 3D inside the application (the same as some GUI`s in PREY), this would improve the game/simulation/demo immersion.
- We could put shaders on some parts of gui rendering (like post-process shaders), like a background with a rippling water effect. (could be a "shaderbox" gui)
- rendering of boxes with a corner parameter (gui could have rounded corner)
- truetype font integration with utf conversion as implemented by Nalin (could use a compiler flag the same as for the DX driver)
- Images that could be scaled, rotated, and tiled. (I think scaling is only supported now)
- Animators
- Improved skinning (with images, colors and gradients boxes). Color and font overrides

Since the IRRlicht library have compiler flags, I don't understand why we would need to have the GUI separated(unless someone would like to re-use the IRRlicht GUI on OGRE or another SDK). I will not affect the size of the library if the users don't want it.

[CuteAlien]

I will have to educate myself and check why and what about serialisation is needed that much.

Serialization will for example allow that your custom gui-elements can be loaded by Irrlicht via XML together with it's own gui-elements. It's about loading&saving elements.

[teto]

truetype font integration with utf conversion as implemented by Nalin (could use a compiler flag the same as for the DX driver)

Rendering could be put on a 3D plane or/and a billboard, so it could be used directly in 3D inside the application (the same as some GUI`s in PREY), this would improve the game/simulation/demo immersion.

I wonder if that's possible with the current one ?

- We could put shaders on some parts of gui rendering (like post-process shaders), like a background with a rippling water effect. (could be a "shaderbox" gui)

that would be cool even though I can't remember any game resorting to that.

The irrlicht gui is already powerful & easy to use. That's one of the main reason people would choose irrlicht over ogre in my opinion (bc it's easier to prototype). It may be a waste to start anew (if you give up meanwhile) but heh, you are free to do whatever you want and some great features might go into the engine this way.

[sudi]

Ok after listening to all this now it really seams you all like the current gui and would much rather like an extended/improved edition of it instead of a new start.
So what i got from this.

• truetype font
• 3D GUI
• Shaders
• Rotating images/font
• Image animations
• Better skinning

please use double buffering for your widgets, that would be great!

All widgets are double buffered bc it rendered via irrlicht and irrlicht is double buffering....

The other option someone pointed out is making a really good integration of an existing advanced lib. I kinda like that idea as well and would like to know what you think. I would for example in that case go for libRocket. Anyway hope i got all the strong points out of the comments.

[hybrid]

please use double buffering for your widgets, that would be great!

All widgets are double buffered bc it rendered via irrlicht and irrlicht is double buffering....

Maybe he meant GUI batching, which would make sense here. This would be one of the major improvements also on target for the current GUI.