Actually, I believe that many Yampa examples do separate the drawing from the update... The arrow provides the game data that *can* be rendered. If you provide interpolators for that game data, you can still achieve the same as is explained in "fix your timesteps" (in my own FRP experiments I have an update thread and a render thread).
But IMHO "fix your timestep" still misses an important detail, in that the delta-time that is measured is the duration of the previous frame, and it assumed that the next frame will take as long as the previous (who says that "integrate" from the article won't take longer than dt?). Now say you are updating at 100 FPS = 10ms, but the next frame actually takes longer, say 20ms. That actually means that you should have passed 20ms as the delta-time of the this frame, because the real time is ahead now! This is really noticeable as little jerky frame hick-up in the motion. In my first game (1987), I added an estimator to compute how long the delta-time of the next frame would be, which results in much smoother motion: you notice that the frame-sampling-rate drops, but you don't see a frame hick-up. I rarely see this in modern games, most PC and even console games suffer from frame hick-up (which could be defined as the real-time moving ahead of the game-time for a brief moment) Regarding FRP, I like to look at this as a kind of a data flow system (a network of "signal transformers", or just "nodes"). However, it is not clear if you want to "pull" or "push" such a network: if side effects are not present, there should be no difference in the "game state" if you push or pull it, but one can be far more optimal than the other. Of example, nodes connected to an analog joystick would most likely benefit from a pull approach, since the joystick always moves a little. But nodes connected to a timer that changes once each second clearly should benefit from a push approach. Although sometimes a static "change frequency" could help to determine wether to push or pull, I believe this can only be determined with profiling. So in a sense, push or pull should be some kind of attribute... Okay, a bit off topic :) On Sun, Apr 25, 2010 at 5:09 PM, Christopher Lane Hinson <l...@downstairspeople.org> wrote: > >> 1) In FRP, there is no global *type* GameState that stores the whole >> game state. Rather, the game state is implicit in the collection of >> "active" computations. This is also why state updating and drawing is >> woven together in FRP, which is good syntactically, but hard to >> disentangle for interpolation. > > I disagree somewhat with this. FRP should be thought of like the IO monad, > out of which everything that can be lifted, should be, especially the > GameState. > > I like to imagine that the FRP's job is to observe the GameState and reenact > changes therein. Some changes take a little while to act out, and the FRP > element that is doing the action can signal that it isn't ready for the next > transition. Or, if no changes occur, the actors can stand around doing idle > animations. > > Friendly, > --Lane > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
