Return scaled center coordinates for widgets #258
Conversation
The button width / height return the center values of the native button. At larger scale modes, the disparity grows enough that other buttons can sometimes be pressed when overlapping each other because it doesn't return the actual center coordinates.
DigiEggz
changed the title
|
Can I get a simple test case that quickly highlights the benefit of this change? |
|
The widget function I made red X marks render where the widget reports its center is at a scale of 3x. The green X marks render at a scaled resolution of 10x. The marks should always overlap, no matter the scale mode. For clarity, here is what the buttons bounding boxes look like:
Reported centers before the change:
Reported centers after the change:
In the "before the change" section, you can see the button centers report different values (from the misaligned X marks) when the game is at a different scale factors. The red X locations are also very high up on the button and not actually centered, either. |
|
To summarize, create a list of widgets for a FlxUICursor to traverse. Then enter fullscreen at different screen resolutions. The cursor always reports the original coordinates instead of the new scaled coordinates. This causes issues clicking buttons, especially so with larger scale factors. |
|
sorry for the holdup, been really busy, can you merge the dev branch into this to fix CI, I'll try to get to this soon Edit: Thanks! |
|
I'm finally looking into this, and I don't quite understand the issue, you mark invalid centers on your images, but when I run the Cursor Demo with a scale of 4 I get no issues with clicking or the cursor's position. (note that the demo currently has a scale of 2) How are you achieving a totalScale of 3, or 10. And what actual code is failing that depends on these centers? Screen.Recording.2023-12-22.at.12.38.06.PM.mov |
|
FlxUICursor uses You will not experience any issues at smaller resolutions because the disparity is not large enough to cause errant clicks, depending on your button size. As the scale size increases, the difference of the "center" becomes to large that it starts to overlap other buttons. You can see that the center is wrong by tracing out the center coordinate of any widget. The value should change with the scale size. The X's were placed programmatically. You can see that the "center" location is too high in the first section and it only gets worse as the scale size grows. |
|
@DigiEggz I'm still not seeing it even with very large scales, does this happen to you with the Cursor demo? I need a solid way to reproduce this issue Here's at least 5x scale |
|
I'll work on something to show you soon. Happy holidays! |
|
I've attached a sample project. Please excuse the absurd verbosity—I tried to make this as fast as I could because I have an event and need to head out. Use the arrow keys to traverse the list and then press the X key or Enter to select a button. Press the S key to view the current scale. At lower scale factors, the button presses normally. Next, either drag the window or go fullscreen with F. At any scale factor of roughly 6.5 or greater, multiple buttons are pressed when you press X or Enter. It also traces out multiple keypresses at once. |
|
I tried the demo, I cannot see a difference in behavior with or without this change. fullscreen seems to have no effect on my behavior, either. No matter what, FlxUICursor presses multiple buttons when I press X, with this change, without it, fullscreen or not. I also see no change in the behavior of mouseover I'm on mac, my fullscreen scale is 12, I don't know if you're on windows or linux or something but I can try those. is your scale an integer, like mine? maybe the issue is more noticeable at, say, 6.5, than 7.0? Also there's no urgency on this, feel free to come back to this after the holidays, I know this time can be hectic for some Edit: also the fact that I can ever press more than 1 button is an indicator that FlxUICursor is set up weird, I don't think this is an issue of "widgetPoint" being off, but perhaps that FlxUICursor is using it's position to determine whether it's pointing at multiple widgets |
|
That's very strange. I've also been testing on macOS, so the difference may lie elsewhere. Once my scale grows greater that a certain value (in this case ~6.x), the drift is large enough that it starts to overlap other buttons. I'll try and make a video when I get the chance. If you spawn a graphic where the widget center point is, does the center point stay in the same location each time you create a new one at different scales? I noticed that the center point was always reporting the native size values of the widget. Edit: I set up HaxeFlixel on a Windows laptop, installed latest versions of all libraries and was able to reproduce the issue. |
|
I modified the code so that when you press the D key, it will draw an "X" mark graphic at the reported Y-center of the FlxUICursor's current widget. The mark should always render at the same location, regardless of scale. When I test it with the old code, the mark location changes depending on the scale. |
|
Sorry for the hold-up just needed to make sure I could reproduce the actual symptoms |
The button width / height always return the center values of the native button. At larger scale modes, the disparity grows enough that other buttons can sometimes be pressed when overlapping each other because it doesn't return the actual center coordinates.