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:
https://gitlab.com/dustyweb/racket-life (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 with. - 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: https://groups.google.com/forum/#!topic/racket-users/yjRuIxypUQc 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.
