I am taking a break (semi giving up)

I have been working for like a week trying to get a PointSprite-based particle system working. It hasn't. So far, I have shown exactly NOTHING on the screen. Quite frustrating, I must say. I am going to leave that, and get something else working for now.

SpaceRocks! v0.0.6

Today, I fixed the screen shot code. I realized, after thinking for a few minutes, that the old code was taking the screen shot, from the back buffer, before the the back buffer was drawn to. That's why my screen shots started coming out blank. I hadn't actually run any drawing code yet, so the back buffer was just black.

Anyway, here is a picture of the game, in all its glory. Notice the new bullet images, the larger asteroids, the explosion, and the score in the top left.

Programming tip

I had to perform a particular task today, one which I have had to do several times before. I thought I would share it. I'm not sure if you guys all already know how to do this, but here goes.

public int DoSomeWork(int a, int b)
{
    return a * b / 2;
}

What we need to do is change the method, so that we can pass a value to divide by, instead of just dividing by two. The catch is that we have several classes, spread across multiple projects and multiple solutions, that all call this method. The chance of missing a call to this method in a different solution is pretty high in this case. How do you make the change without breaking existing code? Here's my technique, which I have implemented at least two dozen times in the app I worked on from 1/05 to 5/06.

public int DoSomeWork(int a, int b)
{
    return DoSomeWork(a, b, 2);
}

public int DoSomeWork(int a, int b, int c)
{
    return a * b / c;
}

Now, all existing calls all work properly, using the default value that was originally hard-coded. In addition, we can now take advantage of the new functionality going forward. I have found, in my experience, that we generally add a boolean to the method signature, and have an if statement that triggers on that boolean. It works for any type of parameter, though.

Hope this helps you guys.

SpaceRocks! 0.0.6

I fixed the display bug in SpaceRocks!. I also changed the bullet class to a cooler sprite, and tweaked some code. The large asteroids are now 50% larger as well.

Check out the revised alpha version:
www.CSquaredComputing.com/Products/SpaceRocksSetup.msi.

Live.com

Ok, I get live.com.

Today, I read an entry by Rick Strahl stating that he doesn't get live.com, particularly because the interface was non-intuitive. Here's the link: http://west-wind.com/weblog/posts/5290.aspx.

That post prompted me to check out live.com. I don't get what he doesn't get. When I logged in to my passport account (using the 'sign in' link at the top right), I saw my email right away, and a bunch of crap I wasn't interested in. Each section of crap had a little 'X' that I clicked on, to get rid of it.

The top left of the page had a link to '+ add stuff'. I click that, and I get a cascading menu of options to choose from. I click the add button, and it shows up on my page. In 5 minutes, I had the crap removed, and 8 sections of stuff I care about showing up. I didn't like the layout, so I dragged-and-dropped the sections around, until I was happy with the organization.

There are some cool options for stuff, too. I have one called peculiar postings from MSNBC.com. The first entry is titled 'Mom's corpse is my co-pilot'. That is an article that I have to read.

I particularly focused on the weather gadget. It showed me Seattle weather by default. That makes me happy, since we are moving there. I didn't like the size of the gadget, so i clicked the little caret to minimize it. Now I have a one-line entry that shows cloudiness, low temp, and high temp for Seattle. But wait, I live in Jacksonville still. So, I maximize the gadget, and click the plus sign. Type in Jacksonville, FL, and I get both Seattle and Jax weather. Since I'm in Jax still, I drag and drop jax above seattle. Now, when I minimize, I see that it is partly cloudy in Jax, with a low of 67° and a high of 91°. And the 91° is even in red, so I can see that it's freakin hot today.

Five minutes, folks. Normally, I don't really push the new MSFT stuff, but I might actually change my homepage away from Google to live.com now. There's a search bar at the top, which presumably uses MSN search, but I get all this other great free content.

I am a happy consumer.

Memory & performance optimization for today

Originally, whenever a new object was created in the game, the texture for that object was read from disk, and a new Microsoft.DirectX.Direct3d.Texture object was created, using TextureLoader.FromFile(). I realized today that this approach was crazy wasteful.

At any given time, there can be up to 50 bullets on screen. The texture for the bullet is 256 B. In addition, there can be up to around 20 asteroids. The asteroid texture averages 80 KB. So, worst case, we would be using roughly 1600 KB (1.5 MB) of memory, just to hold the textures!

Here is the original code(called every time a game object was created):

protected TileSet GetTileSet(
    Device dev,
    int rows,
    int cols)
{

  string path = Path.Combine(AppSettings["ImageDir"],
     TextureFileName);
  if (File.Exists(path))
  {
    texture = TextureLoader.FromFile(dev, path);
    return new TileSet(texture, 0, 0, rows, cols, 16, 16);
  }
  else
    throw new FileNotFoundException("Texture not found.");
}

So, every time we created an object, we were reading from disk, and adding more memory, to hold the texture.

Here is the new code, split into two parts:
(Called once per game session)

public static void LoadTexturesFromDisk(
    string texturePath,
    string searchPattern,
    Device dev)
{

  string[] texList = Directory.GetFiles(
     Path.GetFullPath(texturePath), searchPattern);
  if (textures != null)
  {
    textures.Clear();
  }

  textures = new Hashtable(texList.Length);
  foreach (string texture in texList)
  {
    TextureManager.textures.Add(
        Path.GetFileName(texture),
        TextureLoader.FromFile(dev, texture));
  }
}

(Called every time an object is created)

protected TileSet GetTileSet(
    Device dev,
    int rows,
    int cols)
{

  return new TileSet(
    TextureManager.Textures[TextureFileName] as Texture,
    0, 0, rows, cols,
    TexturePixelDimension,
    TexturePixelDimension);
}

So, now, we have each texture in memory exactly one time, in a static variable. Each object then references the correct texture, basically by using a pointer, thereby saving both disk IO time, and significant memory space. The maximum texture memory footprint for asteroids and bullets is now ~367.5 KB. The savings aren't as great as you would expect, since there are 9 textures for asteroids (three different sizes, with three different types). Still, the memory requirements are now one quarter of the original.

Pretty good savings, for one new method, and a couple of lines of code.

Project Plan update

From the post http://cullenwaters.blogspot.com/2006/04/revisiting-spacerocks-plan.html, in the v0.5 - v1 section, we see this entry:

2-3 hours: Add sound effects [v1-1 hour][v2-2 hours] In progress, with about an
hour to go

Today, I finished the sound effects, after working for about .5 hours. In addition, I spend about 1 hour creating a setup project, refactoring some code, and refactoring the project heirarchy.

That brings the total development time to about 24 hours. Definitely on schedule.

SpaceRocks! alpha version

Today, I fixed a problem with the in-game sound. The game had been crashing, when I tried to clone a sound. The problem only showed up when you fired several bullets at once, in such a way that all of the existing SecondaryBuffer objects were playing, and you needed to create a new one.

I fixed that, and did some refactoring today, as well as creating a quick and dirty setup project; about 2 hours worth of work.

As promised, here is the link to SpaceRocks!, alpha version. Play it. Enjoy it. Have fun. Let me know if it sucks.

www.CSquaredComputing.com/Products/SpaceRocksSetup.msi (1.3 MB)

There is one bug that I have seen, and am aware of. Some of the asteroids' textures are messed up. Actually, it's only on medium asteroids, of type 1 and type 3. I'm pretty sure the problem is just the artwork. I'm going to track down this problem next. If you see asteroids that seem to be rotating around some point that is non-center, that's the bug I'm talking about.

The controls are as follows:

• <a>- left
• <d>- right
• <w>- thrust
• <s>- reverse thrust (this is only for testing purposes, will not be in the release version. Also, this command acts 5x as fast as the thrust command)
• <space>- fire
• <q>- end game (simulates dying)
• <esc>- exit game (leaves the program)

Make sure you have speakers connected, and sound turned on. I'd hate to see all my work debugging the sound player go to waste ;)

[Edit: added known-bug note]

Revisiting the SpaceRocks! plan

A while back, I posted a project plan for my clone of the asteroid destroying game. In case you didn't notice, I changed the name from RockCrusher to SpaceRocks!. I'm going to review the plan here, and show my current progress.

I will reproduce the entire plan, and show the time I spent on each part. Some of this stuff happened months ago, though, so it's all just an estimation. Actual times will be in square brackets ([]).


Nominal Project Plan

• 1 hour: Get Managed DirectX to display a black screen [.5 hours]
• 2-3 hours: Design the class framework for the game [1 hour]
• 2 hours: Develop classes for the player ship and the asteroids[1 hour]
• 1 hour: Display the ship on the screen[3 hours] This task turned out to be frustrating. I missed two critical lines of code, and didn't tell DirectX that I was about to start drawing sprites. This caused Invalid Call errors when I rendered, and I couldn't tell what was causing the error. However, once I got the sprite problem worked out, I got asteroids on screen for free.
• 1 hour: Display some asteroids (included in time above)
• 3-4 hours: Design the physics simulation system [0 hours] I decided to strip the gravity from the game, as well as friction. I may add friction back in, but for now the only forces in the game are velocities and accelerations. The ship is the only object that feels any accelerations, the rest move at constant velocity.
• 1 hour: Apply the physics engine to the ship[0 hours] Removed when I pulled out the above entry.
• 1 hour: Apply physics to asteroids [0 hours] Removed when I pulled out the above entry.
• 2 hours: Handle player input for the ship(DirectInput) [1 hour] This was a lot easier than I thought it would be. Currently, the game only supports keyboard control. I'd like to add mouse and joystick in the future.
• 3 hours: Make the ship wrap when hitting the edge of the screen [1 hour] Once I got around to it, this was trivial. The code works for all game objects, including ships, bullets, and asteroids
• 1 hour: Make asteroids wrap when on the edge of the screenCompleted above
• 2 hours: Add a bullet class [1 hour] Since the bullet class inherits from the game object class, most of the code was trivial. The artwork is still subpar for the bullet, though.
• 1 hour: Get ship firing bullets [2 hours] This took a little while to get right. There are still some tweaks to be made to bullet offset and velocity.
• 2 hours: Make bullets his asteroids [2 hours] Since most of my objects are easily approximated with spheres, collision detection is incredibly simple. This collision detection handles bullet to asteroid collisions, and asteroid to ship collisions.
• 1 hour: Make asteroids explode when their damage threshold is reached [.5 hours] The code to kill the asteroid was pretty easy. The harder part was splitting it, which I did at the same time. The time for splitting is further down the plan, though.

That's already 28 hours of work. [There were 13 hours to get to this point in the game's development. I was way ahead of schedule, in development time. I thought that the actual elapsed time would be shorter, but I got discouraged a couple of times, and took some time off to get away from it. Now, the code is flowing.]

At this point, I should have a playable game, v0.5

For the next version, 1.0:

• 2 hours: Add scoring [1 hour]
• 2-3 hours: Add sound effects [v1-1 hour][v2-2 hours] In progress, with about an hour to go
• 2-4 hours: Add levels [2 hours] during this time, I also worked on the code base a bit, cleaning things up, and tweaking the constants
• 1-2 hours: Make the asteroids break into smaller asteroids when you blow them up(this should be a random choice) [2 hours] This was tricky. I created a couple of events in the code to handle this, and that caused some problems, because the events were firing at funny times during the game cycle. In hindsight, I should have just taken care of this as part of the updating phase of each frame, instead of using events
• 4-5 hours: Add alien spaceships that can shoot back once you reach a certain level
• 2-3 hours: Give the aliens some AI
• 1-2 hours: Track a high score board [2 hours] I wrote a class in my game engine that can track high scores, as well as persist the scores. There is a helper class that represents a score. This class should be useful for all games, and is fully code-covered (I used TDD writing it)
• 2-5 hours: Implement a particle system, and provide particle-based thrust effects during player maneuvers I removed this feature. I just can't get it to work. I think there must be some incompatibility between rendering with sprites, and adding in PointSprite rendering. [6 hours] I finally got this feature to work. I'm pretty pleased with the final results.
• ? hours: Improve artwork
• 10 hours: Finish UI work (high score board, menus, help, etc)

That's another 19 hours, for a total of 37 estimated hours.
So far, we are in really good shape for time. I'm about 15 hours ahead of schedule, and could, with only a little embarassment, publish the game to friends and family now. There's a lot of polish still to be added, but the basic gameplay is complete.

Where do we go from here?
The next step is to iron out the bugs remaining in v2 of the sound control classes. I'm trying to add support for multiple instances of the same sound playing at the same time. This is a little tricky in DirectSound. I can handle multiple sounds, as long as they are from different .wav files. If you fire twice in succession, though, you only hear the first shot sound.

After that, I should be able to breeze through most of the items left for v1 of the game, and then I will be publishing it. Once I get the sound fixed, I will post an alpha version of the game, so you guys can check it out and let me know what you think.

[Edit: fixed a couple of places I was missing strikeouts.]
[Edit: I'm going to keep this entry up-to-date, so I marked off the sound time]
[Edit: added particle system and thrust effect feature]
[Edit: added task for UI work]

Geeking with Greg: Google Cluster Architecture

Geeking with Greg: Google Cluster Architecture

In this article, there is a quote that just struck me.

Google quite literally stores a copy of the entire web to implement their
snippet feature.

I assume that everyone knows what he means by snippet. That is the little part of the page that Google shows you when you do a search, I've always thought of it as proof that they really did find your search terms on the page. I have found that this feature is incredibly useful during searches, since it lets you check the context in which your search terms were found.

The hardware and software problems being solved by Google stagger me.

An OFFER!

I got an offer from Microsoft! Can you believe that?

The salary isn't quite what we were hoping for. It's actually a small step back, if you take cost of living into account. I'm getting about a 10% increase in salary, but we are taking a 20% hit on cost of living.

There are other compensations, though. The benefits are amazing. We don't have to pay a penny for full medical, dental, and vision coverage for the entire family. No copays, no premiums, no prescription costs; nothing out of pocket, ever.

The dress code is lax. As far as I could tell, you just couldn't be naked.

Completely flexible time. One of the test managers I interviewed with normally comes to work around 11am, then heads out for a couple of hours in the afternoon, to go sailing, then works till about 2am. Apparently, MSFT is really big on work-life balance, and letting you set that balance for yourself. I must have heard that work-life balance phrase 30 times Monday.

The relo benefits are awesome. I'm going to come out ahead, because they give you a $750 check for incidentals. Plus, we get an all-expense paid house hunting trip.

I'm also going to get a signing bonus (about 10% of my current salary), and a stock grant (which, at today's prices, is another 10% of my current salary).

It's going to be really hard for Courtney to leave her family, since she hasn't ever lived away from them. It's not as hard for me, since I had the whole Marine Corps thing to prepare me.

I have some doubts about whether this is the right thing for us, mostly centered around taking Mik away from her extended family, and taking us away from our support network.

Of course, this isn't necessarily permanent. We can always come back if we hate it, which I don't think we will.

Right now, I'm sticking with stoked about the big adventure. The worst part about it was having to send Eric Sink an email telling him I wasn't going to come interview, since I already had an offer from MSFT. I really feel like I would be failing my family to turn down a solid offer from a great company like MSFT to go interview with a great company like SourceGear. Had I received the same offer from both companies, at the same time, I would have needed days to decide which to accept. MSFT just got in there first, with a concrete offer.

Stay tuned, and I'll provide more information as I get it.

Whew. What a long day

First interview starts at 8am. Last interview (6th) ended at 5pm. For those of you keeping track, that is 9 hours of straight interviews. Even at lunch.

By the way, lunch was at the MSFT cafeteria. The burger was pretty good, the fries were not.

So, what should you expect when interviewing with Microsoft? Data structures. Then more data structures. Then, after that, a few more data structures.

Every one of my interviews went about the same. Meet the interviewer, get a problem description from them, and then do some coding. After you solve the technical problem, come up with a bunch of test cases to test this algorithm.

Here are the specific algorithms and questions, as I can remember them:

1. Given a binary tree, and a number, find the item in the tree that has the next highest value.


2. Given a binary tree, create singly-linked lists that connect all of the nodes at each level. So, all of the sibling nodes in the tree should be connected to each other, in a list that goes from lowest to highest values.


3. You have a 100 element array of integers. The values 1-100 are in the array, but in random locations. I will take away one of the values, and replace it with a zero. Find out which value was removed. The best solution I could come up with worked in a constant O(n) time. My first solution was found in O(n²) time.


4. Given two arrays, A and B, of unknown length, determine if the array B is contained inside array A. So, B contains a list of integers. We need to know if that same list of integers exists anywhere in A.


5. Implement the String.Split function. Except, instead of passing in a character as the delimiter, we will provide a string delimiter. Memory utilization is important for this one. Try to implement the algorithm without any memory overhead beyond the strings passed in to the function.


6. Given the 'Save As' dialog from notepad, come up with test cases for the file name textbox. I came up with about 30 test cases, which would have resulted in thousands of permutations.

Some suggestions:

• Get extra sleep. 8 am comes early, and I did the worst on my first technical interview. The 3 hour time difference messed us up here.


• Study up on data structures. You need to know about every data structure from your class, to include linked lists, queues, stacks, hash tables, and particularly binary search trees.

I'm supposed to find out tomorrow if they are interested in offering me a position. The 5 hiring managers are apparently going to sit down in a room together, and come up with a decision about which team(s) will offer me a position.

Oh yeah, and I found out something else. It's taboo at MSFT to bypass the system, which I sorta did. There were raised eyebrows when my recruiter learned that an SDET took me around Seattle on his own time, without being asked.

There are two teams on the Office Live group, Core Services and User Experience. So, those are the two teams that will have the option to present me an offer.

More updates to follow.

Seattle is amazing

Courtney and I both love Seattle. Actually, to be technically correct, we both love the Seattle area.
It's really beautiful here. We took a bunch of pictures today, here's a link: www.TheWatersFamily.Shutterfly.com.
Only one hour from real, full-on mountains. I can't wait to get my bike here, and go for weekend rides. I've got to find a group of sport bikers in the area as soon as we get moved. There are a surprising number of riders out today, considering the 47° high temp today.
Interviews tomorrow. I am really nervous. Every other time I interviewed, I was pretty sure I would get an offer. This is the only job I've ever felt like I was more 50/50 than 90/10.

Big huge news

I've got a Microsoft interview scheduled! Courtney and I are going out to Seattle for 17-21 March, with my 5 SDET interviews scheduled for March 20th.

I had two phone screens before this, one with a recruiter, and one with a test manager.

MSFT presented me with 4 teams that are interested in talking to me. Guess how they choose which ones I interview with (you can only interview with 2 teams)? They asked me which ones sounded coolest to me.

The four teams were(in my coolness order):

1. Office Live
2. Small Business Accounting
3. Dynamics CRM
4. Setup and Deployment (.NET Framework)

I'll let you know how things went, and what a MSFT interview day is really like in my next post.

Amazingly relevant quote

I am finally reading my copy of Code Complete, 2nd Edition. I've had the book for a while, but couldn't get past the first chapter the last time I tried to read it. This time, I skipped the first chapter ;).

Anyway, here's the quote:

We try to solve the problem by rushing through the design process so
that enough time is left at the end of the project to uncover the errors that
were made because we rushed through the design process.

--Glenford Myers

Other than the fact that we ignore the design process, instead of just rushing through it, this quote really applies to my current company.

Revelation day

Today, I told my boss Steve that I would be leaving my company on May 1st. I have accepted an offer from Microsoft, and Courtney, Mik and I will be moving to Seattle May 7th or so.

Tomorrow, I will post a series of entries detailing my experience with MSFT, focusing on the interview process. I wrote them a while ago, and have been waiting to post them until after I announced my leaving.

Stay tuned.