Biiiiiig thanks to @pspeed and @normen for putting up with my questions.
Long story short. I hate Nifty… unfair statement… I hate Nifty as a game GUI library. So, when I saw Paul was working on his own GUI… it was like a major forehead slap. Why the F am I not doing this already??! O.o
Quick vid showing what I just finished up. Basically, it shows default movement, resize, docking and scaling behavior (well, shows some of it, anyways)
Both graphics and text
Graphic elements can use whatever shader I want to write for it.
Text by default implements word wrapping
Positioning is absolute (relative to the parent container)
Resizing is recursive and takes into account scaling and docking behavior per child
Elements can be locked to parent bounds and stifles movement and resizing accordingly
All elements implement draggable, resizing and docking functionality as they are behaviors of the element class
The window in the vid consists of 7 unique objects (including text. And it literally took me 5 minutes to put together the window from the primitive Element class.
1 element as the window panel… resize enables
1 element for the dragbar - movable enable, set to effect parent element, scaling EW only, docked north & west
1 element for the text area - scaling set for NS and EW, docked north and west
1 3 state button - docked south and west
1 3 state button - docked south and east
the last two elements are the text elements internal to the drag bar and text area.
Anyways… just wanted to share the “other” project I am working on for fun. I might actually get back to working on my game now that I can do away with Nifty!!
Cool. Just like my UI in jME2 ^^ Whats the general system for layout? Percent? Pixels? Alignment like for the buttons?
Btw, this is how the GUI mess in jME2 started. Everybody started working on his own library or some other external library that he imported. Then we had 6 half-done or half-working GUI libs. Only late people realized they a) don’t have time to invest to support the library (Jens is working continuously on Nifty since more than three years) b) have no interest in making a general purpose UI library but one strictly adhering to their requirements. This is why I personally still think it makes sense that all work on and with one library and it gets improved from multiple sides. Lone programmer GUIs are cool for lone programmers but people that make themselves dependent on them will get locked in. And creating some images and text in the GUI node isn’t really that hard if people don’t want to use Nifty as people have proven time and again in jME2 (and you now too).
@normen Oh man… I maybe should have clarified better. This is just for me / having fun. Don’t worry about the plugin library getting cluttered with unsupported GUI libraries!! I have NO desire or intention of releasing / supporting something like this. I’ve read the posts under GUI long enough to know better
Although, I though it would be cool to share the effort as I go… in case someone else working on their own says… ooo… hey, I’ve been having trouble with that… How did you handle that one?
For instance:
I’m almost done with text input fields / input text areas. - when done, will share the approach
I think I may have a way of dealing with clipping layers - if it works, will definitely share the approach.
Layouts are pixel based… I’ve never been very fond of % layouts.
Alignment is all in setting behaviors up. How do I (as an element) react when my parent updates? On resize, do I scale east/west or north/south or both or not at all? Am I docked to the NW, N, SE, etc and move accordingly on resize? Am I locked to my parent’'s bounds? If you meant button text… left | center | right >.<
Anyways… I'm more than happy to post code snippets or whatever if someone sees something that peeks there interest along the way.
Well I actually also meant that if you decide to not use nifty it might be wise to use and help improve the library that is actually going to the plugin repo (namely pauls) instead of completely diverting the field with homebrew solutions. Of course that is at the same time the thing that in the end makes people roll their own lib again Its a vicious circle ^^
@normen said:
Well I actually also meant that if you decide to not use nifty it might be wise to use and help improve the library that is actually going to the plugin repo (namely pauls) instead of completely diverting the field with homebrew solutions. Of course that is at the same time the thing that in the end makes people roll their own lib again ;) Its a vicious circle ^^
To be fair, I haven’t provided any kind of ETA on when I’ll even post code. Though your points are all well founded.
I may stick the stuff up in the repo “as is” at some point soon just to have it out there. I even added a groovy layer for configuring styles already… since it doesn’t require any additional dependencies to compile, just to run. (JDK scripting support is awesome.)
@normen said:
Well I actually also meant that if you decide to not use nifty it might be wise to use and help improve the library that is actually going to the plugin repo (namely pauls) instead of completely diverting the field with homebrew solutions. Of course that is at the same time the thing that in the end makes people roll their own lib again ;) Its a vicious circle ^^
Though, chances are… I would want to create my own anyways. The whole point of developing games… is for the love for playing games (otherwise, half the people here would be writing plugins for minecraft instead of creating there own bloxel world, no?). I love writing user-interface libraries. I’ve made a habit of it actually >.< My favorite thus far being SVG based as it requires no pre-defined graphics.
Yes, but the fact that you had to reinvent the wheel for everything in jME2 and that you had to assess what library works with other libraries you want to use is much more of a downer than having the option to do it your way or use the default implementation where many people helped improve it. Same for physics or anything really. People choose Unity or UDK over Ogre not because of the functionality but because Ogre is more or less a loose collection of C++ game-related libraries plus a scenegraph, not more. jME exists not because its impossible to write games in java without it but because you’d write this stuff anyway when doing a 3d game with e.g. lwjgl or so. Finally people choose jME over other java game libs not because of the monkey or the fact that its java but because its a complete solution and just gives off a more thought-through impression (and because of the active community). Anyway… nothing here against you or your GUI lib (or not lib) and I am not actually defending Nifty even if that may seem so, I didn’t even choose it to be our GUI lib. This is just about the general issue of doing something or not. …idk why you gave that Minecraft plugin example anyway ^^
@normen said:
Yes, but the fact that you had to reinvent the wheel for everything in jME2 and that you had to assess what library works with other libraries you want to use is much more of a downer than having the option to do it your way or use the default implementation where many people helped improve it. Same for physics or anything really. People choose Unity or UDK over Ogre not because of the functionality but because Ogre is more or less a loose collection of C++ game-related libraries plus a scenegraph, not more. jME exists not because its impossible to write games in java without it but because you'd write this stuff anyway when doing a 3d game with e.g. lwjgl or so. Finally people choose jME over other java game libs not because of the monkey or the fact that its java but because its a complete solution and just gives off a more thought-through impression (and because of the active community). Anyway.. nothing here against you or your GUI lib (or not lib) and I am not actually defending Nifty even if that may seem so, I didn't even choose it to be our GUI lib. This is just about the general issue of doing something or not. ....idk why you gave that Minecraft plugin example anyway ^^
The minecraft reference was in pointing out that there are already MULTIPLE bloxel plugins for JME3, however… everyone writes a new one when they start their bloxel world… instead of contributing to an existing one. There has to be a reason for this (more than likely… the existing plugins a) don’t do specifically what their looking for or b) they want finite control & complete understanding over a core piece of their game).
I get where your coming from… I really do.
However:
I can’t really contribute to Nifty… I can just complain and grumble until a patch is released.
I don’t have access to @pspeed 's library yet. All I can do is share ideas atm. And, me sharing my ideas as I go might (slim chance, but could happen) spark an idea with him while he is still working on it.
And the most important part is… I love writing code for GUI’s. Each time I go through the exercise, I learn something new.
Plus, it only took me a day or two to reinvent the wheel. This goes a long way towards showing how intuitive and well implemented JME3 is.
Right, its something you write for your game and thats good. Paul uses basically nothing but the core scenegraph for mythruna, thats also fine. Its just that if 80% of our users decide to use something else we’d have to think about that. You explain how you do your own GUI, I explain why we suggest using Nifty. Sorry for abusing your thread for propaganda here but if paul and you start going in this direction you might unintentinally move us into the formerly described situation quickly. Only then it would be a pity if you hadn’t worked together on an even better lib Its really not actually about what you do, should do or should not do, its great you share your progress.
@normen Speaking of progress, I could use your help understanding something. I’m having a bit of trouble with z-order in the gui node. I would have thought it worked as described in the HUD wiki… however, things seem to start getting weird with multiple nodes and nesting. Let me see if I can diagram my expectations… and then what I am seeing.
Say I had:
Node 1 (z : 1)
---- Node 1’s Child 1 (z :-0.9)
Node 2 (z : 0.8)
---- Node 2’s Child 1 (z : 0.7)
I would expect to see
Node 1 behind everything
Node 1’s child slightly closer
Node 2 above both of these
Node 2’s child in front.
What I am seeing is:
Node 1 farthest away
Node 2 next
Node 1 child next
Node 2’s child closest.
Does nesting nodes effect z-order in some way?
Or are their limitations that aren’t described in the HUD wiki?
Or is it -1 to 1 in the guiNode only… then 1 to 0 in nested nodes? I know… this makes zero sense… unless how distance is calc’d in gui node is not applied to child nodes as well.
The world Z is used to sort objects back to front in the GUI node. I don’t remember exactly how that comparator picks the Z value to use for sorting.
Because the guiNode has it’s Z scale flattened, there will be no depth written or tested in the Z-buffer. So rendering order is everything in the GUI bucket.
Edit: " I don’t remember exactly how that comparator picks the Z value to use for sorting." Meaning I don’t know whether it uses object center or something like nearest point like the opaque bucket.
A pretty cool update to this. I implemented shader-based clipping… and since all events are delegated from the screen class, I was able to easily determine where the clipped focus element should be ignored. Like other behaviors, clipping is unique to each object and can be applied or ignored and each object can be set with unique clipping objects. So, two objects contained by the same layer could be clipped by two completely unrelated objects that are not part of the clipped layers hierarchy.
Anyways, here be a vid of the clipping (and a bit of the text input element… which is still a work in progress. I’m not totally happy with the caret behavior… and I have only just started implementing text ranges.
Really happy with this one. Dynamic resizable scroll areas. It turns out that the way I implemented clipping lent itself to some things I had considered… like using an element to clip itself. This allowed for using a standard element as it’s own scrollable area. Anyways… horizontal and vertical scrolling… though the vid only shows vertical, basically to show off the dynamic resizing. And… here it is…
My history with Nifty is rather chaotic and I have a deep seated love/hate relationship with it. Seeing the above makes me want that GUI even if I know it’s not for everyone’s use. That makes me sad.
@madjack If no one is apposed to me adding this as a plugin, I’ll be willing to do so when it is complete. I just don’t want to upset the powers that be, or cause confusion/chaos unnecessarily.
Oh… past that. New update: Really narrowed down how TextField/Passwords should and do work now.
Features (everything you expect they should do… including blinking caret when the caret is in static position… this and text ranges are handled at the shader level for visuals)
Caret: This looks/works exactly as you would expect from a standard GUI library. You can set the position via keys or mouse pointer.
Text Ranges: These work great! Not only can you use SHIFT+(arrows/page/home/end) and CTRL+SHIFT+(arrows/page/home/end), you can also select text ranges using mouse click+drag+release or SHIFT+click.
Cut & Paste Yep… this works as well.
Password masking: you pick the character.
Set max characters per field.
Set grab-bags for character exclusions or use predifiened flags such as numberOnly, noSpecialCharacters, etc.
Set rules such as mustContain, etc.
Anyways… I’m pretty happy with this as test fields are probably the most irritating part of most game GUI’s.
Next on the list is adding visual effects via texture deformations, blending, etc.
Will be positing a complete list of available controls soon(ish)
And you will be pleasantly surprised at exactly how easy it is to design/build you own controls from scratch using just a single primitive.
Pet peeve: I really hate it when devs don’t implement CTRL-INS / CTRL-DEL, effectively the precursors of Copy/Paste modern shortcuts of CTRL-C/CTRL-V.
Also, word navigation in an editable text box can be frustrating. Firefox uses its own version of how that should work vs standard software. But that part is very rare.
As far as the GUI library is concerned, if I were a religious type I would constantly pray for your salvation. lol
Though your points are all well founded.
Its really not actually about what you do, should do or should not do, its great you share your progress.
lol