Watch Conway’s Game Of Life Flutter Across A Flip-Dot Display

Like many of us, [John Whittington] was saddened with the news that John Horton Conway passed away a little earlier this year, and in honor of his work, he added the Game of Life to a flip-dot display that he has been working on. The physicality of an electromechanical display seems particularly fitting for cellular automata.

Like what you see? If you’re curious about what makes it all tick, the display shown is an Alfa-Zeta XY5 28×14 but [John] is currently working on building them into a much larger 256 x 56 display. GitHub hosts the flip-dot simulator and driver software [John] is using, and the Game of Life functions are here.

If you’re new to the Game of Life and are not really sure what you’re looking at, [Elliot Williams] tells you all you need to know in his writeup celebrating its profound impact and lasting legacy. Watch the flip-dot display in action in the video embedded below.

21 thoughts on “Watch Conway’s Game Of Life Flutter Across A Flip-Dot Display

  1. R. I. P. Mr. Conway, you will be remembered.

    I think it is safe to say that so many of us enjoyed his “game” and inspired us to learn programming or even opened our mind for philosophy a bit, also.

      1. But could you find any of those implementations and/or results now? Game of Life was invented in the 70s, and I expect we all know that there were plenty of implementations of it from its invention onward, but finding a working example is pretty cool.

  2. Conway’s Game of Life – the mandatory C / Pascal program for students, right after the “Hello World” and matrices… :-)

    Waiting to see a Glider glide, not disappointed. \o/

  3. Now if only there were an efficient way to render cellular automata (CA) like these on screen under Linux. It’s easy-peasy to compute CA in an array in C/C++ but the idea of making a call to something like a fill-rectangle to turn each cell into an MxN patch of pixels on screen makes me ill. There must be a way to take a 2D array and copy-and-scale it onto the display, in one call. Like the old StretchBlt from windows. Heck of a time finding that technology for Linux.

    1. So you’re saying you’d like some kind of buffer for something like a frame of visual data… how to buffer a frame… how to buffer a frame… pffft…. you beat me.

      1. Do you have an actual method to get an off screen buffer onto the screen, or were you just going for comedy value here? There is undoubtedly GPU hardware to make this efficient. The missing piece is, what API is there that does that. Not saying Linux can’t do it, just that most searches for 2D graphics seem to result in drawing APIs, rather than the low level blit and buffer management.

        1. Honestly a little of both. I don’t know which APIs you’ve tried, but they usually have a way of taking some memory and smearing it on your screen. If you were using Qt for example you could shove your memory into a QImage and give that to a QPainter.

        2. If you want the game to be slow enough to watch, you don’t need GPU accelleration. Any library that provides some sort of canvas GUI element (I’d imagine QT does) should have a drawrectangle and you can subdivide the canvas into rectangles for each cell and write wrapper functions that take a 2d array and do the proper calls.

          1. I can imagine wanting to get a big picture, super fast view for some GoL endeavours. You’d want your GoL computer to be pretty fast, just because all the signals take so long to propagate, I’d probably be frame skipping at that point though.

      2. Or literally just output ■ or □ Unicode 25A0 and 25A1

        or maybe ▢ and ▣ ? 25A2/3.

        But honestly I don’t buy your argument that a single buffer display function is insurmountable.

        https://repl.it/repls/WelllitUnpleasantParser

        It took me longer to find a website to run the code on than write it. That run fine on my laptop. If anything you will want to slow that loop down even if you make it actually process the game state.

    2. A real simple approach would be to use the Curses library and render it with ascii characters in a terminal window. That would give you the tty experience that is closer to when it was originally created. A step up in complexity, but more fun, would be skip the Curses library and send the escape sequences to position the cursor in the terminal window yourself.

      If you want a more graphical setup experience and are not running a GUI, you can use the frame buffer device to draw. If you are running a GUI, a simple X windows program is the way to go and not much different to implement than a Windows version. In either case, there are sample programs on how to accomplish that. Bonus point if you implement double buffering for smoother animation.

      My recommendation is to implement using the escape sequence method (https://en.m.wikipedia.org/wiki/ANSI_escape_code).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.