So, while I had a graphics module written several weeks ago, it didn’t really work because there was one main “game loop” for the whole system. The result of that was that the RaspberryPi would often miss a bumper trigger because it was busy drawing the screen. I brought the problem to my brother Timothy Baldridge (@timbaldridge) and he suggested that I split the program up, and let the Linux Kernel worry about the task managing.

Enter, Multiprocessing! Python has a great module for this which includes a thread-safe queue system for sending messages around. http://docs.python.org/2/library/multiprocessing.html

So, I re-wrote a lot of the code to let it work this way. So, basically the main thread declares an instance of my “cabinet” class and throws the loop() function at python’s multiprocessing module. From there, one thread is constantly scanning all the inputs and responding to them, and then letting the main process know: “Hey, the bumper was hit. We took care of it. Just FYI.”

You can see that it’s only running at 16fps, but at least the bumpers and slingshots never miss a beat. I could also over-clock the RasPi.

So, currently, hitting a whole drop target assembly down multiplies the multiplier variable by 2 or 10. That number is displayed in green below the points.

I’m basically going to re-write the graphics module soon. The code is a mess. I need to make it extendable so that when I come up with a new mode, or something, then I can easily add a new display screen.

Check back soon! And there’s always real-time updates on twitter @marktbaldridge