The GHC bugs are now fixed, so it might be stable enough for
another adventure like that, but I don't think I would bet on it
again.
GHC bugs are corrected, but Reactive still have some. (See my previous
posts)
IMO Haskell is great for writing small clean prototypes, doing
interesting
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Limestraël
Sent: 26 May 2010 08:52
To: Peter Verswyvelen
Cc: haskell-cafe@haskell.org; Patai Gergely
Subject: Re: [Haskell-cafe] [reactive] A pong and integrate
The GHC bugs are now fixed, so it might be stable enough for
another adventure
On Wed, May 26, 2010 at 6:19 AM, Sam Martin sam.mar...@geomerics.comwrote:
There’s a lot of missed opportunities for more elegant and powerful
architectures going by at the moment simple because it’s not realistic to
attempt them in C/C++.
I beg to differ on that point. See my
Well, this does not contradict Sam's point, which was that you may have written
nicer, faster and more elegant code in way less time, had you used a true
programming language ;-)
El 26/05/2010, a las 12:28, David Sankel escribió:
On Wed, May 26, 2010 at 6:19 AM, Sam Martin
Wow... impressive...
And now, with your experience, if you'd have to do this again, would you use
Yampa or stick up with C#/C++ ?
2010/5/24 Peter Verswyvelen bugf...@gmail.com
Yeah. Funny that we're still writing games in C++, while mission
critical and hard real time systems are written in
Well, first of all, I did not make these PS3 visualization, my former
colleagues and I just made the editor, language and runtime that
allowed video game artists to do the job for us in a couple of weeks
time :-)
I wouldn't use Yampa, for performance reasons, and difficulty to get
it running on
IMO: For AAA game programming? Definitely not. For exploring new ways
of doing game programming and having a lot of fun and frustration?
Sure! For making casual games? I don't know.
Why not casual games? I don't see any immediate difficulty. Do you have
any particular bad experience?
One problem with Elerea experimental branch besides the update time control:
the memo function. I can't understand when I have to call it and when I
don't.
Just to know, have you been told of a language dedicated to reactive
programming (even experimental)? I mean, not an embedded language just
2010/5/24 Patai Gergely patai_gerg...@fastmail.fm
IMO: For AAA game programming? Definitely not. For exploring new ways
of doing game programming and having a lot of fun and frustration?
Sure! For making casual games? I don't know.
Why not casual games? I don't see any immediate
Just to know, have you been told of a language dedicated to reactive
programming (even experimental)? I mean, not an embedded language just like
Yampa is.
Maybe Lucid Synchrone (http://www.lri.fr/~pouzet/lucid-synchrone/) and
Timber (http://www.timber-lang.org)?
One problem with Elerea experimental branch besides the update time
control:
the memo function. I can't understand when I have to call it and when I
don't.
Technically, you never have to. However, if you have a signal derived
from others by pure application (i.e. fmap or *), keep in mind that
But you have to be aware that Elerea, Yampa, Lucid Synchrone and Lustre
are all very similar in their foundations.
Okay. I just thought that reactive programming was a quite new field of
research, but I saw that Lustre and Esterel date back to 1980...
I assumed also that it was a field which
Yeah. Funny that we're still writing games in C++, while mission
critical and hard real time systems are written in much nicer
languages :)
I made something similar to Lucid Synchrone for a game company I used
to work, but with the purpose of making reactive programming
accessible to computer
I keep asking myself the question is Haskell and/or FRP even suitable for
game programming.
And if so are there any design patterns.
2010/5/19 Patai Gergely patai_gerg...@fastmail.fm
I that the saw sleep time at each loop is fixed (0.02). So game speed
will
depend on processor speed, since
IMO: For AAA game programming? Definitely not. For exploring new ways
of doing game programming and having a lot of fun and frustration?
Sure! For making casual games? I don't know.
On Sun, May 23, 2010 at 9:09 PM, Ben Christy ben.chri...@gmail.com wrote:
I keep asking myself the question is
On May 23, 2010, at 15:09 , Ben Christy wrote:
I keep asking myself the question is Haskell and/or FRP even
suitable for game programming.
Well, that's the question. FRP is a research project, not a
production framework/paradigm; anyone working on it currently is there
to help answer
On 05/23/2010 02:17 PM, Peter Verswyvelen wrote:
IMO: For AAA game programming? Definitely not.
Why not? I suppose it may depend on your definition of AAA, since
there doesn't seem to be any consensus on it. I have seen it mean
various combinations of the following, but rarely, if ever, all
Assuming Haskell is ready has any work gone into creating design patterns or
the like. One of the biggest problems is ALL of the literature regarding
game programming is written in an imperative style. My goal for learning
Haskell is to make a hobby game written in a Functional language but I am
On Mon, May 24, 2010 at 12:30 AM, Jake McArthur jake.mcart...@gmail.com wrote:
On 05/23/2010 02:17 PM, Peter Verswyvelen wrote:
IMO: For AAA game programming? Definitely not.
Why not? I suppose it may depend on your definition of AAA, since there
doesn't seem to be any consensus on it. I
I guess Im thinking of a overarching pattern for creating games in a
functional language similar to
http://www.acims.arizona.edu/PUBLICATIONS/PDF/JeffPlummerMSthesis_wo_Appendix.pdf
.
On Sun, May 23, 2010 at 6:51 PM, Ben Christy ben.chri...@gmail.com wrote:
Assuming Haskell is ready has any
What papers did you read?
When I read most of the Yampa papers, most of the design patterns
became obvious for AFRP (arrow-based FRP) style of programming. That
doesn't mean I could apply the design patterns immediately; I
understood them but writing a game in it was difficult since I also
was
Elerea finds middle ground between the two, and unlike Yampa, it's
examples would still work I guess.
Yes that's the big problem of Yampa: all of the examples are very old, and
some even don't work anymore.
It's the same for the papers/tutorials (they're all 6 years old or more),
and it would
I that the saw sleep time at each loop is fixed (0.02). So game speed
will
depend on processor speed, since with a more powerful CPU frames will be
computed quicklier?
Yes, that's how it works.
So we don't have (with the Simple branch) some way to say I want my
sprite
to move 100 pixels
I heard complaints about this two-layered solution with
SignalMonad/SignalGen, so I'm glad you like it. :)
Doesn't SignalGen replace SignalMonad in the experimental branch ? They
aren't meant to be used together, are they?
By the way, I strongly recommend using the Experimental branch instead
Doesn't SignalGen replace SignalMonad in the experimental branch ? They
aren't meant to be used together, are they?
Absolutely, they are incompatible, and play the same role in the
respective versions.
But there is no notion of time, here. So how do I make sure the network
is updated with the
Time has to be an external signal?
I saw dow uses the Simple experimental branch, and I don't see how you
synchronize elerea with GLFW (what is done by driveNetwork in the Chase and
Breakout examples which use the main branch).
2010/5/18 Patai Gergely patai_gerg...@fastmail.fm
Doesn't
Time has to be an external signal?
With the Simple version, yes. With the Param (and Delayed) versions it's
pretty much like the old one, where you have to pass something (delta
time being one possibility) as an additional parameter, and all stateful
and transfer nodes will see it.
I saw dow
The game speed is determined by the amount of sleep
per frame.
I that the saw sleep time at each loop is fixed (0.02). So game speed will
depend on processor speed, since with a more powerful CPU frames will be
computed quicklier?
So we don't have (with the Simple branch) some way to say I want
I did not look thoroughly at elerea, but at least, when I tried its sample
dungeons of wor it worked properly ;)
Elerea has its own 'beauty' though. I suggest unpacking the source of
dow and executing it in ghci, the problem will be obvious as you play at
length. Unfortunately, Elerea doesn't
I looked at elerea. I found it simple and nice!
I just regret the fact that the SignalMonad can only be run inside IO. With
reactive, you can transform signals in pure code.
I suggest unpacking the source of
dow and executing it in ghci, the problem will be obvious as you play at
length.
Yes,
I looked at elerea. I found it simple and nice!
I heard complaints about this two-layered solution with
SignalMonad/SignalGen, so I'm glad you like it. :)
I just regret the fact that the SignalMonad can only be run inside IO.
That's life. ;) However, there is only a single point where you have
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
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
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
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
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
Okay,
guess I'll have to bring out the chapter 25 of my Real World Haskell...
2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com
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'm definitely not good at profiling...
But I have something:
4,971,190,736 bytes allocated in the heap
4,392,735,248 bytes copied during GC
13,998,328 bytes maximum residency (573 sample(s))
3,281,000 bytes maximum slop
38 MB total memory in use (0 MB lost due to
Make sure you're profiling with -prof -auto-all
And any packages you're using may need -auto-all as well.
limestrael:
I'm definitely not good at profiling...
But I have something:
4,971,190,736 bytes allocated in the heap
4,392,735,248 bytes copied during GC
13,998,328 bytes
On Sat, May 15, 2010 at 8:42 AM, Limestraël limestr...@gmail.com 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
40 matches
Mail list logo
