Fix My Bugs

Almost every blog I read seems to have posts about building your own PC, so I figure I’d post one too.  The machine I built about 4 years ago packed up recently, just failed to power on.  Swapping components in and out didn’t fix things and I boiled it down to either the CPU, the motherboard, or the memory, maybe it was some dodgy wiring, heck, I dunno!  I can put components together to create a PC, no problem. I understand what each bit does, and to some degree how it does it.  I understand software far more intimately of course, but I imagine most programmers can put together the hardware on which they depend. When it comes to hardware failure diagnosis though, I’m out of my league.  My father’s school of thought is to replace the cheapest parts one by one until the cost of the next component to replace is more than the appropriate tool (or person) to diagnose and fix the problem. When you reach that point, weigh up the cost against a new machine.  He would do this with cars, whereas I do it with computers.

So, no problem, I thought, I’ll just buy a bunch of new components, a nice case and bingo, one new PC.  It’s not that easy though it is?  Where on the vast internet do you find easy to understand, appropriate advice on the parts you need for a PC of a given type?  I haven’t got days and days to research everything, I don’t know how many DDRs of RAM I needs, how many Watts of power,  2, 4 or i7 cores, and not even God could choose between the staggering array of graphics cards available today.

Luckily, it seems this area of recommendations is where paper based magazines seem to have the edge over the Internet.  In the latest copy of Custom PC magazine are a couple of pages detailing the components they would recommend for a PCs of a given budget.  There’s the budget PC of just under £500, the mid range at just over £750,  the performance PC at just over £1000 and the crazy but cool monster for £2300.  The performance PC is just what I need, give or take a bit more RAM here, and no need for a dedicated audio card there.  I’ll take an Nvidia card over an ATI too since they generally give much less hassle under Linux.  The Custom PC setup also uses an Antec Twelve Hundred case, which I think is a little too gamer oriented for my liking, so I’ve gone for a P182 instead.  Here’s the complete list of parts:

• Antec P182 Case
  

• Gigabyte GA-EX58-UD3R motherboard

• Intel Core i7-920

• 6GB Corsair XMS DDR3 Memory
• Crucial Ballistix Tracer 6GB

• Scythe Mugen 2 CPU Cooler

• Be Quiet! Dark Power Pro 650W Power Supply

• 2 x Samsung Spinpoint F1 1TB Hard Drive

• XFX 9800 GTX+ 512Mb Nvidia GPU Graphics card

All in, including Scan’s special idiot insurance in case  I break anything attempting to build the machine, it comes to just about £1000.  That’s about the same amount of money I always end up paying for a new PC.  My first 486DX4-100 was the same price, then my Home Theater PC which became my now dead general PC was the same too.  Hopefully the build will go without a hitch, but luckily I’ve got a couple of more hardware savvy friends who can help if needs be.

Update: It looks like the Corsair  memory wasn’t right for the motherboard, or I got 3 sets of dodgy sticks from Scan, which is unlikely.  After lots of forum reading I decided to get some more expensive, but reported compatable Crucial Ballistix Tracer 6GB RAM instead, and now everything hums along nicely.  I also splashed out on a second identical hard drive for some RAID 0 speed.  It’s not like the case is tight on space!

As a programmer, there will be a time when you have to think about software licenses. Notice I didn’t say ‘there might be’, I believe it’s inevitable. There are many licenses to choose from, and many ways you might want to protect and distribute code and programs you write.

If I post source code on this blog that I’ve written, either inline, or linked to in a zip file or something, then unless it specifically says otherwise, you can assume usage writes under the WTFPL v2. Credit for publishing this license goes to Sam Hocevar, on who’s web site, full details can be found. It’s so simple, I’m not even going to reproduce the text here!

I enjoyed writing about Triple Pop so much, I’m going to continue straight on with the next game I coded at iomo, Sky Diver.  Sky Diver was another white label game for Nokia, this time targeted initially at the 5100, but also later the 3510i.  The 5100 is technically very similar to the 7210, it’s another Series 40 v1 device, but is aimed at the ‘outdoor sports’ type person.  It has a rugged rubber jacket that’s splash proof and the promo material at the time showed people climbing mountains using it!  A game about sky diving was ideally suited to the device.

This time, the game was entirely new, there wasn’t an existing mobile game to base things on.  However, if you look closely, you’ll notice a vague similarity to Pilot Wings for the SNES!

At the time, we created designs for games  in one or two pages, and it was Glenn Broadway, iomo founder and creative director who visualised the ideas.  Indeed, they were mostly his initially, even if they were refinements of existing ideas or games.

Technically, creating a sky diving game for a mobile device actually turned out to be fairly straightforward.  My collegue Nick Reed (an amazing programmer who later became technical director of iomo and my boss at Infospace) wrote a few lines of code that demonstrated scaling and rotation on a set of points.  By rendering lines between the points it looked like flying down from a height onto an airfield. The MIDP 1.0 specification has basic line drawing methods, but Nokia added an additional API with functions beyond the standard. The early Series 40 devices didn’t have Mode 7 hardware sprite scaling and rotation, but they did have an API with 2D polygon drawing methods.  My job was to take the simple idea and along with artist Cameron Kerr, more input from Glenn, and QA from Nokia, flesh it out into the game it became.

Polygon Clipping

You can probably stop reading now if you don’t care about technical details!  I didn’t post any code from Triple Pop because basically there wasn’t anything generally useful.  In Sky Diver however, there turned out to be an interesting problem that needed to be solved.  When the points that described the ground polygons were scaled too much, as happened at low altitudes, the large values passed to the drawLine and drawPolygon methods caused them to become really slow.  I imagine there wasn’t any internal clipping performed on the geometry, only pixel clipping to the current screen clip region when attempting to rasterise the line to pixels.  This meant if you did drawLine (0,0,10000,10000), it look a long time!

To the rescue came the seminal Computer Graphics, Principles and Practice by Foley, van Dam, Feiner and Hughes.  It goes into great detail about line and polygon clipping, and gives algorithms in Pascal or C (depending upon the edition).  I wrote these Java routines directly from the algorithms in the book:

Sutherland-Hodgman Polygon Clipping in Java

Liang-Barsky Polygon Clipping in Java

To use the routines, you call them with arrays of points, and arrays to put the clipped polygon points into.

if(land_type <= Land_Runway || land_type == Land_Ground) {

   c = SutherlandHodgmanPolygonClip(num_points,
                                    poly_x,poly_y, // input verts
                                    clip_x,clip_y, // output verts
                                    TOP
                                    );

   if(c > 0) {
      c = SutherlandHodgmanPolygonClip(c,
                                       clip_x,clip_y,   // input verts
                                       poly_x,poly_y,   // output verts
                                       LEFT
                                       );
      if(c > 0) {

         c = SutherlandHodgmanPolygonClip(c,
                                          poly_x,poly_y,   // input verts
                                          clip_x,clip_y,   // output verts
                                          BOTTOM
                                          );
         if(c > 0) {

            c = SutherlandHodgmanPolygonClip(c,
                                             clip_x,clip_y,   // input verts
                                             poly_x,poly_y,   // output verts
                                             RIGHT
                                             );
         }
      }
   }

   if(c > 2) {
      // Draw the polygon as a series of triangles.
      // Here we assume that the polygon is convex, because the triangle
      // decomposition for concave polys is much more complex and probably
      // more time consuming than the poor performance of fillPolygon!
      for(j = 1; j < c-1; j++) {
         dg.fillTriangle(poly_x[0],poly_y[0],
                         poly_x[j],poly_y[j],
                         poly_x[j+1],poly_y[j+1],
                         colour);
      }
   }

} else {

   c = LiangBarskyPolygonClip(num_points,            // count
                              poly_x,poly_y,         // input verts
                              clip_x,clip_y);        // output verts

   if(c > 2) {
      dg.drawPolygon(clip_x,0,clip_y,0,c,colour);
   }
}

The code above picks the clipping routine to use based on the land type of the current shape being drawn, the comments for the clipping routines explain the best ways to use them. The fillPolygon and fillTriangle methods come from the Nokia DirectGraphics interface, but you could replace them with drawLine calls for wireframe rendering. If you’re looking for some clipping routines and find these useful, let me know with a comment. I might even put together a standalone J2SE demo if anyone shows any interest