[Haskell-cafe] Asteroids game, (was Space leaks)

[Ben Lippmeier]

Andy,
For the asteroids game, I just call GHC's System.Mem.performGC every 
frame and it seems to run ok. It's a very simple game, my 2.6Ghz P4 
system walks all over it and the FPS counter seems to bounce around from 
about 150 to 300.

I would imagine it's spending all it's time in the big XFillRectangle 
call I'm using to blank the screen, and without double buffering it 
flickers pretty bad.

I wrote the game as a way to get some non-tree-processing experience 
with Haskell, and to test out a C struct marshalling FFI preprocessor I 
was messing with. All the graphics stuff is written using straight Xlib, 
called from Haskell.

You're more than welcome to the code if you think you can do something 
with it. You can get it from my homepage at

http://cs.anu.edu.au/people/Ben.Lippmeier

There's also a mandelbrot set plotter, written in Haskell, which I wrote 
to try out various unboxing schemes.

The only other (reasonably current) real-time projects i've heard of are:

* The HOpenGL effort and Haskell Quake.
HOpenGL seems to be somewhat active, you might like to try out some of 
their sample programs.

I tried to get Haskell Quake to work once, but from memory they were 
using an ancient version of Greencard/HOpenGL for their FFI, which I 
couldn't get to work. The Haskell Quake home page says it hasn't been 
updated since 1997.


* Alastair Reid's real-time computer computer vision project, FVision.
http://www.reid-consulting-uk.ltd.uk/alastair/
I think they solved their Garbage Collection stall problem the same way 
I did, just invoked the garbage collector some fixed number of times per 
second / frame.. Don't know much about it, best ask him directly.


* The Haskell DSP libraries
http://haskelldsp.sourceforge.net/
I think its mostly an off-line, don't-care-too-much-about-runtime
-performance kind of thing. I think it consists of a collection of 
(typically) list to list functions, so its not really designed for real 
time operation.

However, a while back I had the idea that if you wanted to burn some CPU 
cycles in a real-time way, you might try piping to/from /dev/dsp with a 
full duplex souncard to make yourself some sort of poor-mans effect 
processor.


Thats it. Not much code deployed out in the 'world' it seems. My PhD 
project is also aligned with addressing this issue.

I think it's one of those catch 22 situations where no-one has written 
real-time programs in Haskell cause they knew it probably wouldn't 
work.. So when someone comes up with a new language feature which tries 
to solve the problem, there's no programs to try it on cause no-one's 
written any.

Do you know of any other real-time type projects besides these?

Perhaps the two of us, and who ever else is interested, should choose 
some real-time program (perhaps the asteroids game, or revive Haskell 
Quake) and spend some small, fixed amount of time per week working on it 
so we'll all have some application to showcase our glorious new language 
features with?

Ben.



Andrew Cheadle wrote:
> Hi Ben
> 
> 
>>-> An astroids game I wrote for X.
>>The state:    position, velocities of ship, astroids, missiles.
>>The [x] list: ship control data, key codes.
>>The [y] list: a list of graphics prims which get rendered to the screen.
> 
> 
> I wonder if you could help me out. I'm trying to investigate the
> practical use of my incremental collector for GHC over the standard
> generational collector. I'm looking for applications that have soft-real
> time constraints / interactive nature where garbage collector pauses are
> noticable. Do you know of any such applciations, did your asteroids game
> suffer any such problems? Although graphical programs would be great,
> when written in Haskell the rendering engine is usually in C so they're
> not usually appropriate!
> 
> Any help greatly appreciated!
> 
> Cheers
> 
> Andy
>