Pong with the Java 2D API

I’m planning on using the Java 2D API for a project this summer, but I need to get familiarized first. In the previous post I covered Pong on a the C32 microcontroller. Here I’ll look at a desktop implementation using AWT.

A great starting point is this zetcode tutorial on game programming. The author covers a series of classic arcade games. I used their code to figure out how to initialize the Swing JPanel and handle keyboard input.

Here’s my implementation:

Player 1: Q, A
Player 2: Up, Down
Pause: Space
Restart: Esc

The collision detection code is almost exactly the same as the C version. This version is a little more robust in that it supports arbitrary window sizes, paddle lengths/widths/speeds, and ball velocities. The only real trouble spots were devising a scheme to handle two keys being held down simultaneously and repainting the frame at the correct times. For more fun, consider modifying this version to change the X and Y speeds of the ball based on paddle velocity or collision position.

Here’s the playable jar file and the Eclipse project with the source.


Helpful links

Pong on the mc9s12c32

At the conclusion of UT’s embedded systems lab, EE445L, all student teams produce a final project of their own choosing. My partner (Tim) and I built a game system for playing Pong.

I designed the circuit schematic and wrote most of the software. Tim designed the PCB and assembled most of the hardware. Everything that could go wrong did, but we managed to build a fun little game.

The finished product

The interface is extremely intuitive. The potentiometers on either side of the screen control the paddles for each player. The code for the C32 is almost entirely C and was developed in Freescale’s CodeWarrior IDE.

The screen is an AGM1264 128×64 monochrome LCD. Professor Jonathan Valvano provides a useful driver for the c32 on his website. While the driver supports writing whole bitmaps, the memory layout of the LCD makes it very tricky to draw 2D shapes at arbitrary coordinates. I ended up using a 1-pixel ball because a 2×2 ball could require writes to 4 memory locations, a can of worms that I did not want to open.

But, if you’re interested in improving the game, you can draw to arbitrary pixels using the modulus arithmetic in drawBall(). It could easily be a jumping off point for a 2D graphics library supporting more interesting shapes. A word of warning: you will get a noticeable flicker when writing bitmaps quickly (we did 20 fps). The screen really isn’t built to draw every location continuously.

Edit: I had a conversation with another student who attributed the flicker to a call to LCD_Clear(0) in Valvano’s LCD_DrawImage routine. It’s there in LCD.c on line 383. I no longer have the hardware, but that would have been an easy fix to make.

Things that went wrong

  • The seventh wire in the ribbon cable was broken, resulting in garbage on LCD. I tracked this down with a multimeter and patience.
  • I forgot to right justify the 10-bit ADC inputs on the potentiometers. This should have been obvious when the values read were greater than 1023. The fix: ATDCTL5= channel + 0x80;
  • The original box we ordered was just barely too small. Tim measured the LCD’s bezel, rather than its slightly wider PCB. I didn’t double check it. We ended up using the obnoxiously large black box in the picture.
  • The black button unexpectedly employed negative logic. That is, pressing it opens the circuit. This was trivial to deal with in software, but annoying nonetheless.
  • The power switch broke. Our nice metal toggle switch broke into pieces when I bumped it on the table. I decided to short the wires in the interest of time.
  • Tim was unaware that capacitors may be polarized and soldered them in randomly. He is now very good with solder wick.
  • The potentiometers are a little longer than the screen is wide. It would be better to have a perfect 1:1 correspondence.
  • There is a strange bug with the LCD hardware or driver that causes a few pixels near the lower left corner to erroneously become dark. Hence the name, “Distortion Pong”. I tried to convince the TA it was feature, but I don’t think he bought it.


Check out the hastily written source.

This project wouldn’t have been possible without the technical guidance of Darryl Goodnight, Paul Landers, and Justin Capogna.

If this post tickled your fancy, check out my Java version of pong. The functionality is nearly identical, but the code is much nicer.


6 Great WordPress Tricks Everyone Should Know

I love WordPress because much of its functionality is dead simple. However, I’ve found that it usually takes some tweaking and 3rd party plugins to get everything working to my taste.

1. Auto-update with SSH instead of FTP
I maintain dozens of WordPress installs for various reasons. I absolutely love that you can auto-update with one click. The default mechanism behind this behavior is FTP. That’s fine for shared hosting, but when I moved to my Linode VPS, FTP became just another daemon that would be nice to avoid for the pain of configuration, not to mention security.

WordPress is cool enough to support updating over SSH but you have to edit your config.inc.php file like so:

define('FS_METHOD', 'direct');
define('FTP_BASE', '/srv/path/to/wordpress/root/');
define('FTP_CONTENT_DIR', '/srv/path/to/wordpress/root/wp-content/');
define('FTP_PLUGIN_DIR ', '/srv/path/to/wordpress/root/wp-content/plugins/');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'example.com:22');

Learned how to do this from Karl Blessing’s helpful blog.

2. Highlight the syntax of your code snippets for virtually any language
After playing around with handful of code formatting plugins, I finally got comfortable with Syntax Highlighter ComPress. It supports an impressive list of languages and integrates nicely into the TinyMCE editor. You can stick with the visual editor and avoid HTML entirely. This is a big deal for me because I don’t want to write HTML when I’m writing content.

3. Create a static front page
Before I had written any posts for this blog, I set the home page to my list of projects.
From the WordPress Codex:

Go to AdministrationSettingsReading panel.

  1. Set ‘Front page displays:’ to ‘a static page’ and choose the first page you created above for ‘Front page.’ If your WordPress site will contain a blog section, set ‘Posts page’ to the page your created for this above. Otherwise, leave this blank.

4. Install the Google XML sitemaps plugin
From what I can tell, having a sitemap for WordPress has been a effective SEO tool. Searching for sitemap builders in the plugin directory will bring up many results. The only one you need is called Google XML Sitemaps by Arne Brachhold. Consider donating because the plugin is fully featured, but a breeze to install and deploy.

5. Eliminate spam comments forever
After letting BeatLogic.org sit dormant for several months, the comment queues were overflowing with about 5000 spam comments. There are nuanced ways to combat spam, but I prefer this three step kill-it-with-fire approach.

  1. Disable comments on future posts under Settings->Discussion->Allow people to post comments on new articles
  2. Disable comments on old posts under Posts->Select All with checkbox->Edit->Comments->Do not allow.
    Do this for every post at once by using the checkbox at the top of the Posts table and the bulk action dropdown.
  3. Delete spam comments by logging into your SQL database and running a
    DELETE FROM wp_comments WHERE comment_approved=0

Warning: These steps will completely disable commenting on your blog and delete every unapproved comment. Make sure this is right for your situation.

6. Recover from broken plugins
On a few occasions I’ve had a wordpress install die after an update because of plugin trouble. Usually the home page will fail to load at all or the posts page will die halfway through. The trick is to disable all plugins and re-enable them one by one. Run one of these on your database
SELECT * FROM wp_options WHERE option_name = 'active_plugins';
and delete the text string in the one matching row. Everything should then load normally, leaving the sleuthing up to you. Thanks to WordPress pro Jeff Star for this one.

4 Problems with Google Docs

1) Cursor displacement bug
Google recently changed the way page breaks work. Instead of one continuously scrolling page, you now see distinct predetermined page breaks. This feature is vital for competition with Word. It’s expected behavior for a word processor and it’s far more convenient than rendering a PDF every time you want to see where page breaks occur or placing them manually.  Unfortunately, this feature introduced an annoying bug that places text a line behind where the cursor should be.
Short term fix: avoid page breaks.

2) No tab leaders
Ever since high school debate I absolutely have to make my tables of contents with the rows of dots between the section names and page numbers. As far as I can tell, Google Docs doesn’t tab leaders, the standard way of doing this.
Short term fix: manually type out dots

3) No dashed lines in drawings
This is really a nitpick, but it would be nice to be able to draw dashed lines. I’ve created a couple diagrams where it would have been handy to delineate collections of components. The solid line doesn’t work well because it’s the same thickness as the arrow tails.
Short term fix: don’t worry about it

4) Weird collaboration behavior on presentations
When I last tried to collaboratively edit a presentation (April 2011), the editor was very sluggish when reflecting the changes of others and repeatedly threw errors about conflicting edits. The chat in the right sidebar did not correctly list others as viewing the document.
Short term fix: Temporarily designate one person as an editor for  a group slideshow

Whining aside, Google Docs is still my go-to solution. Real-time collaboration and universal access rock so hard that Word’s extra features aren’t alluring anymore.

Ruby on Rails: A first look

I’ve been writing PHP apps for about 5 years, but it’s time to learn Ruby and its popular framework, Rails. Since there is already great documentation available, I’ll only cover the trouble spots that I’ve encountered.

I began with Ruby itself and followed this quick introduction to Ruby’s data types, object orientation, and iteration methods. It’s a lot to swallow if you’ve spent most of your time writing in C-style languages, but I can understand the appeal of the syntax. If you’re just starting out it’s probably a good idea to spend more time with Ruby proper. Later it can be easy to conflate Ruby with Rails if both are foreign.

To get up and running with Rails on Arch Linux I followed the guide on the official Arch wiki. I ran into a little trouble at the database section. The sqlite package is called sqlite3-ruby package has been renamed to sqlite-3. A proper install requires a
# pacman -S sqlite3
and then a
#  gem install sqlite3

I opted to use the Passenger Apache module rather than WEBrick because I plan to host production applications on this server eventually and it makes sense for Apache to serve everything. If you just want to play around with Rails, it’s probably a better idea to go ahead with WEBrick because Apache requires a little configuration.

Pacman will spit out some configuration information for Passenger and it’s important to get it right. Rails’ official Getting Started guide is specific to WEBrick so it doesn’t tell you that the Document Root line in your httpd.conf should point to the public folder of your rails application. I wasted some time staring at an Apache index trying to figure out why the app wouldn’t execute. Just do something like this:

<VirtualHost *:80>
ServerName rails.trillworks.com
DocumentRoot /path/rails/application/public
RailsBaseURI /path/rails
<Directory /path/rails/application/public>
AllowOverride all
Options -MultiViews

Don’t forget these lines either:

LoadModule passenger_module /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.7/ext/apache2/mod_passenger.soPassengerRoot /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.7PassengerRuby /usr/bin/ruby
RailsEnv development

That last line is vital to get the blog example from the Getting Started guide working smoothly. Passenger runs your app in production mode by default, but that won’t work because the migrate command in the guide creates tables in the development table.

The blog app in the guide has a decent introduction to Ruby’s take on MVC and how to wire up the various components. Stay tuned for some real apps.