Space Fish

Space Fish is a game that I worked on during the first Global Game Jam at the Raleigh-Durham site with Nick Darnell. The theme was ‘As long as we’re together, we’ll never run out of problems’.

It’s sort of a physics-sandbox game, where you can use your StarBeam to grab red or blue stars and fling them around.

Mindy the Space Fish is a persistent omnivore which will exist until the end of time. You are Mindy’s minder, feeding her pesky Red stars and keeping her from eating the pretty Blue stars.

As Mindy’s minder, you are free to ignore her. However, if you want to stick around with Mindy, your life will be full of problems.

Continue reading “Space Fish”

How to supress Warning LNK4099 – PDB ‘XXX’ was not found

When a library is compiled in MSVC with PDB support, but later distributed without the correct PDBs, anyone attempting to link with the library will get many warnings of the form:

warning LNK4099: PDB 'XXX' was not found with 'YYY' or at 'ZZZ'; 
linking object as if no debug info

You might think that it’s not a big deal: recompile the library to not use PDB files, or disable the warning. The former option isn’t available if it’s a 3rd party SDK without source code, and the latter option isn’t possible (more on that in a second).

At least in Visual Studio 2003 (7.1) and Visual Studio 2005 (8.0), 4099 is on a ‘non-ignorable’ warning list. This means that you can’t use /ignore in the linker command line options to get rid of it, brilliant! This is by design [1] and they don’t care enough to provide any other mechanism right now [2]. To be fair, both the /ignore switch and which warnings are non-ignorable seem to be undocumented, but someone else has made a handy list of them [3].

Now, you could probably live with it if there was just one warning per-library and you don’t really care about compiling with 0 warnings, but it’s typically hundreds of warnings, and we all know how slow VC80 gets when you spam the output window. So, since there is no sanctioned workaround, let’s do this the hard way.

How to disable the warning by patching your linker

The following are instructions that I wrote up for some friends in this situation, only tested on VC8, but it should apply to VC7.1 or VC9 as well.  Yes, I really am proposing that you patch your linker to ensure a clean build. If it helps you sleep at night, think of it as correcting a profound oversight by Microsoft. There just isn’t any other solution if you want to compile in debug mode against libraries you don’t have source for that were incorrectly configured.

You could go after the code that generates a 4099 and prevent it from ever getting generated, or the code that prevents it from being ignored. The second path is quite easy, there is a whole list of non-ignorable warnings which makes it trivial to correctly identify the list within the linker executable.

Fire up your favorite hex editor on link.exe (likely the one in “C:\Program Files\Microsoft Visual Studio 8\VC\bin”) and look for 4099 at 32 bits wide. The very first hit also has 4088 before it, and 4105 after it, bingo! I set it to 65535; pick your poison, but you probably want to avoid the 4xxx range. Hooray for no more annoying PDB warnings, at least until the next VS SP or VC9.

The usual caveats apply when modifying executables (Make a backup copy, validate what you’re attempting to change, no warranty express or implied, etc…). If you have a newer or older link.exe, the list of unignorable warnings may be different, or stored differently, so verify that the value you’re replacing is sane:

... F8 0F 00 00 - 03 10 00 00 - 09 10 00 00 ... (4088, 4099, 4105)

Once done, you can add /ignore:4099 to your linker options and it will actually work.

T27 Puzzle Game

A simple puzzle game with retro graphics

I don’t remember why I titled it T27, although it might have taken 27 minutes to make the very first version. All in all, I spent about a day playing around with the concept and here you have it. The main idea was to do something fun and fast with ASCII graphics so I didn’t get bogged down making it pretty.

T27 Gameplay

You play an owlish character (it’s hard to portray fine details in a 4×4 ASCII grid) who must defend himself from evil invading cubes. Your owl has the ability to grab cubes from the sky or throw them back, although he can only carry cubes of one color at a time.

These cubes come in a variety of colors and ones of the same color don’t get along well. If three or more cubes of the same color come into contact, they get into an argument and explode. Use this to your advantage and save the world!

After a number of grabs or throws, the screen will start to vibrate, indicating that another wave is approaching. Your owl can do two more things before the next wave comes, but he is fighting a losing battle, as the cubes never stop coming.

Reverse-engineering the WMB Prototcol

I took a graduate networking class and for my project, I decided to reverse-engineer the DS download play protocol (commonly referred to as Wireless Multi-Boot, due to ideological similarities with the GBA Multi-Boot feature).  This is the protocol underlying the ability for wirelessly transferring demos from a download station or another DS to your own DS.  Many games have the ability to transfer demos of the full game, or multiplayer clients for LAN gaming, and the kiosks are used in stores and at conferences to distribute game demos.

The project title was ‘Inferring a Proprietary Wireless L3 Protocol From Packet Traces’, and I gave a presentation in class, as well as a project report that had the technical details.  I’ve since placed all of that information on the NDSTech wiki.

Note: I was not the first person to do this.  FireFly did everything that I did first, but he did not publish any information on the protocol or source code for his tools.  However, his raw-mode driver for Ralink cards and the already re-assembled WMB captures made my life a whole lot easier.  A number of other people on the gbadev.org forums also provided vital insight (to both FireFly and myself).

aMaze – A game for visually-impaired children

I took the Enabling Technology class and worked in a group on the aMaze project, which provided a maze game to children with visual-impairments.  A 2D maze is simulated, and the child can walk around inside the maze using a keyboard, joystick, or Sensable haptic-feedback device.  Footsteps, simulated cane taps, and environmental sound sources are modelled in 3D, allowing the child to navigate by sound.  There is also a visual display of the maze and current position, which can be used for debugging or disabled if a child has partial vision and wishes to try it by audio alone.

The EVE group at UNC has a bunch of foam cubes that they use to construct interesting virtual environments, and we thought of asking a few children to come in and try walking a real maze and the virtual maze.  Some children would do the virtual maze first, and others would do the real maze first, and we could find out if they felt more prepared for the real maze after doing the virtual one.

The experience ended up snowballing (with the help of many) into a Maze Day with 51 visually impaired students and 55 adults visiting the UNC Computer Science department to view all of the class projects and previous research, instead of just aMaze.  Maze Day has since become an annual event, and will be held again towards the end of April.

Pictures from preliminary testing

Our aMaze team had a station with 3 computers, one with a keyboard, one with the joystick, and one with the Sensable Phantom.  We also made a real maze (complete with wolf and elephant sound sources played back at the bends of the maze) constructed in a room that matched one of the virtual mazes that were being shown.  By navigating the maze using the computer beforehand, the general consensus was that it was much easier to navigate the real maze.  Maze Day was a lot of fun, and we were proud to be a part of it.