Pug’s Place

I gave a presentation to the GatorLUG tonight about a LUG project (Ninja Sudoku) and how to do very simple network protocol design using Serializable objects in your favorite Object Oriented language. It’s here:

Ninja Sudoku / Simplified Network Protocol Design using Serializable Objects presentation for GatorLUG

Really, this entry is entirely too geeky and starved of information to be of any worth to any one, but I’m leaving it up ’cause I can. Nyah.

One of my two classes this summer is actually doing “research” with Dr. Fishwick. In reality, what I’m supposed to do is put together a 3D library, a Physics library and maybe a networking library to get a collection of tools for making 3D simulations. He wants this so that he can give it to students in his undergraduate Computer Simulation class next fall and let them create more interesting 3D projects than what is possible with Processing, the current tool they use.

I’ve got until the second week of August to put together two things:

1. A cross-platform tool-kit consisting of at least a 3D library and a physics library with class-tailored usage instructions and examples
2. and a version of SCHUA remade with this tool-kit as a “large” example.

Unfortunately, I haven’t been spending enough time on this yet. I originally intended to be done with all of the serious coding by the first of June and, hell, I haven’t even started. After spending all morning and some of this afternoon working on remedying this I have rediscovered my problem from late April: I can’t even get demo applications for my candidate 3D and Physics libraries to compile (e.g., turn from source code into executable binary code).

You know, I’m not all that inexperienced with programming. I’ve written a few applications, held a few jobs, captained the UF Programming Team, etc. I’m not all the unfamiliar with Linux, either, but ye gods, getting [OGRE and GangstaWrapper] or [Ogre and OgreNewt] or [Yake] to compile together is driving me batty.

For my own sanity I’m going to vent for a moment. Don’t take any of this as gospel, these are opinions with possibly nothing but an emotional foundation:

• OGRE compiles very easily.
• GangstaWrapper sounds like a great OGRE physics middle-ware. Too bad you have to read 16 pages of forum posts to find out that no one has touched it in over a year so it doesn’t compile cleanly.
• OgreNewt sounds like a great Newton Game Dynamics Library. Too bad it doesn’t compile cleanly in Linux. Oh wait, there’s a specific out-of-date source distribution for Linux the main author won’t host. Too bad its server is flaky and generally down. Including now.
• The Newton Game Dynamics Library is a professionally-packaged product produced by a real company. Too bad its demos don’t even compile out of the box on my system.
• Yake sounds great. Wow, its build instructions for Linux both look complicated and possibly compromised. I don’t much like the idea of having to SSH into a random box with a guest account to acquire source code…

I’m getting rather annoyed, but I think I’m going to tough it out and try to just make Yake compile. With Yake, at least, if I can get it to work it comes with its own wrappers for physics, networking and all that other stuff.

If I can just make it work… gah.

Other news: I’ve switched to Opera. I’ve decided I don’t have enough RAM to run Firefox anymore - the memory sieves are just too large. This might be short-lived, we’ll see…

So, I decided that now that I have a proper laser printer I want to be able to print professional envelopes again in Linux. I define a professional envelope as having three parts: return address, to address and the delivery point postnet (that barcode-like thing in the bottom right corner). In reality, printing the delivery point postnet speeds up postal processing by a day since it guarantees no human being has to look at the envelope until it reaches the destination street, and I always am a fan of efficiency.

So, what’s a delivery point postnet? It’s 12 numbers, the 5-digit zip code, the 4 digit +4, the 2 digit delivery point code and one check digit, printed in a height-varying barcode-like symbol on the bottom right corner of an envelope. Those numbers, taken together, indicate a specific mailbox in the United States. Theoretically all you would need to get a letter from A to B would be a delivery point postnet and a return address. I might try that sometime…

Back on track, I decided I wanted to print these things in Linux so I went tracking down free software to do it for me. I found Gregory Spath’s useful perl script called “envelope”, available on his website. It works like a charm - I expended 10 envelopes getting the margin values set right in my ~/.enveloperc file, but from then on it worked like a charm. It even prints postnets in the bottom right corner of the envelope! The only problem with this is that in order to print a full delivery point postnet it requires that I provide said delivery point value, in addition to the zip+4. Well, that’s a pain!

So, armed with the determination of being lazy in the future, I sought out something to locate that delivery point value for me. After several non-starts I realized that the USPS had several tools on their website to provide this value. One of them is even made to be used by programs (it has its web-based API)! Oh, that’s too good to be true, I thought! Indeed it was, the USPS requires a lengthy registration procedure to be permitted to use this API. Luckily, there still is another tool: a web-based query intended to be used by human beings. Unfortunately, programming something to use a web page intended to be used by human beings is generally another serious pain. Fortunately for me I found that Gregor Purdy wrote a perl module called Scrape::USPS::ZipLookup to do just that for just this script. Unfortunately again, it was slightly out of date. Fortunately, I fixed it and have emailed the changes to Mr. Purdy for release.

So that leaves me with a tool that can take a provided address, ask the USPS to correct it and return the full zip+4+delivery point code. What could I do next? Oh, it’s obvious, I wrote a GUI.

So now I have a small Gtk2 frontend to “envelope.pl” which you can see to the right here. It’s fairly simple: the address fields and four buttons. In brief, here’s what they do:

• Fix: Lookup the address with the USPS and fill in / correct fields
• Cancel: Close
• Print Preview: Show a preview of the envelope in GGV, GV or whatever you’ve configured to show postscript
• Print: Print the envelope using LPR

If you notice in the first screenshot I’ve put in a somewhat incomplete address. After pressing the “fix” button the USPS filled in the rest of the information for me, and that’s visible in the second screenshot.

Once that’s done I clicked the Print Preview button and the Gtk GhostScript viewer (GGV) opened to show me vaguely what the envelope would look like once printed. That’s the third screenshot.

Finally, the last screenshot shows the envelope I printed by clicking the Print button.

Not bad for a lazy Sunday morning, eh?

Source is available here: http://downloads.pugsplace.net/tree/envelope-maker-0.1.tar.gz. It contains the updated Scrape::USPS::ZipLookup module and Gregory Spath’s envelope.pl. You’ll have to install Perl-gtk2 and the dependencies for Scrape::USPS::ZipLookup via CPAN, but that’s described in the included INSTALL file.

Gpremacy
I spent most of this week’s free time working on Gpremacy. I’ve implemented Blind Bidding and Turn Randomization, the last major features standing in the way of Gpremacy being a really playable game. The changes are in CVS but they are not ready for serious use yet. For some reason the server-side logic keeps failing at keeping track of who’s playing when. There has to be a subtle problem in the StateManager class. It’s not that big of a class and its job is pretty darn straight-forward, so I’m perplexed at where the error lies. I intended to spend this morning line-by-line debugging it but I was distracted by E.

When I get back from my Spring Break I’ll either do the debugging or simply re-implement the class and see if I get it right next time.

On the plus side, the client code keeps getting better and better. I’ve fixed a number of holes which would cause clients to lock up when connecting to the server. In fact, the only bug I’ve found in the last few days regarding that is so weird that it don’t even throw a useful exception - it just deadlocks. Anyway, I’ll track that one down once I get the Blind Bidding (and probably Loans) fully working.

I’m gearing up to make a serious release very soon - Loans won’t take long at all, and once they’re out of the way the only things not implemented will be Winning Conditions (easy), L-Sat Clashes, Orbital Nuclear Bursts and Amphibious Warfare. Amazingly, these things should all be rather simple, especially in comparison to the Blind Bidding (which required a rewrite of a bunch of the game state management). By “serious release” I mean the following:

• Windows Installer
• Linux Installer (using Autopackage)
• Straight binary (just in case)
• User Manual (already partly written!)
• Turn walk-through (not yet written)
• New website (partly done)
• Developer documentation (just beginning)

I’m also going to bump up to a proper version number this time - the next release will be 0.4.0.

It’s going to be good, very good.

Spring Break

But before I can finish that up, I’ll be heading off to Phoenix and Las Vegas for Spring Break. Yes, Vegas again — we’ll see if Chris can capture another wacky image of me in front of the Paris casino. I’m sure I’ll still be checking my email and cell phone, so you’ll still be able to get in touch with me, just not as quickly.

Finally
My final project for Concurrent Programming is to implement a multiplayer Internet Boggle game using Java. I wrote up a frighteningly complete UML diagram and functionality outline during class today so I think I can say that I’ve a good head start. Don’t worry folks, you’ll get to play this one too.

I anticipate becoming very good at Boggle before this semester is complete…

I had a hard drive on my computer here have a complete head crash last weekend. Luckily, I’m a paranoid freak who runs his desktop with a RAID array, so no important data was lost. However, I realized over the week (while waiting for the replacement drive to arrive) that I have several places on the Internet to where I could do offsite backups of my most critical data if only I trusted them with the data.

Well, I had a bit of a brainstorm yesterday and I wrote a series of BASH scripts which I am actually rather impressed with which I’m titling PEBS: Pug’s Extensible Backup System.

Features:

• Written in BASH with minimal dependencies
• Provides a simple scripting language for defining what you’d like backed up
• Can be used on a multi-user system with each user defining what files they would like backed up via the scripting system (this is unsecure, presently, though)
• Uses GPG and your public key to encrypt the final backup archive before transmitting it to the remote host

Executive Summary for Interested Parties (Read!)

PEBS provides an infrastructure for remote, encrypted backups. Proper use of PEBS is going to require you to be comfortable with the “tar” command and have a basic knowledge of how to edit a shell script.
What PEBS does is takes care of backup naming, data encryption, data transfer to the remote server and verification of successful transfer. It also provides some logging of the results. If you’ve questions, look at the script example below for an idea of how to use this tool.

Download:

• PEBS (tar.gz)

Read more

For those of you who regularly read my blog, you can skip this entry. It’s just a compilation of what I’ve said so far about SCHUA so that I can have one post which covers everything. At Dr. Fishwick’s suggestion, I’m going to post SCHUA to the Processing exhibition page.

My CAP 5805 term simulation project was SCHUA, my Schooling User-Interactive Aquarium. Yeah, the acronym sucks, but it’s pretty. SCHUA is a simulation of fish, dolphins and sharks (and fish food) in a 3D spherical aquarium. All entities have agent-based artificial intelligences and school, hunt, eat, avoid other species and generally stay alive.

This simulation showcases emergent behaviour - complicated behaviour made up of a blend of simpler sub-behaviours. It is an extension of Boids, a bird flocking simulation created by Craig Reynolds in 1986. SCHUA is drawn in 3D with OpenGL, has multiple species with unique characteristics, Newtonian physics and additional behaviors such as hunting.

The sliders on the left change the coefficients which blend different behaviours of the fishes, and the smaller buttons on the right add more agents of various species to the aquarium.

It’s rather cool to watch. The fish school around, trying to avoid predators and unfamiliar species. When you add fish food, they go up and feed on it. The dolphins streak around the aquarium eating fish, and the sharks lurk around munching on living targets of opportunity (including dolphins). I’ve faked underwater lighting with texture maps, so light ripples across their bodies as the agents move. You can rotate the aquarium around and zoom in/out.

Further stuff you can look at:

• The project’s demonstration video is online at Google Video. You’ll need Flash to play it: SCHUA Demo on Google Video If there’s demand, I can put up a DivX and MsMpeg4 copy on Archive.org within about a week.
• The final report has detailed pseudocode of all of the algorithms involved as well as more details on how everything works. It’s online here: SCHUA Final Report (PDF).
• The source code can only be compiled and run with Processing, a Java simulation package. Luckily, Processing needs nothing more than a java environment to run, so it’s easy to install and easy to work with. Just uncompress SCHUA into your processing “sketch” directory, which defaults to “My Documents\Processing” in Windows. Processing is very simple to use, so even people with only a basic knowledge of using a compiler should be able to make SCHUA work. This FAQ entry and its links may be helpful for anyone giving Processing a try. SCHUA Source Code Release 1 for Processing, released under the X license.

For those of you who want to play with SCHUA (see the last few posts) you’ll want to download the SCHUA Source Code. This source can only be compiled and run with Processing, a Java simulation package. Luckily, Processing needs nothing more than a java environment to run, so it’s easy to install and easy to work with. Just uncompress SCHUA into your processing “sketch” directory, which defaults to My Documents in windows.

Have fun!

I’m heading home. Later!

I’ve made the demo movie for my 3D aquarium schooling simulation. Go watch the 3D Schooling Simulation Demo now @ Google Video!
I made this, turned it in today and Google Video posted it the same day. Nice turnaround time…

Unfortunately, I just spent a considerable amount of time and effort trying to get JOGL and Processing applets to play nicely so that I can hand out an executable for you all to play with, but the solution to this problem is still proving elusive. I’ll get the source code up this weekend, but you’ll need to install Processing to play with it for now.

Some notes about the video: I couldn’t find a working microphone in this place so I had to improvise. The voice-over was done on my cellular phone and transferred via Bluetooth to my computer. Then I meshed it into the video. It took me more than 25 tries and more than 3 hours to make that video, almost entirely because I couldn’t get XVidCap to stop crashing. I finally figured out that it crashed any time my mouse cursor dipped below a certain line at the bottom of my simulation’s window, but luckily the line was low enough that I could still manipulate all of the UI widgets. So I avoided moving the mouse down too low and all worked out fine. *grumble*

The video was captured to individual .ppm files, 10 per second, and these took up a whopping 9.3 gigs of space for the four and a half minute video. Then I had to convert these all to .png files so that Mencoder could make a video from them.

Converting voice recordings from my Nokia cellular phone to a usable format required the 3GPP decoder mentioned at this AMR Converter webpage and a short shell script:

if [ -z $1 ] || [ -z $2 ]; then
        echo “Usage: $0 [in.amr] [out.wav]”
        exit
fi
/home/pug/bin/3gpp/decoder $1 $1.raw
sox -r 8000 -w -c 1 -s $1.raw -r 16000 -w -c 1 $2
rm $1.raw

I know, Jen, that this isn’t a version you can use as a screen-saver, but at least you can see what it looks like.
Hopefully I’ll iron out the problems with JOGL at some point in the future and thus be capable of distributing it…

I’ve completed SCHUA, my Schooling User-Interactive Aquarium. Yeah, the acronym sucks, but look at the pretty!. I’ve written up the Final Report (PDF) and placed it online there for you to see, if you like. It has a few more pictures and descriptions within it. All that’s left, then, is to create a demo video - a task I’ll set to tomorrow. Once I get the video, I’ll put it up on Google Videos or something similar and link to it.

For those of you who want the source code, I’ll put it up this weekend - I have to wait until after the submission deadline is passed.

As you can see compared to the screen-shot in the post before this one, I’ve fixed the text labels and cleaned up the textures. Looks so much better, doesn’t it?

School’s basically done. I have some RITA work for Software Engineering to do this weekend and I need to put together a video of my Simulation project, but otherwise it’s smooth sailing.

Above you can see a screen-shot of the new installer for Windows I put together yesterday. It uses the Nullsoft Scriptable Installer System and has features to:

1. Check for your local copy of Mono. If you don’t have one, it opens your web browser to the Mono download page.
2. Create Start Menu shortcuts.
3. Create a Desktop shortcut.
4. Cleanly uninstalls through a Start Menu shortcut or through the Add/Remove Programs dialog.

That should fix… every problem so far reported for Windows. The next release of Gpremacy will have this installer for Windows. The big feature additions for the next version of Gpremacy will be Blind Bidding and randomized order of play, fixing the old market-manipulation flaw in the original game rules. This is proving to be difficult to get right, so I have no ETA on the next release.

Speaking of that Simulation project above, well, here’s a screen-shot. It’s a simulation of fish, dolphins and sharks (and fish food) in a 3D spherical aquarium. All entities have agent-based artificial intelligences and school, hunt, eat, avoid other species and generally stay alive.

This simulation showcases emergent behaviour - complicated behaviour made up of simpler sub-behaviours.

The boxes at the bottom of the screen have descriptive text when run in Windows, but something strange is happening in Linux. The big button in the center, believe it or not, says “Add Food”. I’m trying to fix this now. The sliders on the left change the coefficients which blend different behaviours of the fishes, and the smaller buttons on the right add more of various species to the aquarium.

It’s rather cool to watch. The fish school around, trying to avoid predators and unfamiliar species. When you add fish food, they go up and feed on it. The dolphins streak around the aquarium eating fish, and the sharks lurk around munching on living targets of opportunity (including dolphins). I’ve faked underwater lighting, so light ripples across their backs as they move. You can rotate the aquarium around and zoom in/out.

It’s a hell of a cool amusement. One of these days I’ll get it on-line for general consumption.
Tomorrow I’m invited to April’s place for a day of Star Wars. We’re watching all of the movies, 4-5-6-1-2-3. The order that God intended.