Can we do without delayed switching?
Hi everyone, I feel this should be very simple to do, but I can't find a way to describe the movement of the ball in a breakout game. What do you think, how should it be modelled? My idea was to define a vector-valued behaviour for the position of the ball, and an event that fires on collisions and carries information about them. I believe such an event is necessary if I am to add sound to the program, for instance, and it feels natural to me anyway. The ball position behaviour is then defined as a stepper in terms of this event. Now the problem is that the event is defined in terms of the ball position among other things. At the moment this leads to a <<loop>>, no matter how I try to approach the problem. This is not too surprising, since I can't really think of a way to define the event other than filtering some kind of clock tick (e.g. framePass) using whenE. Please tell me if there are other, fundamentally different alternatives. After thinking about this for a while, I feel that Reactive really needs delayed semantics for switching, at least optionally. Otherwise I don't see how we could possibly avoid looping, since the event must be generated assuming that the behaviour continues without switching. Such an alternative reality doesn't fit in the semantic domain of time functions, but an infinitesimal delay looks like a possible solution that resolves the dependency loop. Using delayed constructs always felt clumsy in Yampa too, but loops need special attention... Another thought I had for a moment was defining some kind of intermediate semantic domain, where behaviours are represented as a _list_ of time functions (with or without intervals provided), which would somehow give access to pre- and post-switching behaviours (like 'head' and 'tail') through some mid-level combinators. But I don't see how that could be made elegant on the application level, and it doesn't seem to achieve anything the delayed switch can't do for us. What do you think? Gergely -- http://www.fastmail.fm - Access all of your messages and folders wherever you are
On 4 Mar 2009, at 15:05, Patai Gergely wrote:
Hi everyone,
I feel this should be very simple to do, but I can't find a way to describe the movement of the ball in a breakout game. What do you think, how should it be modelled?
My idea was to define a vector-valued behaviour for the position of the ball, and an event that fires on collisions and carries information about them. I believe such an event is necessary if I am to add sound to the program, for instance, and it feels natural to me anyway. The ball position behaviour is then defined as a stepper in terms of this event. Now the problem is that the event is defined in terms of the ball position among other things. At the moment this leads to a <<loop>>, no matter how I try to approach the problem. This is not too surprising, since I can't really think of a way to define the event other than filtering some kind of clock tick (e.g. framePass) using whenE. Please tell me if there are other, fundamentally different alternatives.
After thinking about this for a while, I feel that Reactive really needs delayed semantics for switching, at least optionally. Otherwise I don't see how we could possibly avoid looping, since the event must be generated assuming that the behaviour continues without switching. Such an alternative reality doesn't fit in the semantic domain of time functions, but an infinitesimal delay looks like a possible solution that resolves the dependency loop. Using delayed constructs always felt clumsy in Yampa too, but loops need special attention...
Another thought I had for a moment was defining some kind of intermediate semantic domain, where behaviours are represented as a _list_ of time functions (with or without intervals provided), which would somehow give access to pre- and post-switching behaviours (like 'head' and 'tail') through some mid-level combinators. But I don't see how that could be made elegant on the application level, and it doesn't seem to achieve anything the delayed switch can't do for us.
What do you think?
I would model this as the position being the integral of the ball's velocity, and switch the velocity, this way, you don't need to do complicated things with trying to grab the position from the last section of the behavior. Re delayed switching, Reactive already has a kind of delayed switching, that happens automatically when necessary. If you attempt to take the value of a Reactive value at the exact moment of a switch, you will receive the value from the previous step. This allows you to compute the new value even in a recursive computation, because sampling no longer gives you the value you are computing. I hope that helps. Thanks Bob
I would model this as the position being the integral of the ball's velocity, and switch the velocity, this way, you don't need to do complicated things with trying to grab the position from the last section of the behavior. I tried that too, but the result was the same. I don't see how that would help anyway, since integral is just a stepper over an accumE. I even tried a function-valued behaviour that had to be supplied time explicitly, which did move at least, but still <<loop>>-ed, so it never switched.
Re delayed switching, Reactive already has a kind of delayed switching, that happens automatically when necessary. If you attempt to take the value of a Reactive value at the exact moment of a switch, you will receive the value from the previous step. Oh yes, now I went back to the 'Simply efficient...' paper, and it says so indeed. I just misunderstood that part (off by one thinking, as always ;). However, the problem still remains, because it's not only the new value that depends on the current one but the time of switching as well. This knot is apparently too tight for the time being.
Gergely -- http://www.fastmail.fm - The professional email service
I think the problem in this case is the infamous recursive integral one...
Position of the ball depends on the velocity and vice versa. I'm not sure if
it is possible to do right now with Reactive. That's why pong is still
number one on my list of test cases for any reactive library :-) Or actually
a breakout game is even better, since it involves dynamic collections.
On Wed, Mar 4, 2009 at 9:39 PM, Patai Gergely
I would model this as the position being the integral of the ball's velocity, and switch the velocity, this way, you don't need to do complicated things with trying to grab the position from the last section of the behavior. I tried that too, but the result was the same. I don't see how that would help anyway, since integral is just a stepper over an accumE. I even tried a function-valued behaviour that had to be supplied time explicitly, which did move at least, but still <<loop>>-ed, so it never switched.
Re delayed switching, Reactive already has a kind of delayed switching, that happens automatically when necessary. If you attempt to take the value of a Reactive value at the exact moment of a switch, you will receive the value from the previous step. Oh yes, now I went back to the 'Simply efficient...' paper, and it says so indeed. I just misunderstood that part (off by one thinking, as always ;). However, the problem still remains, because it's not only the new value that depends on the current one but the time of switching as well. This knot is apparently too tight for the time being.
Gergely
-- http://www.fastmail.fm - The professional email service
_______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive
Hi Patai,
If I understand correctly, what you're describing is something that I intend
Reactive to handle well, and it doesn't yet. In other words, I think the
problem you ran into is just an implementation bug, not a problem with
semantics or interface.
Regards, - Conal
On Wed, Mar 4, 2009 at 12:39 PM, Patai Gergely
I would model this as the position being the integral of the ball's velocity, and switch the velocity, this way, you don't need to do complicated things with trying to grab the position from the last section of the behavior. I tried that too, but the result was the same. I don't see how that would help anyway, since integral is just a stepper over an accumE. I even tried a function-valued behaviour that had to be supplied time explicitly, which did move at least, but still <<loop>>-ed, so it never switched.
Re delayed switching, Reactive already has a kind of delayed switching, that happens automatically when necessary. If you attempt to take the value of a Reactive value at the exact moment of a switch, you will receive the value from the previous step. Oh yes, now I went back to the 'Simply efficient...' paper, and it says so indeed. I just misunderstood that part (off by one thinking, as always ;). However, the problem still remains, because it's not only the new value that depends on the current one but the time of switching as well. This knot is apparently too tight for the time being.
Gergely
I don't think you can do this without a form of recursive behaviour and hence a way to introduce infinitesimal delay to fix recursive definitions. Assuming you don't deal with acceleration at a given time t you have : collisions depends on position position depends on velocity velocity depends on collisions This has no least fixed point at time t. To break the tight loop you must introduce an infinitesimal delay in one of the dependencies. Note that doing the same as you do (see the p.s. below) made me doubt a little bit on the appropriateness of frp for physics simulations. The problem is that physics simulations are dirty with respect to time (at least as implemented traditionnaly). Dirty in the sense that you update positions according to your time step and once you realize that you went to far (i.e. across a collider) you come back in the past until the point of contact, invoke collision response, and start this again until your system stabilizes at the end of the time step. In my breakout game the system is ad-hoc, I tried to factor out a more general system where collision detection and collision response would be nicely separated, as is usual in physics engines, but didn't really succeed; at least not without introducing a lot of intermediary behaviours. This lead me to think that maybe implementing the simulation more traditionnaly and give it an frp interface to implement the game logic to be feedback in the simulation would be a better approach. As I said elsewhere I'd love to be proven wrong i.e. that implementing physics simulation in frp itself is feasible and worthwhile. Maybe my lack of experience with frp is just showing, as is my experience with physics engines, and I'd be interested to know if anybody comes with interesting and non-contrived frp solutions to these problems. Best, Daniel P.S. There's an ANSI terminal breakout [1] in the examples of my own OCaml frp library. It uses infinitesimally delayed behaviours to break the loop mentionned above. [1] http://erratique.ch/software/react/repo/test/breakout.ml
Hi, (resurrecting a very old thread) You have your answer (recursion is supposed to work in reactive!) but I would observe that there are three solutions to defining a behaviour for the kind of model you propose: (1) Solve the problem completely so you have a purely time-parametrised behaviour. In general this involves solving d.e.s so it may not always be possible. It also doesn't support the interactivity well. I used the complete solution approach for the pong "game" (it's non interactive) in the crayon demo I just posted. (2) Solve the problem using mutual recursion between Events/Behaviours. This allows you to access the previous value "just before" the kind of instaneous change `switcher` introduces. (3) Approximate the problem using a boring finite clock-rate iterative simulation. This is the solution I used in my stars demo uploaded last december to this list. This is obviously the least elegant approach, but there are all kinds of algorithms much easier to express as iterative simulations than the other kind. You can use quite a slow iteration rate (I think I used 10fps in stars) and then interpolate between the 'keyframes'; it works very nicely. This is a good place to generate collision events etc. Jules
Hello,
(1) Solve the problem completely so you have a purely time-parametrised behaviour. In general this involves solving d.e.s so it may not always be possible. It also doesn't support the interactivity well. Not just interactivity. If we return to the breakout example, the movement of the ball depends on the position of the bricks, but bricks disappear as the ball touches them. In the end, we are back at mutual recursion, and I don't think there are many useful examples where it can be avoided altogether.
Gergely -- http://www.fastmail.fm - A fast, anti-spam email service.
participants (6)
-
Conal Elliott -
Daniel Bünzli -
Jules Bean -
Patai Gergely -
Peter Verswyvelen -
Thomas Davie