I would like to suggest inverting the y axis of guiNode. Currently the y axis pointing upward is a stupid idea and nowhere found. The center of coordinates is always at the top left corner of the screen.
It makes a lot of confusion and problems.
It’s not really possible without using negative coordinates on screen. If you flip Y to be upside down then you also have to flip X.
And if you are ok with negative coordinates then guiNode.setLocalTranslation( 0, cam.getHeight(), 0 )
“nowhere found” is a very strong statement.
y axis up is quite common in a lot of places. Maybe not the GUI libraries you are used to but it is still common elsewhere - and more importantly it is consistent with the 3d view in the scene graph where positive y is also up.
@zarch said: "nowhere found" is a very strong statement.y axis up is quite common in a lot of places. Maybe not the GUI libraries you are used to but it is still common elsewhere - and more importantly it is consistent with the 3d view in the scene graph where positive y is also up.
Truth. OS/2 was Y-up. Every graph plotting API I’ve ever used was Y-up by default, etc…
For graphics, it’s extremely common to use the mathematically correct Cartesian coordinate system.
Reasons:
- The logic of reading and writing in most countries is from the top-left.
- NOWHERE in the world reading or writing starts from the bottom.
Beside this - most browsers support floating layouts, where objects are positioned from top-left, to the bottom-right. Every web browser uses the top left center coordinate system.
Most GUI libraries use that system: like Swing, QT, even the NIfty library (not mentioning Unity or other big game engines).
@zarch
“y axis up is quite common in a lot of places”
So maybe tell me where did You found this solution? What dark and abandoned place have You been and found this working that way?
@pspeed
I don’t think that this is impossible. As I know - the rootNode is an instance of Node. So it’s possible to extend the Node for a GuiNode and add the required functionality/handling of coordinates - this is the easiest workaround but not a serious solution.
pspeed already listed several examples.
@luke1985 said: Reasons: 1. The logic of reading and writing in most countries is from the top-left. 2. NOWHERE in the world reading or writing starts from the bottom. Beside this - most browsers support floating layouts, where objects are positioned from top-left, to the bottom-right. Every web browser uses the top left center coordinate system. Most GUI libraries use that system: like Swing, QT, even the NIfty library (not mentioning Unity or other big game engines).@zarch
“y axis up is quite common in a lot of places”
So maybe tell me where did You found this solution? What dark and abandoned place have You been and found this working that way?@pspeed
I don’t think that this is impossible. As I know - the rootNode is an instance of Node. So it’s possible to extend the Node for a GuiNode and add the required functionality/handling of coordinates - this is the easiest workaround but not a serious solution.
I think you haven’t thought this through properly. If you invert the coordinate system then everything gets rendered upside down. Text would be upside down, etc… not to mention that all of the triangle windings would be backwards. It’s a huge undertaking and lots of code to maintain just to avoid you using cam.getHeight() - y.
Talking about graph ploting libraries - this is not the same branch as game engines. I can’t imagine graph ploting libraries which use the top-left corner as the coordinate center. That would be completely inappropriate for graphs, where almost always in that case - they are plotted so that y axis represents the positive amount.
The OS/2. To be honest to the time You wrote the post I didn’t know what is OS/2. Then I’ve read an article on wikipedia.
Now I wont argument anymore about apparent things if somebody takes out 10 years old operating system that is dead and no more used.
Chill, dude. If this were easy to do then we’d do it. It’s not easy. In fact it’s ridiculously hard. Which is about 100000x harder than getHeight() -y.
<cite>@luke1985 said:</cite> Currently the y axis pointing upward is a stupid idea and nowhere found.
Oh really? Except, you know, in OpenGL
http://www.arcsynthesis.org/gltut/Basics/Intro%20Graphics%20and%20Rendering.html#d0e676
1 Like
“Huge undertaking”
One day I was writing my game for WebGL enabled browsers. It took me 2 or 3 months. Then I’ve realized two things:
- WebGL is too slow
- JavaScript is too slow
- JavaScript is bad language for so much complicated system as a game
- JavaScript has no good IDE that could perform correct refactoring and make some operations easier
Well today I think that it was worth taking the effort switching to Java rather than saying that something is too big.
Imagine God creating a human and saying that taking his head above his head is a too big effort. He then created man so that his head was between his legs, so the man had to lift his head everytime he wanted to pee.
Saying that something is huge undertaking and giving up is just a laziness. It’s better to get things work correct. And if somebody ignores the fact, let him be responsible for it.
@luke1985 said: "Huge undertaking"One day I was writing my game for WebGL enabled browsers. It took me 2 or 3 months. Then I’ve realized two things:
- WebGL is too slow
- JavaScript is too slow
- JavaScript is bad language for so much complicated system as a game
- JavaScript has no good IDE that could perform correct refactoring and make some operations easier
Well today I think that it was worth taking the effort switching to Java rather than saying that something is too big.
Imagine God creating a human and saying that taking his head above his head is a too big effort. He then created man so that his head was between his legs, so the man had to lift his head everytime he wanted to pee.
Saying that something is huge undertaking and giving up is just a laziness. It’s better to get things work correct. And if somebody ignores the fact, let him be responsible for it.
Yeah, I don’t think we’re going to add special case paths through the whole engine to avoid users having to use cam.getHeight() - y in their GUIs (or just -y if you pretranslate guiNode). (Because note that this is only GUI-related and not game related per se)
It’s not worth the hassle. You are welcome to try to submit a patch but I suspect it will be too big and invasive to accept.
1 Like
All that rage for an axis direction…
Is that really a big problem?
I think the time of jme contributors would be better spent on something else.
Also I don’t want to redo all the code for all my GUI appstates just to handle a different coordinates perspective… all because some guy on the forums “thought it was stupid”… You need to make a more compelling argument man.
1 Like
Well, getHeight()-y combines final total height and coordinates. That can be a problem when you want to do coordinates first and total height later (maybe because you don’t know the number of items beforehand, or similar situations). Or if you increase or decrease the number of items, you need to adjust coordinates in items that don’t actually change place. That’s all possible but extra code you write.
Personally, if the standard interpretation of the y coordinate goes upwards on the screen, I’d use negative y coordinates.
It’s easy to code, it keeps position and size decoupled, and you don’t need to look at size information to interpret coordinates in data structures.
I wouldn’t change coordinates for an existing library, @icamefromspace is totally right with that, At the very least, an existing library would need to stay compatible, i.e. offer additional coordinate systems as an option, don’t require all client code to be rewritten. It’s about the worst thing you can do.
For a new GUI library, negative Y is an option to be considered.
@toolforger said: Well, getHeight()-y combines final total height and coordinates. That can be a problem when you want to do coordinates first and total height later (maybe because you don't know the number of items beforehand, or similar situations). Or if you increase or decrease the number of items, you need to adjust coordinates in items that don't actually change place. That's all possible but extra code you write.Personally, if the standard interpretation of the y coordinate goes upwards on the screen, I’d use negative y coordinates.
It’s easy to code, it keeps position and size decoupled, and you don’t need to look at size information to interpret coordinates in data structures.I wouldn’t change coordinates for an existing library, @icamefromspace is totally right with that, At the very least, an existing library would need to stay compatible, i.e. offer additional coordinate systems as an option, don’t require all client code to be rewritten. It’s about the worst thing you can do.
For a new GUI library, negative Y is an option to be considered.
Yeah, I’ve suggested -y in this thread a couple times. You can then just translate the gui node to whatever makes that appropriate and keep the getHeight() part out of any layout stuff. And it’s infinitely easier than the alternative. 
Seems like because nobody is believing him here luke decided to give his best to discredit the engine on devmaster :roll:
http://devmaster.net/devdb/engines/jmonkeyengine#user-reviews
His explanations about its biggest flaws boil down to “SimpleApplication is a stupid name” (we’ll fully give you that one mate), “Theres stuff in there that doesn’t work 100%” (you definitely were not a jME2 user), “I don’t like the class names” (Duh) and “Theres methods in the interfaces I don’t use” (Duh, plus - Ever heard of compiler inlining?). And of course, the main corpus delicti – “The developers don’t want to implement my change suggestions”. With the hilarious addition of “They are the only ones who have the ability to add and change stuff [in this Open Source Engine]” – Wait, what? Who taught nehon that secret knowledge then? xD
I wonder what other open source game engines with complete SDK he really compares jME to when saying he doesn’t understand how its getting such a high rating? 
Given that he wants to attest the engine a sub-par rating I guess thats a great review ^^
Well, he does have a valid point around GUI as a weakness, even if he’s off the mark with every single reason he’s giving about WHY it is a weakness.
Of the rest, I’d expect that a neutral reader will see for at least a third of his points that they’re just nitpicking, and that that’s going to weaken the overall impact of that review.
@toolforger said: Well, he does have a valid point around GUI as a weakness, even if he's off the mark with every single reason he's giving about WHY it is a weakness. Of the rest, I'd expect that a neutral reader will see for at least a third of his points that they're just nitpicking, and that that's going to weaken the overall impact of that review.
Nobody ever said its perfect but compared to what was going in jME2 GUI wise we have a way better stand today. In jME2 times many people ran into platform compatibility issues (!) if they didn’t research and reimplement GUI options for months 
There were multiple GUI libraries all with varying support and compatibility issues. Basically what you would have now if you took Nifty out
I don’t think anything this large could be perfect, even if it was funded and done by a large corp.
Also totally impossible to cater for everyone’s needs or ideas of “what’s right”.
Windows for eg, plenty of “undocumented bugs”
and I’ve never had a “perfect” linux distro either
Just something people have to accept, jME had enought to go with and if it lacks anything or something isn’t how you want it there is enough in the core to build it how you need it, just may require a bit more effort.
I hated terrainGrid, so I build my own version, I accepted that as a challenge to me, not a let-down from the devs.
</ my-2c> 
2 Likes