[Golist] A talk about GoPhysics

[Joel Stransky]

I'm having trouble seeing the need for a GoPhysics class. Perhaps I don't
understand it enough.
>From my experience, physics code is enterFrame based. Even if you use events
to stop and start, it seems too dynamic to make tweening efficient. I've
never really understood how Fuse would be useful for games for that matter
so like I said, I might just be missing a key point here.

For example, take a simple catch and throw demo. Imagine a white stage with
a small red circle for a ball. The user can grab and throw the ball where it
will bounce around the stage bounds. Every frame the position of the ball
its calculated against the four boundaries. The balls velocity is altered
accordingly (normally reversed in the event of a collision) which is then
added to the balls x and y. Technically, on Mouse UP you could have a go
class calculate a series of movements which is cleared the next time the
ball is grabbed and so on. But how far into the future do you calculate? And
is it really efficient to pre-calculate all of those values as opposed to a
per frame increment?

That's more of a you can, buy why question for me.

Example 2 is a scene with billiard ball physics. How much precalculating
would be required to build that big of a sequence? Similarly, imagine a
stack of blocks drawn with the API where the nodes are part of the physics
and a user moves one of the lower blocks toppling the stack.

That's a can you even do it question.

If I can see the need, I'd love to take a crack at such a class.

--Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080527/5fa88592/attachment.html