[Haskell-cafe] Re: FRP for game programming / artifical life simulation

[Peter Verswyvelen]

2010/4/25 Patai Gergely <patai_gergely at fastmail.fm>:
>> (in my own FRP experiments I have an update thread and a render thread).
> I wonder how to nicely deal with state that requires communication with
> the outer world, even though it is functional at heart. For instance, if
> you want to change a vertex buffer or a texture or whatever during the
> update, how do you organise your code? Do you maintain separate pure and
> impure state information blocks?

I don't have a vertex buffers or texture in my update loop. These are
low level details, left to the render loop. Indeed I maintained a pure
information block in the update. If you really wanted to have
low-level access in the update loop, I wouldn't know how to do that,
although keeping two copies could work. Now my experiments were really
simple 2D games, so not really state of the art.

> Deciding between push and pull according to profiling results is a nice
> idea. :) It might be too expensive to do it adaptively during runtime
> (the overhead might easily distort the results and thus render them
> invalid), but treating it as just a flag could give us an interesting
> architecture to play with.

Yes, I see it more in the line of "profile based optimization", where
a compiler performs static optimization based on a previous profile.

I kind of abandoned the FRP thing because Haskell just feels a bit too
complicated/abstract for me. It might also be that for the average
person to learn Haskell really well, one needs a mentor. I would love
to follow courses about it actually :)