Collision Callbacks
1 view
Skip to first unread message
Eric
Mar 27, 2008, 3:30:43 PM3/27/08
to glaze Engine
Collision callbacks are imperative for game logic. I've looked at
several different AS3 physics engines and have found two that have
partial callback implementations:
APE 0.5a - It's in their trunk. There's a bug in the way the code
works. I'm going to post a fix in the forums in a little bit.
Box2D - People have outlined methods for adding callbacks to the code
but half the time they don't integrate into the Flash Event system.
I can only assume that, as Glaze is being billed as a "2D Rigid Body
Dynamics and Game Engine" that it will eventually include this
functionality. Am I off base? Do you happen to have an ETA for this?
Lastly, great work! I came across Chipmunk earlier today and was
impressed with the speed optimizations. *Very* happy to see a Flash
version (and one where care was used on implementation for the speed
issues in AVM2)!
Thoughts?
several different AS3 physics engines and have found two that have
partial callback implementations:
APE 0.5a - It's in their trunk. There's a bug in the way the code
works. I'm going to post a fix in the forums in a little bit.
Box2D - People have outlined methods for adding callbacks to the code
but half the time they don't integrate into the Flash Event system.
I can only assume that, as Glaze is being billed as a "2D Rigid Body
Dynamics and Game Engine" that it will eventually include this
functionality. Am I off base? Do you happen to have an ETA for this?
Lastly, great work! I came across Chipmunk earlier today and was
impressed with the speed optimizations. *Very* happy to see a Flash
version (and one where care was used on implementation for the speed
issues in AVM2)!
Thoughts?
Richard Jewson
Mar 27, 2008, 3:57:38 PM3/27/08
to glaze-...@googlegroups.com
Hi,
Thanks - took some effort to get it optimized...
As for callbacks - absolutely. I'm not sure how I'm going to implement them yet. Any ideas on what a games programmer would want?
With AS there are a few ways to go, either override a method or register a function (like AS event handlers) - maybe both.
When should the callback fire? Maybe have optional ones for:
- Callback 1 - fired on first frame of contact
- Callback 2 - fired for each subsequent frame of contact
- Callback 3 - fired when objects part contact
What do the other engines do that you've seen/liked?
Thanks - took some effort to get it optimized...
As for callbacks - absolutely. I'm not sure how I'm going to implement them yet. Any ideas on what a games programmer would want?
With AS there are a few ways to go, either override a method or register a function (like AS event handlers) - maybe both.
When should the callback fire? Maybe have optional ones for:
- Callback 1 - fired on first frame of contact
- Callback 2 - fired for each subsequent frame of contact
- Callback 3 - fired when objects part contact
What do the other engines do that you've seen/liked?
Eric
Mar 27, 2008, 5:01:37 PM3/27/08
to glaze Engine
So there's actually a lot of information that would be useful but one
thing we cannot live without: a reference to the object collided
with. If I'm Mario then I want to know what object I've collided with
so that I can appropriately grow, throw fireballs, or... die.
I'd put my money on the AS3 Event system rather than overriding a
method. There are several reasons for this but one important one is
event propagation: you can have multiple Listener objects set to a
specific event and give them priorities. The higher priority
listeners can actually interrupt the standard event propagation -
custom game logic flow! Further, you could easily implement a global
callback by registering the event in your Main class and putting all
your code in there.
I don't quite understand the difference between the three callbacks
you defined. Could you elucidate?
Take a look at how the current APE Trunk handles the callbacks.
Currently there are two events you can watch for: COLLIDE and
FIRST_COLLIDE. I've tested the [fixed] code a bit with simple tests
and it reacts as expected. The pertinent files (in link form) are
listed below:
1) http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractItem.as
- Extends EventDispatcher (required to trigger events, implement
IEventDispatcher works too).
2) http://ape.googlecode.com/svn/trunk/source/org/cove/ape/CollisionEvent.as
- Extends Event, adds "collidingItem" to event:CollisionEvent object.
3) http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractParticle.as
- Insertion point for EventDispatch (look for the "resolveCollision"
and "testParticleEvents" functions in particular).
In testing the Event code I came across a bug and fixed it. I wrote
about it in the APE forums here (very simple fix):
http://groups.google.com/group/ape-general/browse_thread/thread/457a537ecbcfa00f
I use the Torque Game Builder for some projects and they return
information like the Collision Normals as well (which can be extremely
useful at times).
Thoughts?
On Mar 27, 3:57 pm, "Richard Jewson" <rjew...@gmail.com> wrote:
> Hi,
>
> Thanks - took some effort to get it optimized...
>
> As for callbacks - absolutely. I'm not sure how I'm going to implement
> them yet. Any ideas on what a games programmer would want?
>
> With AS there are a few ways to go, either override a method or register a
> function (like AS event handlers) - maybe both.
>
> When should the callback fire? Maybe have optional ones for:
> - Callback 1 - fired on first frame of contact
> - Callback 2 - fired for each subsequent frame of contact
> - Callback 3 - fired when objects part contact
>
> What do the other engines do that you've seen/liked?
>
thing we cannot live without: a reference to the object collided
with. If I'm Mario then I want to know what object I've collided with
so that I can appropriately grow, throw fireballs, or... die.
I'd put my money on the AS3 Event system rather than overriding a
method. There are several reasons for this but one important one is
event propagation: you can have multiple Listener objects set to a
specific event and give them priorities. The higher priority
listeners can actually interrupt the standard event propagation -
custom game logic flow! Further, you could easily implement a global
callback by registering the event in your Main class and putting all
your code in there.
I don't quite understand the difference between the three callbacks
you defined. Could you elucidate?
Take a look at how the current APE Trunk handles the callbacks.
Currently there are two events you can watch for: COLLIDE and
FIRST_COLLIDE. I've tested the [fixed] code a bit with simple tests
and it reacts as expected. The pertinent files (in link form) are
listed below:
1) http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractItem.as
- Extends EventDispatcher (required to trigger events, implement
IEventDispatcher works too).
2) http://ape.googlecode.com/svn/trunk/source/org/cove/ape/CollisionEvent.as
- Extends Event, adds "collidingItem" to event:CollisionEvent object.
3) http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractParticle.as
- Insertion point for EventDispatch (look for the "resolveCollision"
and "testParticleEvents" functions in particular).
In testing the Event code I came across a bug and fixed it. I wrote
about it in the APE forums here (very simple fix):
http://groups.google.com/group/ape-general/browse_thread/thread/457a537ecbcfa00f
I use the Torque Game Builder for some projects and they return
information like the Collision Normals as well (which can be extremely
useful at times).
Thoughts?
On Mar 27, 3:57 pm, "Richard Jewson" <rjew...@gmail.com> wrote:
> Hi,
>
> Thanks - took some effort to get it optimized...
>
> As for callbacks - absolutely. I'm not sure how I'm going to implement
> them yet. Any ideas on what a games programmer would want?
>
> With AS there are a few ways to go, either override a method or register a
> function (like AS event handlers) - maybe both.
>
> When should the callback fire? Maybe have optional ones for:
> - Callback 1 - fired on first frame of contact
> - Callback 2 - fired for each subsequent frame of contact
> - Callback 3 - fired when objects part contact
>
> What do the other engines do that you've seen/liked?
>
Eric
Mar 27, 2008, 5:06:29 PM3/27/08
to glaze Engine
Further regarding the Event system: You can easily *unregister* for
events, too.
- Eric
On Mar 27, 5:01 pm, Eric <ryunokok...@gmail.com> wrote:
> So there's actually a lot of information that would be useful but one
> thing we cannot live without: a reference to the object collided
> with. If I'm Mario then I want to know what object I've collided with
> so that I can appropriately grow, throw fireballs, or... die.
>
> I'd put my money on the AS3 Event system rather than overriding a
> method. There are several reasons for this but one important one is
> event propagation: you can have multiple Listener objects set to a
> specific event and give them priorities. The higher priority
> listeners can actually interrupt the standard event propagation -
> custom game logic flow! Further, you could easily implement a global
> callback by registering the event in your Main class and putting all
> your code in there.
>
> I don't quite understand the difference between the three callbacks
> you defined. Could you elucidate?
>
> Take a look at how the current APE Trunk handles the callbacks.
> Currently there are two events you can watch for: COLLIDE and
> FIRST_COLLIDE. I've tested the [fixed] code a bit with simple tests
> and it reacts as expected. The pertinent files (in link form) are
> listed below:
> 1)http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractItem.as
events, too.
- Eric
On Mar 27, 5:01 pm, Eric <ryunokok...@gmail.com> wrote:
> So there's actually a lot of information that would be useful but one
> thing we cannot live without: a reference to the object collided
> with. If I'm Mario then I want to know what object I've collided with
> so that I can appropriately grow, throw fireballs, or... die.
>
> I'd put my money on the AS3 Event system rather than overriding a
> method. There are several reasons for this but one important one is
> event propagation: you can have multiple Listener objects set to a
> specific event and give them priorities. The higher priority
> listeners can actually interrupt the standard event propagation -
> custom game logic flow! Further, you could easily implement a global
> callback by registering the event in your Main class and putting all
> your code in there.
>
> I don't quite understand the difference between the three callbacks
> you defined. Could you elucidate?
>
> Take a look at how the current APE Trunk handles the callbacks.
> Currently there are two events you can watch for: COLLIDE and
> FIRST_COLLIDE. I've tested the [fixed] code a bit with simple tests
> and it reacts as expected. The pertinent files (in link form) are
> listed below:
> - Extends EventDispatcher (required to trigger events, implement
> IEventDispatcher works too).
> 2)http://ape.googlecode.com/svn/trunk/source/org/cove/ape/CollisionEven...
> IEventDispatcher works too).
> - Extends Event, adds "collidingItem" to event:CollisionEvent object.
> 3)http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractParti...
> - Insertion point for EventDispatch (look for the "resolveCollision"
> and "testParticleEvents" functions in particular).
>
> In testing the Event code I came across a bug and fixed it. I wrote
> about it in the APE forums here (very simple fix):http://groups.google.com/group/ape-general/browse_thread/thread/457a5...
> and "testParticleEvents" functions in particular).
>
> In testing the Event code I came across a bug and fixed it. I wrote
Richard Jewson
Mar 27, 2008, 5:49:01 PM3/27/08
to glaze-...@googlegroups.com
The first two of the 3 callbacks were the same as COLLIDE and FIRST_COLLIDE.
I already have everything required to send these events are the right time, a few lines of code are all thats needed. Any ideas on the performance impact of sending all those events?
At a minimum an body should know what its in contact with, I'm just wondering what use more global event is?
I already have everything required to send these events are the right time, a few lines of code are all thats needed. Any ideas on the performance impact of sending all those events?
At a minimum an body should know what its in contact with, I'm just wondering what use more global event is?
On 27/03/2008, Eric <ryuno...@gmail.com> wrote:
Eric
Mar 27, 2008, 6:34:20 PM3/27/08
to glaze Engine
Yeah, I thought that's what you meant for the first two... the third
one threw me off: what does it mean to have a partial collision? As
in halfway through a physics engine step? Does that even make sense?
I don't think you're going to incur very much overhead by using the
system. You will certainly incur no overhead by not using it. I'm
not sure about your implementation in Glaze but one thing to be
mindful of would be the Event Dispatch Phases. Essentially, if your
event target is in the Display Hierarchy then not only does the your
event target get notified, but all ancestors as well. If the event is
a bubbling event then the ancestors get notified twice. The event
dispatch phase looks something like:
Capture Phase->Target Phase->Bubbling Phase.
If you think of your target as the last link of a hanging chain then
the event system starts at the ceiling hinge, walks down to the last
link and then back up. All ancestors get notified twice, the target
once. This has its utility (especially for display related stuff).
If your target is not in the Display Hierarchy then the event
dispatcher simply notifies your target object directly. That said, I
believe the ancestors also need to register a listener for a specific
event in order to 'intercept' it, etc. anyway. I've no idea on how
Adobe actually implemented it, unfortunately (do they walk the whole
display hierarchy or do they maintain an ad-hoc list, inserting
ancestors in the appropriate position when they notice a descendant
has already registered for an event?). Either way it seems pretty
snappy. And the number of things you'll likely have registered for
events will be pretty small. In my prototype I currently only
register one object so the effects are negligible.
Colin Moock's "Essential Actionscript 3.0" book covers the topic in
depth. See chapters 12 and 21. (It's a fantastic resource overall if
you don't already have it...)
The thing game programmers need to watch out for is heavy code
inserted in these callbacks. The callbacks that merely print [trace]
a statement are negligible. The onus is on the game programmer to
keep their callback code lean and efficient. Also, what utility would
there be in registering callback events for every object in your
pyramid example? You could have them generate sparks with a particle
engine but that would likely be overkill (especially given how much
processing power particle engines in Flash require - dang slowass
Flash renderer...).
By global event do you mean to return a list of collision pairs (pairs
of objects that collided in any given engine step)? In APE, colliding
particles are parts of a group. Perhaps instead of completely Global
you could have Group based globality - during the engine step, accrue
a list of collided objects in a given group and then return that in
the collision event fired at the end(?). There's a bunch of stuff you
could do, really, and I don't have any good use-cases yet. For the
most part, people are really interested in what the Player's
Representation in the world collides with (What did Mario hit? What
did Sonic hit? What did the ball in Peggle hit? Etc.). Just
starting out with a simple Obj-Obj collision would be huge.
And even with that limitation a designer could increment a global
counter for collision events on their side anyway...
I'm beginning to ramble (full-on going at this point?) but one last
thing: You could potentially do something like an Engine event. APE
(the only Flash physics engine I've any real experience with) defines
a static APEngine object that runs your entire simulation. Perhaps
the engine could output some useful stuff like an
APEngineEvent.SLOWDOWNDETECTED event where it would notify your game
that the simulation is slowing down due to high load...? I don't
know. I'm kind of just fishing at this point.
The real meat and potatoes is Obj-Obj collisions. That alone would be
*huge*.
On Mar 27, 5:49 pm, "Richard Jewson" <rjew...@gmail.com> wrote:
> The first two of the 3 callbacks were the same as COLLIDE and FIRST_COLLIDE.
>
> I already have everything required to send these events are the right time,
> a few lines of code are all thats needed. Any ideas on the performance
> impact of sending all those events?
>
> At a minimum an body should know what its in contact with, I'm just
> wondering what use more global event is?
>
one threw me off: what does it mean to have a partial collision? As
in halfway through a physics engine step? Does that even make sense?
I don't think you're going to incur very much overhead by using the
system. You will certainly incur no overhead by not using it. I'm
not sure about your implementation in Glaze but one thing to be
mindful of would be the Event Dispatch Phases. Essentially, if your
event target is in the Display Hierarchy then not only does the your
event target get notified, but all ancestors as well. If the event is
a bubbling event then the ancestors get notified twice. The event
dispatch phase looks something like:
Capture Phase->Target Phase->Bubbling Phase.
If you think of your target as the last link of a hanging chain then
the event system starts at the ceiling hinge, walks down to the last
link and then back up. All ancestors get notified twice, the target
once. This has its utility (especially for display related stuff).
If your target is not in the Display Hierarchy then the event
dispatcher simply notifies your target object directly. That said, I
believe the ancestors also need to register a listener for a specific
event in order to 'intercept' it, etc. anyway. I've no idea on how
Adobe actually implemented it, unfortunately (do they walk the whole
display hierarchy or do they maintain an ad-hoc list, inserting
ancestors in the appropriate position when they notice a descendant
has already registered for an event?). Either way it seems pretty
snappy. And the number of things you'll likely have registered for
events will be pretty small. In my prototype I currently only
register one object so the effects are negligible.
Colin Moock's "Essential Actionscript 3.0" book covers the topic in
depth. See chapters 12 and 21. (It's a fantastic resource overall if
you don't already have it...)
The thing game programmers need to watch out for is heavy code
inserted in these callbacks. The callbacks that merely print [trace]
a statement are negligible. The onus is on the game programmer to
keep their callback code lean and efficient. Also, what utility would
there be in registering callback events for every object in your
pyramid example? You could have them generate sparks with a particle
engine but that would likely be overkill (especially given how much
processing power particle engines in Flash require - dang slowass
Flash renderer...).
By global event do you mean to return a list of collision pairs (pairs
of objects that collided in any given engine step)? In APE, colliding
particles are parts of a group. Perhaps instead of completely Global
you could have Group based globality - during the engine step, accrue
a list of collided objects in a given group and then return that in
the collision event fired at the end(?). There's a bunch of stuff you
could do, really, and I don't have any good use-cases yet. For the
most part, people are really interested in what the Player's
Representation in the world collides with (What did Mario hit? What
did Sonic hit? What did the ball in Peggle hit? Etc.). Just
starting out with a simple Obj-Obj collision would be huge.
And even with that limitation a designer could increment a global
counter for collision events on their side anyway...
I'm beginning to ramble (full-on going at this point?) but one last
thing: You could potentially do something like an Engine event. APE
(the only Flash physics engine I've any real experience with) defines
a static APEngine object that runs your entire simulation. Perhaps
the engine could output some useful stuff like an
APEngineEvent.SLOWDOWNDETECTED event where it would notify your game
that the simulation is slowing down due to high load...? I don't
know. I'm kind of just fishing at this point.
The real meat and potatoes is Obj-Obj collisions. That alone would be
*huge*.
On Mar 27, 5:49 pm, "Richard Jewson" <rjew...@gmail.com> wrote:
> The first two of the 3 callbacks were the same as COLLIDE and FIRST_COLLIDE.
>
> I already have everything required to send these events are the right time,
> a few lines of code are all thats needed. Any ideas on the performance
> impact of sending all those events?
>
> At a minimum an body should know what its in contact with, I'm just
> wondering what use more global event is?
>
> On 27/03/2008, Eric <ryunokok...@gmail.com> wrote:
>
>
>
> > So there's actually a lot of information that would be useful but one
> > thing we cannot live without: a reference to the object collided
> > with. If I'm Mario then I want to know what object I've collided with
> > so that I can appropriately grow, throw fireballs, or... die.
>
> > I'd put my money on the AS3 Event system rather than overriding a
> > method. There are several reasons for this but one important one is
> > event propagation: you can have multiple Listener objects set to a
> > specific event and give them priorities. The higher priority
> > listeners can actually interrupt the standard event propagation -
> > custom game logic flow! Further, you could easily implement a global
> > callback by registering the event in your Main class and putting all
> > your code in there.
>
> > I don't quite understand the difference between the three callbacks
> > you defined. Could you elucidate?
>
> > Take a look at how the current APE Trunk handles the callbacks.
> > Currently there are two events you can watch for: COLLIDE and
> > FIRST_COLLIDE. I've tested the [fixed] code a bit with simple tests
> > and it reacts as expected. The pertinent files (in link form) are
> > listed below:
> > 1)http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractItem.as
>
>
>
> > So there's actually a lot of information that would be useful but one
> > thing we cannot live without: a reference to the object collided
> > with. If I'm Mario then I want to know what object I've collided with
> > so that I can appropriately grow, throw fireballs, or... die.
>
> > I'd put my money on the AS3 Event system rather than overriding a
> > method. There are several reasons for this but one important one is
> > event propagation: you can have multiple Listener objects set to a
> > specific event and give them priorities. The higher priority
> > listeners can actually interrupt the standard event propagation -
> > custom game logic flow! Further, you could easily implement a global
> > callback by registering the event in your Main class and putting all
> > your code in there.
>
> > I don't quite understand the difference between the three callbacks
> > you defined. Could you elucidate?
>
> > Take a look at how the current APE Trunk handles the callbacks.
> > Currently there are two events you can watch for: COLLIDE and
> > FIRST_COLLIDE. I've tested the [fixed] code a bit with simple tests
> > and it reacts as expected. The pertinent files (in link form) are
> > listed below:
> > - Extends EventDispatcher (required to trigger events, implement
> > IEventDispatcher works too).
> > 2)
> >http://ape.googlecode.com/svn/trunk/source/org/cove/ape/CollisionEven...
> > IEventDispatcher works too).
> > 2)
> > - Extends Event, adds "collidingItem" to event:CollisionEvent object.
> > 3)
> >http://ape.googlecode.com/svn/trunk/source/org/cove/ape/AbstractParti...
> > 3)
> > - Insertion point for EventDispatch (look for the "resolveCollision"
> > and "testParticleEvents" functions in particular).
>
> > In testing the Event code I came across a bug and fixed it. I wrote
> > about it in the APE forums here (very simple fix):
>
> >http://groups.google.com/group/ape-general/browse_thread/thread/457a5...
> > and "testParticleEvents" functions in particular).
>
> > In testing the Event code I came across a bug and fixed it. I wrote
> > about it in the APE forums here (very simple fix):
>
Eric
Apr 10, 2008, 11:39:18 AM4/10/08
to glaze Engine
I've started running into some issues with my APE implementation and
they relate directly to this topic.
Something of great utility to programmers would be to delay the firing
of a collision event until *after* all collisions had been detected.
Then, when firing the collision event, include a list (array?) of all
objects collided with.
In APE, and I assume Glaze, you can connect with multiple objects in a
single engine step because of the non-CCD (Continuous Collision
Detection) nature of the engines. Knowing all objects collided with
when a collision event occurs is really, really useful.
I don't think this would be an issue with CCD, would it? Or can we
actually hit in two locations at the exact same time...? I guess you
could, huh, even though it'd be rare.
Sweet.
they relate directly to this topic.
Something of great utility to programmers would be to delay the firing
of a collision event until *after* all collisions had been detected.
Then, when firing the collision event, include a list (array?) of all
objects collided with.
In APE, and I assume Glaze, you can connect with multiple objects in a
single engine step because of the non-CCD (Continuous Collision
Detection) nature of the engines. Knowing all objects collided with
when a collision event occurs is really, really useful.
I don't think this would be an issue with CCD, would it? Or can we
actually hit in two locations at the exact same time...? I guess you
could, huh, even though it'd be rare.
Sweet.
Reply all
Reply to author
Forward
0 new messages