tonegodGUI Button behavior differs at different resolutions

Troubleshooting gui
1

This is a weird problem I’m having. On most resolutions, this problem goes away, but resolutions like full-screen Have this issue.

I have two buttons on a window. When I click them, one quits, the other takes me back to the home screen.

The issue is, when in full screen resolution, the buttons can’t be clicked. Or, rather, they can’t be clicked because the hover and pulse effects are even being picked up. However, after moving around the window for like, 2 minutes, sometimes, a button becomes clickable. But only if the window is dragged to certain parts of the screen.

Here’s what I’m talking about: [video]http://youtu.be/pC67VFez5HY[/video]

Whenever the window is still, I’m actually hovering over the button and demonstrating that it’s not clickable. Then, all of a sudden, I found a spot where the hover effect is kicking in, and so it is clickable.

    [java]quit_button = new ButtonAdapter(screen,"quit", new Vector2f(0, 0), new Vector2f(screen.getWidth()/10, screen.getHeight()/15)) {
        @Override
        public void onButtonMouseLeftUp(MouseButtonEvent evt, boolean toggled) {
            app.getInputManager().removeListener(actionListener);
            quit = true;
            app.stop();
            //throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
        }

        

    };
    quit_button.setText("Quit");
    quit_button.setPosition(20,20);
    quit_button.setFont("Interface/Fonts/HumboldtFraktur.fnt");
    quit_button.setFontSize(fontSize);
    quit_button.setTextPosition(0f,0);
    quit_button.setTextAlign(BitmapFont.Align.Center);
    //quit_button.setTextVAlign(BitmapFont.VAlign.Top);
    window.addChild(quit_button);
    
   
    
    Label unpause = new Label(screen,"unpause",new Vector2f(0,0),new Vector2f(200,50));
    unpause.setPosition(20,window.getHeight()-unpause.getHeight()-5);
    unpause.setText("Hit 'P' to play");
    unpause.setFontSize(fontSize);
    unpause.setFont("Interface/Fonts/KnightsQuest.fnt");
    window.addChild(unpause);
    
    main_button = new ButtonAdapter(screen,"main", new Vector2f(0, 0), new Vector2f(screen.getWidth()/10, screen.getHeight()/15)) {
        @Override
        public void onButtonMouseLeftUp(MouseButtonEvent evt, boolean toggled) {
            home = true;
            app.getInputManager().removeListener(actionListener);
            app.getStateManager().detach(app.getStateManager().getState(PauseState.class));
            //throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
        } 
    };
    main_button.setText("Home");
    main_button.setPosition(window.getWidth()-main_button.getWidth()-20,20);
    main_button.setFont("Interface/Fonts/HumboldtFraktur.fnt");
    main_button.setFontSize(fontSize);
    main_button.setTextPosition(0f,0);
    main_button.setTextAlign(BitmapFont.Align.Center);
    //quit_button.setTextVAlign(BitmapFont.VAlign.Top);
    window.addChild(main_button);[/java]
2

Try adding the quit button after you add the label and see is this help clear up the issue. The problem is related to BitmapText behavoir.

3

How is BitmapText complicit in this? I have not seen this issue at all. Sounds more like a picking problem.

Or are you doing picking directly against the bitmap text quads? (That will always be problematic since the character quads can be quite small and generally users expect to be able to click a larger area.)

4

Note: there was a fix applied to trunk for an issue in BoundingBox:
http://code.google.com/p/jmonkeyengine/source/diff?spec=svn10785&r=10785&format=side&path=/trunk/engine/src/core/com/jme3/bounding/BoundingBox.java&old_path=/trunk/engine/src/core/com/jme3/bounding/BoundingBox.java&old=9840

…it has never been applied to the stable branch. I think it only affects 3D picking, though, as screen picking should be only in the z axis.

5

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?

6
@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?

Yes, but the GUI library is, I remember reporting this issue a while back, but at the time it was not clear as to what the issue was. The above could fix the issue you are seeing.

As for the window.addChild, The position you set initially is y axis top-down. After you add the control, the y axis is flipped as normal. So you would want to set the button position to window.getHeight()-button-getHeight-whateverMarginYouWant.

7

Oh… how are you adding the window to the screen? Are you using screen.,addElement(window); ?

8
@pspeed said: How is BitmapText complicit in this? I have not seen this issue at all. Sounds more like a picking problem.

Or are you doing picking directly against the bitmap text quads? (That will always be problematic since the character quads can be quite small and generally users expect to be able to click a larger area.)

This issue revolves around BitmapText. If it has to do with the BitmapText boundingBox and picking, then so be it, but… if the button was created without the text element, this problem doesn’t happen. I’ve seen this issue before and tested without creating the text element (which is BitmapText… no changes… just the standard BitmapText).

EDIT: I guess there is the potential of this just being any nested element, however, I’ve not been able to reproduce this other than the above scenario.

9

@t0neg0d:

Yeah, I’m doing screen.addElement(window);

I tried adding the quit button after the label, but nothing changed. I also added the quit_button to the window before setting anything and I commented out the position change. That made it so that at full_res, the hover and click effect of the button would only occur if I hover over the top left corner of the button.

When you said “the above could fix what you are seeing” were you referring to the patch pspeed mentioned?

10
@t0neg0d said: This issue revolves around BitmapText. If it has to do with the BitmapText boundingBox and picking, then so be it, but... if the button was created without the text element, this problem doesn't happen. I've seen this issue before and tested without creating the text element (which is BitmapText... no changes... just the standard BitmapText).

EDIT: I guess there is the potential of this just being any nested element, however, I’ve not been able to reproduce this other than the above scenario.

But from picking’s perspective, BitmapText is nothing more than a mesh of quads.

11
@machspeeds said: @t0neg0d:

Yeah, I’m doing screen.addElement(window);

I tried adding the quit button after the label, but nothing changed. I also added the quit_button to the window before setting anything and I commented out the position change. That made it so that at full_res, the hover and click effect of the button would only occur if I hover over the top left corner of the button.

When you said “the above could fix what you are seeing” were you referring to the patch pspeed mentioned?

It’s possible that it could. I’m not sure what the issue is yet. After today, the holidays are over and I’ll be back on this (and a few other things as well)

12

That’s fine. I’m trying to release this game this Sunday, because that’s when my break ends. But take your time. At least, don’t feel pressured because of me. There are workarounds I can use =D

13
@machspeeds said: That's fine. I'm trying to release this game this Sunday, because that's when my break ends. But take your time. At least, don't feel pressured because of me. There are workarounds I can use =D

To help me track down the issue, can you comment out the following lines from the code above and tell me if you still see the issue?

[java]
quit_button.setText(“Quit”);
// and
main_button.setText(“Home”);
[/java]

14

Commented out. Issue still present.

15
@machspeeds said: Commented out. Issue still present.

And does this happen in all fullscreen modes?

16

In every other resolution (being windowed), it’s fine. If I go to fullscreen, my resolution being 1366 x 768, it doesn’t. However, if I go fullscreen, but use a 640x480 (ugh), it works just fine. Weird…

17
@machspeeds said: In every other resolution (being windowed), it's fine. If I go to fullscreen, my resolution being 1366 x 768, it doesn't. However, if I go fullscreen, but use a 640x480 (ugh), it works just fine. Weird...

This leads me to believe that this is a JME issue. The library does ABSOLUTELY NOTHING different when switching resolutions. And even more odd, I noticed something similar a while back… then I couldn’t reproduce the issue. And now someone else is seeing it again.

I will continue to look into this as a library specific issue, however, can you tell me again what your workaround is. Is it adding the top level element to the screen prior to adding children? If this is the case, it is possible that the bounding boxes for child Nodes are not being calculated properly when added to the screen. Which will give me something to report to core devs.

18

If it’s not related to your library then it should be relatively easy to find a test case that illustrates the issue.

It would be interesting to see what causes it to not work in these cases while still working in other GUIs.

19

Well, at least I’m not the only one who has/had this issue…

Well, you see, I have two workarounds. Either lock it in a windowed state, or replace the buttons with a “Hit ‘Q’ to quit” sort of a think.

In a windowed state, it always works just fine. In a fullscreen state, it works on every resolution except, I guess, when the screen autodetects my resolution. If I select one close to mine, 1360x768, then it works, just not on the autodetected res, 1366x768. Stupidest thing I’ve seen.

20
@machspeeds said: Well, at least I'm not the only one who has/had this issue...

Well, you see, I have two workarounds. Either lock it in a windowed state, or replace the buttons with a “Hit ‘Q’ to quit” sort of a think.

In a windowed state, it always works just fine. In a fullscreen state, it works on every resolution except, I guess, when the screen autodetects my resolution. If I select one close to mine, 1360x768, then it works, just not on the autodetected res, 1366x768. Stupidest thing I’ve seen.

That does seem awfully specific. I wonder if the reshaped resolution is actually the same as the one you are being told is autodetected or something strange there.