Fluid simulation, Atari 2600 programming

Fluid simulation update

I added more features to my fluid simulation. Follow the links to see movies:

• Fast approximate far-field interactions
  
• Semi-lagrangian simulation for comparison
  
• Brute-force O(N^2) vorton simulation for comparison
  
• Other visualization modes (still preliminary)
  
• Objects affect the fluid
  

I also submitted an abstract to GDC for 2008.

Atari 2600 Programming

I collect Atari games, consoles, controllers and other Atari-branded stuff from the 1970's and 1980's. I'm also beginning to program the 2600. Its CPU is a 6507 which has the same instruction set as the 6502 but has fewer address pins. Many computers from that era used the 6502 including other Atari consoles and computers (5200, 7800, 400, 800, etc.), Commodore computers and the original Nintendo (NES). It's the first CPU for which I learned assembly programming. The Atari retro development community is quite active and even now, around 30 years following its release, people continue to pioneer new ways to get more out of that console, e.g. higher image resolution. Each year at the Classic Gaming Expo people release several new games for the Atari 2600, and they usually sell out immediately.

I recently obtained a collection of EPROMs (which currently have Atari games burned onto them) and 2 modified Atari 2600 cartridges with ZIF sockets that fit these EPROMs. I put the chips into a conductive plastic container I got from Skycraft Surplus for $2. This gives the appearance I'm engaging in industrial espionage.

Programming is where it's at!

Wow, are we really starting our 7th week? It seems like we've just begun, yet we've already done so much. We've finished our first two rounds of prototypes, and I was very pleased with the work both of my teams did. Those were written in Flash and Actionscript, and several very interesting games came out of those two-week rounds. Now we are starting on our 3D prototypes using Panda and Pyton, and again we have just 2 weeks to create a game - this time focusing on story. Of course, that's not all we are doing. The programmers are working on some very involved C programs (after doing a few tough assembly programs - whew!), the artists are all designing/texturing/animating character models in Maya, and the producers are, well, producing. I can pick on the producers because I originally came into the program as a producer (a technical producer as you may hear them called). But after sitting in on the programming classes and realizing I didn't have a good answer for "What does a producer do?", I decided to switch tracks. And don't let "Sir Charles" (or Chuck as we like to call him) fool you. The job of a producer is not that sexy. The real sexy jobs are held by programmers. Don't believe me? Just take a gander at Dr. Gourlay's blog on "Fluid-like Simulation". Very Sexy!

But we already knew that. What I have learned is that you really have to prioritize here. In undergrad, prioritizing just meant figuring out what you could put off, and what you couldn't. But here, you are working with teams that depend on you. And frequently you are working on different teams at the same time. Should I work on my programming assignment right now? What about my prototype team that needs me to write code for our game? And how's my development plan team coming along? Of course, the other team members on each team are also juggling assignments and teams, so getting everyone to do what you need when you need it means we all have to do a little "producing" of our own.