Hello all,

Last night out of curiosity I started lazily adding some code to see how
long it would take me to write a game of life implementation in Racket.
Not exactly a challenging expidition game-authoring-wise, but a fun
little exercise anyway.  You can see and play with the results here:


(Don't expect astounding code or anything.)

Here were my takeaways:

 - Racket is a real joy, especially due to its inclusion of its picture
   language, to write this kind of thing in.  I started playing with
   this very idly last evening and was very quickly pulled in.

 - The icons library is a hidden gem in Racket... bitmap-render-icon
   is a lovely way in particular to create the kinds of sprites you use
   in puzzle games :)

 - The HTDP big-bang system is, from a programming perspective, a lot of
   fun to code in.  I can easily see how it would be great to teach

 - It was easy to get an implementation of Conway's Game of Life going
   and have it even be fairly pretty within almost no time.  However, as
   observed here:
   the functional drawing system isn't very fast once you get a lot of
   objects on the screen.  Fortunately I found it was possible to not
   have to convert all my code, only the to-draw bit... I converted
   it to a bitmap canvas that I blitted to imperatively.

 - But even this was not fast enough... I found that a 50x50 graph was
   terribly slow.  I found that even just creating the 1000x1000 px
   bitmap every frame was very expensive, even before blitting to it, so
   I stuck the bitmap in a parameter and kept it around between frames.

 - I then found out that the bitmap wasn't changing suddenly... I'm
   guessing big-bang has an optimization where (since it's expecting a
   functional program) if it sees an object that's eq? to the previous
   object come out of to-draw, it doesn't draw it.  So instead I
   allocated two bitmaps as parameters and switched between which one I
   was blitting to.  That effectively tricked big-bang into blitting
   to my reused bitmap every time ;)

 - With those optimizations in place, a 30x30 grid on my
   10-year-old-laptop would run at full speed, and a a 50x50 tile grid
   (1000x1000 pixels) rendered at about 10FPS... a barely tolerable, but
   tolerable speed, for something like this ;)

 - It seems that the blitting of bitmaps to the canvas (I didn't do
   anything smart to "only blit the ones that changed", which would
   speed this up certainly by a lot) is by far the slowest part of
   my code, so I figured maybe it would be faster if I drew rects on
   the canvas instead of blitting my pretty icon-derived bitmaps.
   To my surprise it became 50% slower!

I guess completely redrawing 2500 sprites per frame is just a lot for
the vanilla canvas.  I see there's an opengl canvas... maybe I should
try that.

Obviously there's "the most correct" optimization to do, given that I've
already gone down the route of committing imperative-rendering sins: I
ought to keep around the previous graph and see if it changed at all and
only blit the ones that actually changed.  Well, I'm sure that would
make things lightning fast ;)

I'm not sure if that's interesting to anyone at all.  But I will say,
Racket really is a joy to work with!  Thanks for making a toolbox so
much fun I accidentally lose a number of hours to something like this :)

 - Chris

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to