The 16th meeting of the Houston Recreational Computer Programming Group was held this past Sunday, April 13th, 2014. We had a pretty good turnout this month and lots of interesting things were presented and discussed.

Richard McClendon showed us his Little Man Computer simulator and ran a few demo programs on it. Via wikipedia:

The Little Man Computer (LMC) is an instructional model of a computer created by Dr. Stuart Madnick in 1965. [...]

The LMC model is based on the concept of a little man shut in a small room or a computer in this scenario. At one end of the room, there are 100 mailboxes (memory), numbered 0 to 99, that can each contain a 3 digit instruction or data (ranging from 000 to 999). Furthermore, there are two mailboxes at the other end labeled INBOX and OUTBOX which are used for receiving and outputting data. In the center of the room, there is a work area containing a simple two function (addition and subtraction) calculator known as the Accumulator and a resettable counter known as the Program Counter. The Program Counter holds the address of the next instruction the Little Man will carry out. This Program Counter is normally incremented by 1 after each instruction is executed, allowing the Little Man to work through a program sequentially. Branch instructions allow iteration (loops) and conditional programming structures to be incorporated into a program. The latter by setting the Program Counter to a non-sequential memory address if a particular condition is met (typically the value stored in the accumulator being zero or positive). As specified by the von Neumann architecture, memory contains both instructions and data. Care therefore needs to be taken to stop the Program Counter reaching a memory address containing data or the Little Man will attempt to treat it as an instruction. To use the LMC the user loads data into the mailboxes and then signals the Little Man to begin execution, starting with the instruction stored at memory address zero. Resetting the Program Counter to zero effectively restarts the program.

Richard expressed interested in collaborating with someone else in writing an assembler for the LMC. (Ed.: There appear to be a few LMC assembler implementaions floating around on github.)

Steve Cameron (Ed.: that's me) showed off an abandoned algorithmic attempt to produce images similar to those made by the process of Paper Marbling based on the work of Aubrey Jaffer. The system was found to be too ad-hoc and the output too lacking in chaotic complexity to be worth pursuing for the time being. The impetus for this investigation was the hope of producing some textures for gas giant planets within the Space Nerds In Space game, akin to some of the surface details visible on Jupiter. This did not seem to be forthcoming from the closed form solutions in the marbling models. In any case, the code is here: Marble-o-Man. Instead, attention was diverted to the field of computational fluid dynamics, in the hopes of getting a little more chaotic complexity. Unfortunately real computational fluid dynamics turns out to involve solving zillions of simultaneous equations and though the results can be quite pretty (see for example: Rayleigh-Benard-convection in two dimensions) , the complexity and compute time required, and more importantly the sheer mental strength required to comprehend such programs (for me at least) pushes it out of the realm of "recreational" programming. All is not lost though, as a paper by Bridson, et al, Curl-Noise for Procedural Fluid Flow (PDF) shows the way to a simple and serviceable method for cool and plausible looking, if not physically accurate 2D incompressible fluid flow model. I haven't got anything usable as a gas giant planet surface texture out of it yet, and may never, but it does look pretty cool and involves a sufficiently small amount of code and sufficiently simple algorithm to fall squarely in the "recreational" category.

In a normal fluid dynamics simulation, an incompressible fluid is simulated by some finite element analysis. When one bit of fluid moves, it must diplace other bits of fluid, which in turn must displace other bits (due to incompressibility) and so on. The net effect is that you end up having to solve a zillion simultaneous equations to recompute what all of the fluid does at each step. The method described in the Bridson, et al paper is to take a field of scalar values generated by Perlin noise (which is more or less continuous -- close enough), and essentially produce a vector field that represents the gradient or slope of the noise at each point in the field. Then, the velocity field is perpendicular to these values (essentially swap x and y coordinates). Essentially, if you imagine the slope (1st derivative) of the perlin noise field as a height map, and imagine contour lines at constant heights, the fluid flows along these contour lines.

Given the Perlin noise field (in Processing, the noise() function), finding the velocity field (or curl) is as easy as taking the noise function at the point of interest and at two very nearby adjacent points and computing the difference in x and y to produce a slope vector, then reversing the x and y coordinates to get a velocity vector at that point.

Once the velocity field is computed, particles can be introduced which take their velocity from this field based on position. Coloring the particles by mapping their speed to a heat map produces interesting results.

Note: After the meeting concluded, Steve found a bug in his program in which the sign of the y component of the velocity field was not negated as it should have been (to compensate for the screen coordinates having 0 at the bottom and positive numbers as you move up). Fixing that made the program work in a way that is obviously more correct.

Fake Computational Fluid Dynamics Code is here: Curly-Vortex

Edit: I should not omit mention of this reddit post which turned me on to the Bridson, et al paper, and probably contains many more hints which I've not yet implemented.

Steve also presented an update on Space Nerds In Space development for the newcomers. (There's actually not all that much new lately.)

Finally Aaron presented a work-in-progress computer game called "Star Diver" that he has been working on for the last six months or so that is in some ways similar to the vintage game "Star Control". He says he figures he's about 20% of the way through the development process.

Aaron aims to release the game on PC and consoles on Steam. Here is the Steam greenlight page.

Oddly enough, Aaron mentioned that he also had been looking into computational fluid dynamics simulations with the aim in mind of producing nice looking gas giant planet models! Great minds think alike!

That's all for this month. See you at next month's meeting of the Houston Recreational Computer Programming Group on May 11, 2014.