Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (562)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  UI/mouse detection  (Read 380 times)
0 Members and 1 Guest are viewing this topic.
Offline jonstar

Junior Newbie





« Posted 2013-10-04 15:47:24 »

Hello and thanks for this site!

I'm not a new programmer but I am new to game programming.  I am amazed at how the solutions to some things, like collision detection are not what I expected.  I thought there was more magic to it.  For instance Pong, even if the ball is far away from the paddle, collision is checked each frame. 

Last night I was trying to work out how to do a UI/Overlay/Options menu system on my own and I wondered, "How in the world do I know if the mouse is over a particular component?".   After a time I started just playing with collision detection to see if the current x,y position of the mouse not just collided but is within a rectangle boundary that contains the component.  Instinct for me is this is overkill, just way too much.  Every frame I check to see where the mouse is and if it's within a rectangle.  That's crazy!  Then my thought of managing multiple UI elements was to have a list of them with their details -- that would mean that each frame I would have to iterate over the list of UI elements and see if the mouse x,y is within any of them -- that just feels like using soooo much processing power and that I'm doing it wrong, that there is a more direct approach.

Is this really how I should approach it?

Thanks!
Offline CodeHead

JGO Knight


Medals: 41


From rags to riches...to rags.


« Reply #1 - Posted 2013-10-04 16:04:13 »

That's pretty much the way most frameworks handle it. No matter what the approach, you end up doing a lot of "contains" checks. Depending on how you structure things, you don't always end up iterating over all of your controls. Usually you check for some sort of top level control at a given mouse position, then iterate over the subset of controls within the top level container.

Any which way you cut it, it sounds like you're doing premature optimization from gut feelings. A better approach would be to mock up some controls, and use a profiler to see how bad the "problem" actually is. From my experience, unless you're rendering a ton of controls, there really shouldn't be a significant impact.

Arthur: Are all men from the future loud-mouthed braggarts?
Ash: Nope. Just me baby...Just me.
Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #2 - Posted 2013-10-04 16:43:21 »

UIs are best implemented as a 2D scene graph, so you can look at how input is handled there. Eg:
http://code.google.com/p/libgdx/wiki/scene2d
In scene2d, you have an Actor class which is a basic node in the scene graph. You also have a Group class which is an actor that has a number of actor children. Hit detection is done by asking the root group to check its children. This is recursive since children could be a group that check their children, etc. If an actor reports it was hit, recursion stops and that actor is reported as being hit.

In scene2d, it is unnecessary to set the width and height of your group so it encompasses all the actors. Doing so would be a huge pain if you just want to use the group for translation, rotation, and scaling. So, scene2d lets actors be positioned outside of their parent group's bounds. This means the default hit detection method for group always checks all children, since it can't shortcut just because the hit location is outside the group's bounds. How bad is this? Well consider this complex UI:



scene2d does hit detection for the mouse each frame, so it can fire enter/exit events. The worst case is when the hit location doesn't hit any actors, since all actors will be checked. In this UI 220 actors are checked each frame (68 of those are groups). If the mouse is held down it has to check again, so this doubles. Still, this is not an issue at all on the desktop. If your UI is less complex, there is even less reason to worry.

Still, there is no reason to be inefficient. scene2d.ui is a UI toolkit built on top of scene2d. It has Widget which is an actor and WidgetGroup which is a group. These are specialized actors and groups which know how to do layout and other stuff commonly needed in UIs. Unlike low level scene2d usage for games, when building UIs it is normal to set the bounds of a group so all children are within the group. So, I changed WidgetGroup to not check the children if the hit location is outside of the group. Doing this drops from 220 actors checked each frame in the screenshot above to 21. The whole UI continues to work, so I'll commit to git. Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jonstar

Junior Newbie





« Reply #3 - Posted 2013-10-04 17:30:32 »

Thanks to you both!

Quote
scene2d does hit detection for the mouse each frame, so it can fire enter/exit events. The worst case is when the hit location doesn't hit any actors, since all actors will be checked.

I embrace!  I don't know what magic I thought was going on behind he scenes to determine if a cursor was over an element, but I'm clear now.   I'm still amazed that that's the way it is, but I'm content.

Nate, thank you for such in depth coverage of scene2d and scene2d.ui.  I work on these things with my son and he flipped over Spline.  He does a lot of his animations in Pixen currently and is passing out over what Spline can do!  I learned about more than I asked for, thank you again.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (28 views)
2014-09-21 02:42:18

BurntPizza (18 views)
2014-09-21 01:30:30

moogie (19 views)
2014-09-21 00:26:15

UprightPath (27 views)
2014-09-20 20:14:06

BurntPizza (29 views)
2014-09-19 03:14:18

Dwinin (45 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (100 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56

mitcheeb (71 views)
2014-09-08 06:06:29
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!