[grapefruit] FRP + physics / status of hpysics

[Peter Verswyvelen]

Regarding hpysics, did anybody did some experiments with this? The blog
seems to be inactive since december 2008; has development ceased?
Do alternatives exist? Maybe good wrappers (hopefully pure...)  around
existing engines?

Integrating hpysics with Grapefruit might be a good topic for the Hackaton,
trying to make a simple game (e.g. Pong or Breakout) without using recursive
signal functions, but with correct collision response and better-than-Euler
integration, all handled by the physics engine. Other FRP engines could be
tried, but Grapefruit hacking is already a topic on the Hackaton, so it
would combine efforts.

It feels as if none of the current FRP engines can handle physics correctly,
since a typical physics implementations requires "time backtracking", in the
sense that when you want to advance the current simulation time by a
timestep, collision events can happen during that time interval, and hence
the FRP engine can only advance time until the earliest collision event. So
to do physics *with* an FRP engine, the implementation and maybe even
semantics of the FRP system might need to be changed. *Using* a physics
engine as a blackbox inside an FRP system might make more sense.

Thanks to Wolfgang Jeltsch and Christopher Lane Hinson for having a
discussion with me that lead to this.  Interestingly a similar discussion
was help by other people in the Reactive mailing list at the same time :-)

Cheers,
Peter Verswyvelen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.haskell.org/pipermail/grapefruit/attachments/20090306/8afacf3f/attachment.htm