On Wed, Feb 29, 2012 at 3:45 AM, Philippe <[email protected]> wrote:
> ok. I will try to manage the mouse_events from layers.
> Layers are then a kind of event manager then.
>
>
They have the machinery needed to register-unregister listeners, yes.
> But sometimes, it does not seems the most natural way to handle
> things.
> Maybe I am wrong, but I use Layers when I need to place my sprites in
> all the window.
> That means that the (0,0) is the one from the window.
>
>
Thats a limited point of view. If you place a sprite in (0, 0) of a Layer,
it may be the bottom left window's corner or not, because the layer
position, rotation and scale can be anything.
By example, you can build your spaceship both as
Spaceship_Layer
Hull_Sprite
Component1_Sprite
Component2_Sprite
or as
Hull_Sprite
Component1_Sprite
Component2_Sprite
The first should be well behaved in relation to events.
Sometimes, I have a more complex stack of Sprites (like a spaceship
> made of many components). It's then, sometimes, more natural to
> positionned each Sprite relative to another origin (spaceship center).
>
Thats the way scenegraphs works: you pin things in relation to the most
convenient node.
And you are free to add nodes like Layer or CocosNode with the only purpose
of making a convenient group.
> Not the (0,0) of the window.
> So, I subclass Sprite, and fill it with other Sprites.
>
> Then, I come in the case when it's also more natural to handle
> mouse_event in that Sprite class instead of the parent Layer.
>
>
It can be reasonable that the reactions to IO will be handled by the object
controlled by the human player, but that not necessarily means that Sprite
must catch the event.
By example you can:
Let Worldview, a Layer which contains all entities in the game level,
receive mouse and key events.Then, it can immediately relay the events to
the player entity, or it can store the info and pass it to player when the
Worldview.upate kicks in.
In a MVC style, a controller Layer would receive user events, pass to the
model, which will ultimately update the view.
> Is there a good way to handle mouse_event in a Sprite ?
Looking at the director.window._event_stack while running your script I
think no.
> Seems that
> even if in the on_exit I pop_handlers, the sprite still receives it.
>
> Is there a more explicit way to remove an handler from my Sprite, in
> the on_exit ?
> better than director.window.pop_handlers()
>
>
The interactions between pyglet EventDispatcher class and cocos event
related code should be studied to answer that.
If you replace in your script the line
director.window.pop_handlers()
with
director.window.remove_handlers(self)
the double call does not happen, but I don't know if something else will
broke.( Feel free to try and report :) )
I intend to look at this issue and other event related in coming days, will
post any interesting finding.
> as for Issue 163, I totally agree with it. The natural way seems more
> to be from front to back.
It will have a cost, both in cpu and code complexity.
How much ?
Should we support two event routing models, one lean and mean and other
more complex ?
Tentative code should be written.
by the way, how can I help improving cocos2D ? I do not have 8 hours
> per day for it, but I can spend some time.
>
>
Multiple ways:
- if you find some documentation missing or obscure, you can write a
better one (reading the code, asking in the list, writing some simple demos
to know what to write)
- if you are familiar with certain cocos subsystem and think it can be
better, review it, and fell free to propose changes.
- do something interesting with cocos and show it. (be it a game, an
abstract scene, an effect, ...)
claudio
--
--
You received this message because you are subscribed to the Google Groups
"cocos2d discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cocos-discuss?hl=en.
