I would wonder that too, but u have to remember, this only occurs in the window in this state. I have a main menu state before this, with 4 buttons. They aren’t in a window, just attached to the screen, and they work fine with any res included autodetected fullscreen.
@machspeeds said: I would wonder that too, but u have to remember, this only occurs in the window in this state. I have a main menu state before this, with 4 buttons. They aren't in a window, just attached to the screen, and they work fine with any res included autodetected fullscreen.
Can you println the bounding box info of the button nested and unnested and see if the extents are the same?
Internally to the library, it uses Node.attachChild(whateverNode) … nothing more than this… The geometry and mesh bounds are updated properly, or the application would crash on the first frame the new node was added. The only reason attachChild is a passthrough is it gives the element class a chance to store relevant information. Hide and show, for instance, use removeFromParent() and parent.attachChild() but still keep the internal reference to update nested elements on resize and such.
@machspeeds said: I'm just using the Button the way a button should be used. I'm not doing any picking against the bitmap.Funny though. Putting the window.addChild(quit_button) before setting it’s position and text makes it work in full screen, but not in 640x480 res (albeit the position is wrong now). I’m not sure why though. And how does the bitmap change things, t0neg0d?
This is what has me puzzled. If the order is reversed (i.e. add the window, then add the button) the picking happens correctly. If you add the button to the window, then add the window to the guiNode, picking happens incorrectly in SOME screen resolutions.
@pspeed In what order does your gui library append nested elements? In this case, it is up to the user and one seems to be problematic while the other isn’t.
@machspeeds said: I would wonder that too, but u have to remember, this only occurs in the window in this state. I have a main menu state before this, with 4 buttons. They aren't in a window, just attached to the screen, and they work fine with any res included autodetected fullscreen.
Can you do me one more favor and try adding a DialogBox to your screen and see if you have the same issue with those buttons.
@t0neg0d said: This is what has me puzzled. If the order is reversed (i.e. add the window, then add the button) the picking happens correctly. If you add the button to the window, then add the window to the guiNode, picking happens incorrectly in SOME screen resolutions.@pspeed In what order does your gui library append nested elements? In this case, it is up to the user and one seems to be problematic while the other isn’t.
I don’t understand the question. Nodes are attached in the order they are added I guess. It’s a standard scene graph hierarchy.
How are you doing your picking? Are you only hitting nearest or something? Ray direction is 0, 0, -1?
To the OP, what version of JME are you running? 3.0.x or trunk?
Okay, hold on. Catching up on everything I was asked…
Dimensions while attached to window: (136.6, 51.2)
Dimensions while not attached to window (attached to screen): (136.6, 51.200012) Also, whaddya know, this one works.
a.k.a, small (hope that’s what you meant by extents.
Now for the DialogBox. When you said “those buttons” I wasn’t sure if you were referring to my buttons or the buttons that come with it. No matter, I tested both.
Buttons that came with the DialogBox: worked
Placing my buttons on top: the Quit Button in the top left worked perfectly. The Home button in the top right worked somewhat. Only hovering in specific sections worked, which leaves me flabbergasted.
@pspeed:
I’m running 3.0.3, not trunk
@pspeed said: I don't understand the question. Nodes are attached in the order they are added I guess. It's a standard scene graph hierarchy.How are you doing your picking? Are you only hitting nearest or something? Ray direction is 0, 0, -1?
To the OP, what version of JME are you running? 3.0.x or trunk?
What order:
Do you attach children prior to attaching to the scene?
Or
Do you attach attach components in the order they are defined? i.e. window to screen, button to window.
There is a difference. And in this case attaching the components in order works without hitch, the other is problematic in some cases…
@t0neg0d said: What order:Do you attach children prior to attaching to the scene?
Or
Do you attach attach components in the order they are defined? i.e. window to screen, button to window.
There is a difference. And in this case attaching the components in order works without hitch, the other is problematic in some cases…
Sometimes I attach one node to another and then attach them to the rootNode/guiNode. Sometimes I attach them to the guiNode first and then attach child nodes later. (My HUDs are frequently built up that way with children being added and removed at runtime.)
I’ve never seen any issues.