-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved Mouse Support #380
Comments
As for getting the mouse input and handling it, there is a class called CCInputState that is designed to handle general input controls. You should be using CCInputState to get the current input device state, which will give you a wide variety of inputs that can be processed with every update() call. You should only poll the input state in the update() call, and only in the CCDirector's update method. Then when you get an input state update, you propagate that object state to all of the input listeners. The CCDirector should have a method to manage the receivers of CCInputState. You could add some event handlers that take the CCInputState as their signature. Then in your CCNode, you could have an option to register with the input state handler in CCDirector. |
thx for help, Update 2014 05 06
|
I see what you are after now. Supporting proper mouse activity like hover actions will require the changes you are proposing. Thanks! |
I updated my code, its still buggy since i still not understand the coordinate systems well enought, but thats not the problem, i will come behind it somesays :D, and i have to get rid of the dirty hacks in it (now.Subtract(m_lastMouseClickHandled).TotalMilliseconds > 50)... another problem i encountered is the clicking on overlapping areas. Since you know much better than me, have you any tipps ? |
I have an issue for the z-ordering of clicks on overlapping nodes. Right now the touch passes through all of the touch handlers until it finds one that processes it. That usually does not work because the touch handlers are not re-ordered in LIFO order. To fix this in cocos2d-x they used the global Z ordering, which we do not have in cocos2d-xna. |
yeah, i just saw your entry for this Issue. #396 |
I am not sure. Consider the case of highly nested nodes with deep ancestry. You need to know the rank of the tree so you can compute a sufficient number space to contain each of the branches in the tree. The worst part is that this tree will change constantly, so it can become computationally hard with respect to fast performance during the update() loop. I suppose each time a child is added to a parent you could increase the branch count back to the root (when a new child is added). Hmm. That could work to give us the tree rank in real time. Then it's just a matter of applying a magnitude factor, e.g. 10x, on each branch rank and filling in the global z-order for the nodes using their local z-order as the minor. A (3) <- B (2) <- C(1) Z(A) = 103, Z(B) = 102, Z(C) = 10**1 Z(C[n]) = Z(C) + C[n].zOrder * normalization_factor |
ok, thank you for your help, |
i prototyped my idea - seems to work - if i understood the ZOrder / Node.Children correctly.
|
This looks like it would work if the zOrder is maintained as a global z-order by the programmer. |
what I am considering is a global z-order that is computed as nodes are added, removed, and updated in the draw tree. Then use that global z-order as a priority value in the touch handler interface to sort the touch dispatcher targets in a proper priority order. |
what do you mean "if the zOrder is maintained as a global z-order by the programmer" ? yeah the prototype has no life update yes, i wanted to do this as well, thats the reason, why i have the m_lookup dictionary, what is completly useless in the current implementation. it shall be used if something is changing in the tree the keep the tree sync very fast. as far i tested, my implementation is satisfying for me right now, since i only need to update the tree, if really a click is happening:
|
The current problem with zOrder is that many nodes can have the same zOrder value. That makes the zOrder local scoped instead of global. I started the refactoring of the touch handler to take the TouchPriority from CCNode when the priority is not specified. Currently, the priority is always set to zero, so my refactoring code is not being exercised yet. |
ok thanks for the detailled explaination. |
You are understanding the problem more clearly now. Often times, even in cocos2d-x, the node's bounding box is the entire window, so the bounds check is useless. The only reliable solution is to set the touch priority on the node so that it can handle the touches properly. Once the touch is in the node, it should know whether or not it is in relevant content. There may be times when you want to handle a touch that exists outside of your bounding box ... so I don't think that check is useful. |
Send us your mouse support changes and we'll merge them in. Then we can tackle the touch/mouse priority handling... |
thanks for the offer, its really an honor. Actually its still a prototyp and currently i am switching from "per node handling" of the click to a cenral handling,Ffurthermore i want to build the solution on the touch implementation instead of retrieving the mouse position from MonoGame. but i need still to dig deeper in the possibilities and impossibilities of Cocos2D. So for a merge its far to early, unless you need it right now and are willing to complete it by yourself. |
hmm actually i think about supporting the right and middle mouse key as well, |
MonoGame does not simulate the mouse on touch devices. I have no qualms about supporting platform-specific input. Our framework is the layer that is supposed to handle that type of support. |
thx, good to know, i am still working on it, made some improvements yesterday, so stay tuned. |
Ah, so tunneling is how the framework currently propagates touches, but does so in a mostly unexpected manner. Once the nodes are properly sorted by draw priority, then the WPF tunneling protocol will also map to the touch/mouse propagation in cocos2d-xna. Bubbling is curious I suppose. I suppose a game could respond to deep click/touch events and bubble the event up the draw chain. on z-order, or draw order, you COULD just keep a priority queue that is rebuilt any time the sortChildren method is invoked without short circuiting. That would mean only building it only now and then, and you could even get clever and reconnect the list at a specific node that is causing the order break. The priority value would still be the draw order of the node, implemented as a simple list of nodes and using reverse iteration to process touches and mouse. the draw loop always computes the proper order of the nodes for focus. ah, focus, something I started to implement for xbox support to handle menu item button actions properly. |
hi jake, i dit not change my implementation the last days. Its still a prototyp, but actually it works for me. i only consider the parent/child relation of my nodes. so i wont change it for a while, sorry about that. |
Hey guys. Just some input here. The Cocos2D-X has a new EventDispatcher implementation that really does everything you are talking about. It would be a little work but probably less time than what you are spending on getting that implemented in cocos2d-xna right now. Take a look here: http://www.cocos2d-x.org/wiki/EventDispatcher_Mechanism There are a few classes that need implementing for sure but it really is flexible and takes care of everything you have outlined and have been discussing. It will also work for any of the events that you want to create not just mouse events, for example keyboard events. Just a thought. |
Thanks Kenneth! The v3 Event Dispatcher is pretty much how events are dispatched in -xna. We just encapsulate the delegate into the body of the CCNode instead of leaving it dangling as an anonymous implementation (per the v3 example).. We definitely need to improve how the node priority conveys to input delegation. The real problem, beyond scene graph priority, is focus. When I did the xbox implementation the first problem I had was menu selection. There is no cursor and no concept of touch on a console, so you have to focus on nodes and delegate input to the focus node. That's where the focus manager was born. I stopped work on the focus code when I realized that it did not convey well to the CCNode's encapsulation of the input delegates. That part of the framework needs the most attention nowadays. |
I am working on a cross platform game, and Cocos2D-XNA currently lacks on Mouse Support. So i started to write my own implemention.
I see that the other platform specific input devices are hold together via interfaces and implemented on CCNode.
These are: ICCTargetedTouchDelegate, ICCStandardTouchDelegate, ICCTouchDelegate, ICCKeypadDelegate, ICCKeyboardDelegate.
According to this, the next logical step is to create new interfaces, and implement them on CCNode ?
Thats what i have got so far:
The Tooltip thing may be Bloadware, and i am unsure if its clever to implement it on CCNode.
Major problem currently, i sheduled the Node for Updates, and on Update i ask MonoGames MousePosition.
1.) that is not wise to do for ALL Nodes
2.) its unaccurate, i dont get all clicks atm. (Timing Problems)
Am i doing right, or am i on a missleading way ?
The text was updated successfully, but these errors were encountered: