Jump to content

  • Log In with Google      Sign In   
  • Create Account


Detecting when libRocket GUI handles input


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 AaronWizardstar   Members   -  Reputation: 244

Like
0Likes
Like

Posted 04 June 2013 - 04:43 PM

I'm giving libRocket a try (again).
 
When sending input events to a libRocket context, how would I tell whether or not libRocket handled the input? Because if libRocket didn't handle the input I'd want to pass it to my main game logic. If I have a game map with a GUI on top, I'd like to tell whether or not I clicked on the GUI or on the map, since if I just clicked on the GUI I don't have to pass the input to the map logic.
 
After looking at some sources and docs, it looks like there actually isn't way to tell whether or not libRocket handled the input. Apparently all of my interactive game objects are expected to be in some kind of libRocket element, including my game map. Not really ideal in my opinion, but it's something I might be able to work with if someone confirms that this is the case.
 
I tried asking this on the libRocket forums, but it doesn't seem to be that active anymore. unsure.png


Sponsor:

#2 Jan K   Members   -  Reputation: 531

Like
0Likes
Like

Posted 05 June 2013 - 09:55 AM

One idea would be to insert a "background element" into your UI, which stretches across the entire context and then attach an event listener to that, which detects mouse-move events. So when you know your mouse moved and inject that into Rocket and your listener on the background element does not get a mouse-move event, then rocket handled it internally for some other element (same for mouse clicks).

 

You could actually just take the data from the background element and feed that back into your engine (mouse-moves / clicks / etc.).

 

I haven't tried this, have just stumbled across Rocket and this particular issue and would be interested in hearing, whether this solves this important issue, so let me know what you come up with.



#3 AaronWizardstar   Members   -  Reputation: 244

Like
0Likes
Like

Posted 07 June 2013 - 09:25 PM

Yeah, that's what I've ended up doing, and it's what the "space invaders" sample project that comes with libRocket seems to do anyway.

 

Specifically I've created a GameDocument class that subclasses Rocket::Core::ElementDocument. This wraps the base input, updating, and rendering of the game itself. To use it I created a subclass of Rocket::Core::ElementInstancer called GameDocumentInstancer. The GameDocumentInstancer sets a new GameDocument's width and height attributes to "100%" to make it cover the screen and its z-index attribute to "bottom" to make sure the GameDocument never floats to the top over any standard documents.

 

I could have also just subclassed Rocket::Core::Element, but then I'd need a separate RML file containing the game element with the width, height, and z-index attributes set correctly.

 

The only thing I'm left with now is how to make key input "default" to the background game document. If I click on any control besides the game document, key events don't go to the game document until I click it.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS