UPDATE: I’ve since returned this unit to the vendor. It’s really bad. The native screen resolution is abysmally small, plus is a weird value such that none of my OSes could handle it. The device did its own down-sampling, but did a terrible job of it. Also, the touch sensing was almost completely broken.
Apparently, there is a thing with these small displays where they advertise them as “1080p input!”, meaning they will make attempts to downsample a 1080p data stream to whatever their native resolution is. The resolution on this one was actually 800×480. I couldn’t get Linux Mint or Windows 7 to display on it at the native resolution. It would take other resolutions and do some pretty awful down-sampling, but it always managed to cut off the edges enough that the taskbar and window title bar were never visible.
The touch feature was also almost completely broken, as well. I tried it on Linux Mint first, trying a variety of different drivers available for the device. All Linux drivers from this manufacturer were compiled from source. I tried the one copy named “Linux” on the included CD and tried two copies downloaded from their website for “Ubuntu 6.06” and “Debian K26”. Of course, if we’re compiling from source, why would we need separate sets of source code? But anyway, at first it didn’t seem to work, so I thought I just failed to install the drivers, but things that happened later changed my mind. Windows 7 found a HID driver for it, identified it correctly, but it still didn’t work correctly. I also tried to download the latest driver off of their website, but their ZIP file is corrupted and won’t open with either the Windows Compressed Files utility or 7-Zip.
Moving on with the driver found for me by Microsoft, I now tried using the touch screen as the primary display, disabled my main monitor, unplugged my mouse, and restarted the computer, thinking it might help stabilizing the situation. I finally realized that I had seen the same behavior on Linux, I just hadn’t yet figured out what was going on because Mint wasn’t showing a cursor for the touch events and Windows did. It had the axises completely swapped, and also reversed, so dragging down the screen moved the cursor left. Also, it had no concept of a continuous drag event. It would sometimes drag, sometimes spawn a series of rapid clicks instead.
In other words: complete, unworkable garbage.
I’d be interested to hear from people if they have a recommendation for a simple touch screen. I think I’d like at least 15″ size, and I’m a little concerned about the popularity of multi-point capacitive sensing over the older-style, one-point-only resistive sensing. Yes, the capacitive is more precise, but the resistive doesn’t freak out if it gets just a little damp.
The natural DIY platform for such a project is the RaspberryPi. I’m thinking I want to take the stock Raspbian distro and hack together my own window manager for it to suit the small, restricted dimensions of the system. I’d like something halfway between a CLI interface with its infinite possibility and a GUI interface with its emphasis on geometric arrangement.
Anywah, I’ll keep everyone posted with my progress.
I’ve been studying artificial intelligence for many years. One of the AI constructs that has fascinated me the most has been Genetic Algorithms (GA). With a GA, one “evolves” a solution to ones problem. A “gene” is a candidate solution to a problem, and individual alleles in that gene are individual parameters to the function that attempts to solve the problem. The output of the function is evaluated for “fitness”–essentially, how well it solved the problem–and good candidates are intermingled for the benefit of future generations, while particularly bad candidates are discarded; “survival of the fittest” in its most incredibly literal sense.
This little sketch was written for a couple of reasons. First, I’ve been seeing some AI code that I felt like has been overly complicated. A lot of principle AI algorithms are quite simple to implement, once you understand them. But also, I wanted to demonstrate the flow of a GA and how it tends to find intermediate solutions, improving over time.
This sketch will require some basic programming knowledge to be able to alter the fitness function and make the GA do different things, but I think it can be an exciting and compelling exploration into code. There are actually a few simple things one can do to alter the course of the algorithm. Each “gene” represents a row of pixels in the image being drawn when you click “start”. As it currently stands, it will “evolve” solutions converging on the color red. If you change “if((i%4)===0)”* to read “if((i%4)===1)”, it will converge on green. “if((i%4)===2)” converges on blue. There is a 4th opacity component at #3, but it basically just ends up showing black. It isn’t necessary but I just didn’t feel like fixing the code to get rid of it, and maybe someone else will find it useful.
Instead of “if((i%4)” you replace the 4 with another number–say a prime number like 31–you get some interesting results as well. There are a lot of things that you could do here, it’s just a matter of whether or not you wish to pluck at it.
* the percent sign, ‘%’, is known as the modulus operator. For positive numbers, it returns the remainder of a division operation. So, “13 % 5 ” return 3 because 13 divided by 5 is 2 remainder 3 (i.e. 2 x 5 + 3 = 13).
Lately, I’ve been teaching myself the Racket programming language. It has a very interesting combination of tools, training-wheels-mode, and rocket-ship-mode. Originally built as a teaching programming language, it has significantly outgrown its pedagogical roots and is now a very robust applications language. I’m even developing a business project in it as we speak!
But it is a little rough around the edges. While it has a lot to make it a very easy language to learn, it is ultimately meant for computer scientists, those in training and those in working. There is an underlying feeling to everything that “this easy thing will eventually get harder.” As I see more and more inside the Racket community itself, I know that that is not their intention, and that they hope to be able to bring the joy of programming to everyone, regardless of their background.
A tool that has brought the joy of programming to everyone has been Processing. Processing, in a round-about way, brought a lot of features of the Racket environment to Java. There are some very, very clear parallels between the DrRacket programming environment and the Processing editor. If this was unintentional, then it at least clearly indicates the superiority of the form as a pedagogical tool, as two independent environments have both evolved the same feature. If it was intentional, then there are ways in presentation in which Processing has grown past Racket that I think could be brought back to Racket-land.
Racket and Processing
At a very high level, you can see the similarities between the DrRacket editor and the Processing editor. I have intentionally made the code samples different for each, as they represent more of the canonical methodology for each language.
As an artist with a very strong background in computer science, there are things about Racket that appeal to me that Processing will never be able to do. There are things about Processing that are very awesome and very nice that Racket could do, if someone with a very strong background in computer science took the time to make it so.
Where Racket succeeds over Lisp and Scheme, and where Processing–and thus Java–succeeds over all, is that enough is provided for you to not require you to learn the more advanced language features to get good results. Racket calls it “batteries included”, and it is, I believe, the most important concept that Processing borrows from Racket. Beginners don’t want to learn about “public static void mains”; to this day I still don’t know why that garbage is so necessary.
My hope is to try to bring some of the batteries of Processing back to Racket. The potential is there for Racket to be every bit as popular with artists as Processing is, today. The things that it lacks in comparison to Processing are relatively trivial to develop, in relation to the things that Processing lacks in comparison to Racket. By bringing artists into the much more powerful environment of the Racket programming language, once they have mastered the fundamentals of programming with the training-wheels mode, Racket can be molded by artists, for artists, to let people think and program in ways that the programmer-artist chooses, not in ways that the original language designer chose for them. If there are two groups of people that I know hate being told how to think more than anyone, it’s artists and programmers.
I’d like to hear from the Hive76 readership, especially those who have experience with Processing (though all are welcome to comment), about what you like and don’t like about Processing, about programming, about art, about putting code down in text files, etc. This certainly applies to the Arduino crowd, as well, as Arduino is based on Processing. In the meantime, I have a few thoughts on where the work could begin.
Make the website prettier
First impressions are important, and most programming language websites are prettier than Racket’s. I would more readily crib from Ruby than from Processing here. Ruby’s website is very clean and concise, very inviting and pleasing. Everyone cares about taste, especially artists.
Racket’s website is built in Racket, with a sub-language called Scribble, specifically designed for building documents and documentation. It’s an excellent language, but its default styling is kind of ugly. Restyling the site is a low-hanging fruit that could bring in more people, if only because they don’t jump ship prematurely.
Make more dynamic examples for beginners
The Racket documentation has its heart in the right place, but ultimately feels like its drawing examples are just pat examples. The drawings aren’t very interesting and its not immediately obvious how one gets to more interesting things. See this page for an example. It’s easy to draw a smiley face in Racket, it’s much harder to draw a good looking smiley face. And before it becomes apparent, the documentation dives too quickly into the computer science topics thereafter. In contrast, Processing starts off with examples that are extremely visually compelling. As people are visual creatures by nature, this seems the superior methodology. Note that the Processing example is the introductory page to the documentation–one click off of the front page–whereas the Racket example is several pages into the documentation–two clicks and several screenfuls of scrolling off of the front page. Much more compelling examples in Racket are much more deeply hidden.
 Historical Note: Racket has been around since 1994, when it was originally called PLT Scheme. They figured they lost more people being immediately associated with Scheme and Lisp than they gained, so in 2010 they changed the name to underscore the fact that there is so much more to Racket than the name “Scheme” implies. Suffice to say, for beginners it doesn’t matter, other than knowing that their is history to the project and it isn’t going away anytime soon.
 There are problems in both examples; both are overly simplistic and both would not scale well for large applications. But the gist of the difference is there, Racket is about functions that define what we want to happen, Processing (because it is based on Java) is about instructions. The differences to the non computer scientist are difficult to explain, so for now you will just have to take my word for it that the former is a generalization of the latter and is therefore more robust and open for greater expressiveness.
 For the computer scientists reading, succinctly: macros. You either know what I mean or you don’t, this is not the place to get into a technical description of macros. For the non-computer scientists, the best analogy I can make is magic. Magic isn’t real in our world, but I can think of nothing that comes closer to resembling it than the massive productivity gains that macros can afford, once mastered. But neither is mastery of macros in Racket required to do great work. Processing is what happens to languages like Java that do not have macros. In Racket, something like Processing would stay a part of Racket and not be a separate project.
Well everyone, so long, and thanks for all the fission reactors. I’ve moved to Alexandria, VA, to be with m’lady, plan our wedding, start a doggy dating website with some folks, and maybe spread the joy of hackerspaces a little further south. Step 1) figure out the joy of hackerspaces.
It’s a bittersweet change, as I am really going to miss Hive76 and her amazing people. You all taught me a lot and I will forever hold it all in my heart with great appreciation.
I’m not disappearing completely. You will still receive the occasional displeasure of reading some new, overly-verbose, trying-too-hard rambling from me on the listserv and in this blog. I plan on visiting on occasion as well. But regardless, here are a few of those things that I learned thanks to Hive76:
Everything is permitted. There is an avenue for doing just about anything. Don’t let the fact that you’ve never done something before prevent you from doing it now. Don’t ask permission to do it, either. People ask permission to do things in a lot of different ways. They stall the doing by looking for a job in what they want to do, waiting for an employer to give them permission. They research the “best” way to do something, asking questions of everyone around them, never actually just giving it a try. Someone will show up in your life with a need for help and you can help them by just saying, “I bet I can do that”, without knowing for sure if it is so. You win some, you lose some, hence it is a bet, but you always learn something, and that’s almost as good as winning.
Anything is possible. If you put your mind to it you’re capable of just about anything. Things you could never imagine will happen if you just try. Like having a piece of art put into a museum. Or meeting a legend of technology. Or just plain making the block clean for a change. “Luck is what happens when preparation meets opportunity”. A place like Hive can help you always be prepared for the opportunities that inevitably come our way.
It’s okay to do stupid things. Actually, it’s even preferable. We are too serious on most occasions. Having a habit of doing things just to see them done–things that have no inherent value of their own, beyond any spectacle they may bring–is pretty much the only way new discoveries are made; certainly the important ones. Without time for play, there is no art. Without art, there is no culture. Without culture, there is no language, no nation, no city, no people.
Don’t ever let anyone tell you what is right. Not a boss. Not a friend. Not your parents. Not a single person. You have to decide, and you have to get good at deciding, because half of the people out there are wrong and it’s on you to figure which half. Depending on what it is, more than half of everyone is wrong. There aren’t many places where less than half of everyone is wrong. So get good at deciding what is wrong and then trying new things to try not to be wrong. But absolutely, most importantly, respect everyone else’s path to figuring out how not to be wrong, because if you try to tell them you’re right, you’re probably wrong.
I’m stopping at 4 because it’s not wrong to stop at 4 and I’m also tired of typing for the day. Don’t forget to check out Hive76’s Open Houses on Wednesdays at 7pm. I understand they have an opening for memberships now.
Michelle doesn’t drink coffee, so she does not own a coffee pot. However, she did have a few coffee filters left over from making cocktail bitters. Fortuitously, she had also finished off a jug of milk the night before, leaving it on the counter because I hadn’t yet taken out the garbage (see! Procrastination pays, probably!) So, the milk jug bottom with a hole cut in the center holds the filter. The milk jug top holds the bottom instead of the filter because the handle was crumpling the filter. The weight of the jug assembly with grounds and water make the chop sticks grip the assembly on top of the jar (my favorite part), otherwise the top-heavy nature of the assembly would probably make it topple over. And now coffee is ready! I can’t tell if it tastes good because it’s freshly ground or because I’m just overly pleased with myself.
This year I wanted to do something a little different for Christmas gifts. Instead of just getting people electronics or video games or clothes, I wanted to give something that encouraged creativity and making. A lot of people never even think to try to make things on their own, so maybe a little hobby-style gift will give them a taste and spark an interest.
To that end, I did two things. First, I bought ten MSP430 LaunchPads. These things are really inexpensive, so they make great stocking-stuffers. If you don’t know what the MSP430 is already (really, we talk about it constantly, where have you been), it’s a 16-bit microcontroller with really low-power consumption needs. They run on 1.8 to 3.6v power supplies at up to 16MHz, making them quite a powerful little beast for only $4.30, which includes the chip programmer. If you were to buy the chips alone, they cost about $0.50 each, with a few different serial communication protocols built in, and requiring only a small selection of external parts (2 resistors and 2 caps if you want to do it right, 1 resistor if you’re living dangerously, and face it, at $0.50, you can afford to live dangerously). It’s something of a long-term project plan of mine to buy 100 of these and try to build a small, physical neural network computer.
A lot of people have shied away from the MSP430 because the Code Composer Studio software–based on the professional-grade Eclipse development environment–is very difficult to use in comparison to the Processing-based software typically used to program Arduinos. But luckily, someone has taken the Arduino cue and created Energia, a Processing-based editor for use with TI’s LaunchPad line of MCUs! If you’re experienced with Arduino, using Energia is a snap, and if you’re not experienced at all, it’s really not that big of a learning curve.
Making the putty is really easy. I pooled all 6 eggs of putty together in a non-stick pan. On very low heat, I warmed up the putty until it was just too hot to handle with my bare hands. If it starts to become the consistency of chewing gum and sticks to the pan, don’t worry, it will unstick when it cools down. Don’t heat it further than that though, it will start to smoke and burn. Wearing rubber gloves to give me just enough insulation from the heat and to keep my hands from getting stained black, it’s just a matter of working a large, heaping tablespoon-full of the black powder into the putty. You will need to work the putty like taffy, stretching it and folding it to blend the powder evenly into it. Once the powder is sufficiently kneaded in to the putty, it will not stain anything, so keep testing it on the back of your rubber glove to see if it leaves any marks. I then cut the putty into 6 equal chunks and shoved them back in their eggs. It took 10 minutes total. I thought about taking some photos of the process to show it off, but really, it could not be simpler.
I’m hoping these gifts will be completely unexpected and will inspire people to try something they never would have considered on their own. The MSP430s are just a really easy, cheap, fun way to get into programming, and the magnetic Silly Putty is a great example of something you can’t buy as a product that is also extremely easy to make.
One of my first projects here at Hive76 was the Burning Zombie Dummy. A friend of mine had called me, asking me if I knew how to set people on fire safely, and that led into a very stern discussion about what he was trying to do and that I would take over so that noone would get hurt. So I became the Special Effects Design Engineer for Exile: The Family You Choose, and it was one of the best times of my life. I got to do some pretty awesome things (including making an impromptu harness for doing a shotgun-to-the-chest effect), met a lot of really great people, and learned a lot about a hobby that would ignite my passion in a way I hadn’t felt in a long time. Seeing our end result, this thing that we made together, from start to finish, without any adults (of course, we’re all adults, but you never really feel like it) helped to further cement my belief that anyone is capable of doing anything. The hacker spirit is strong in the indie film world. Continue reading “Zombie Web Series Kickstarter Time!”
It’s a vidya game but not! A completely audio-based game, the objective is to use sonar to find the hidden submarine and destroy it with depth charges. But be careful! If you are not close enough to hit the submarine, it will get away and you must hunt it down again.
Got an Arduino Mega2560 on the innards side. Got the joystick and arcade buttons from Ada Fruit! Very nice quality, shipped very quickly, and not too expensive to boot. Box was just a little, prefab wooden deal from a craft store somewhere in the middle of nowhere. And the speakers, I think I pried them out of a few alarm clocks.
Okay, so I’m going to switch over to a very simple format, with very short examples of how you do certain things. The long article format is just too much for everyone to digest and takes too much time for me to write, so I tend to put it off forever.
Types of Games
Most games fall into two patterns: turn-driven or time-driven.
Turn-driven games have distinct periods where user input is taken, then periods where game updates are made, and the two do not overlap in anyway. The user-input section waits for the user to make their choice, and the user then waits for the update section to finish before they take their next turn. Many puzzle games and most board games are going to be of this type. For example, in chess with an AI player, the game waits for the player to move a white piece. Once the player moves, the AI takes over and calculates a move for a black piece, during which time the player is stuck and cannot make any moves. Once the AI has moved the a black piece, it’s up to the player to make a move decision again, and the AI cannot progress until the user has decided.
Time-driven games work completely differently. They are constantly updating the game, never waiting for the user to first make a selection or hit a button or waggle their joystick. If a user does perform some kind of input, the input is not processed separately, it is taken into account for the next update. Think of a game of Asteroids, in which the big, giant rocks float around the screen all on their own until the user decides to turn her ship and blast them.
There is actually a third class of game called alternate-reality games (ARG) that do not really update and do not really take user input–not in the same way these other games do–but they are way outside of the scope of this project. ARGs are more literature projects than programming projects.
Turn-driven games are relatively simple to create, as the user drives everything and performance issues do not cause noticeable artifacts like frame-rate stutter or audio clipping and buzzing. When we get into handling user input, you’ll learn all you need to make turn-driven games. Actually, time-driven games turn out to have many of the same features as turn-driven games, just with the additional features of not waiting around for the user first, having its own pump to drive the game forward.
We will be focusing on time-driven games, as they are the most technically challenging.