Re: [Haskell-cafe] [reactive] A pong and integrate

Yes, it would be very nice to actually pinpoint why this can't be done. Is it a bug, is it a design flaw, ... I'm just saying that I'm not aware of a working Pong game in Reactive. Well actually, someone did make a Tetris game with it once... Intuitively I would say Reactive gives the programmer too much power of what can be done with time, making it all too easy to break causality. And since that's a physical law that can't be broken (unless Reactive would create a wormhole somehow), it means you too easily get delays or deadlocks. But that's just an intuition, I can't describe this formally. This is a general problem of first class signals IMHO: too open, not restrictive enough. First class signals are fine for just animation, but not for complex reactivity. Yampa gives you access to signal transformers, not the signals themselves, which is more natural to me as a casual game developer. Yampa looks like dataflow programming, but I agree that's not something you want to do in a text editor ;-) (stuff like x <- f -< y is easier in a graphical boxes/links editor). Also, a lot of global state needs to be transfered to all the signal functions (e.g. a random number seed that can't be used statically, e.g. in dynamic collections), and an arrow is fine for that, just like a state monad is. Well, at least that's what I understand from it. But I understand only tiny bits of pieces of it all :) On Sun, May 16, 2010 at 11:41 PM, Limestraël wrote:

Why isn't it possible to make a Pong with Reactive? Where is the problem? Conceptually, I don't see where it is. IMO, it's a time-leak issue due to a Reactive bug, but it is not a limitation of Reactive. I mean, it's not that it can't work, it's that it should work, shouldn't it?

And why would it be more possible with Yampa? I've already checked Yampa, but I find it much less simple and easy to use than Reactive. Moreover, I tried the space invaders sample (the sample that the paper "Yampa Arcade" is about), and it lauches but it is completely unusable (I do have a decent PC, and I get like 5fps and a gun which absolutely doesn't move correctly). Not very appealing ^^, but maybe the problem is with the code of the game itself or with my PC, not with Yampa...

I did not look thoroughly at elerea, but at least, when I tried its sample "dungeons of wor" it worked properly ;) I will have a look...

2010/5/16 Peter Verswyvelen

...

As far as I know, it was never possible to make a pong game in Reactive, at least not with the versions I tried, but I admit a lot of never versions got released since then. It would be great to see one though :)

You might want to try Yampa, that works for sure (although you should mark all your output data strict, as is done in the examples, otherwise you might also get space leaks or shaky frame rates). Or Elerea, which comes with a breakout game.

On Sun, May 16, 2010 at 9:30 PM, Limestraël wrote:

...

Eventually, I don't think it is a profiling issue. Maybe a problem with integral. According to a quite recent post on the reactive mailing list, the following minimal code produces the same problem :

...

import FRP.Reactive

...

import FRP.Reactive.LegacyAdapters

...

import Control.Applicative

...

type Velocity = Double type Position = Double

...

data Car = Car { vel :: Velocity, pos :: Position } deriving Show

...

velocity :: Behavior Velocity

...

velocity = 1

...

position :: Behavior Position position = integral (atTimes [0, 0.5 ..]) velocity

...

car :: Behavior Car car = Car <$> velocity <*> position

...

main :: IO () main = adaptE $ print <$> car `snapshot_` atTimes [0, 0.5..]

...

1) why is the leak happen? 2) how can I fix this problem?

...

Some more detailed informations:

...

* reactive 0.11.4 * GHC 6.12.1 * Gentoo Linux (2.6.32-tuxonice, x86_64) or Ubuntu 9.10 64bits * compiled with or without -O2 flag

2010/5/16 David Leimbach

...

On Sat, May 15, 2010 at 8:42 AM, Limestraël wrote:

...

Okay, guess I'll have to bring out the chapter 25 of my Real World Haskell...

I find it's often the most practical chapter that I hit a lot during writes and changes to my server process I have in Haskell in our control system code :-) That plus the information that I had missed that Control.Monad.State defaulted to the Lazy version (which is consistent, but for some reason it got by me) helped me to realize why I was leaking so much space in a garbage collected environment. I wouldn't have gotten very far with Haskell as this piece of our code without that chapter.  I'd love to see more writing of that sort around Haskell in book form.  One can become fluent in tuning Haskell by trial and error, but the sharp corners one must bump into are often sharper than in other languages I've found. Dave

...

2010/5/15 Bulat Ziganshin

...

Hello Limestraėl,

Saturday, May 15, 2010, 7:02:38 PM, you wrote:

> But when I set my beat to tick every 60 times per second, the > position is well updated, but I clearly see that the display > dramatically slows down after a few seconds of execution. Too heavy > rate for integrate?

it may be due to lot of uncollected garbage that is result of lazy evaluation. profile program to check its GC times

-- Best regards,  Bulat                            mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ 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