OMSK Pong

OMSK Pong is a Nintendo 64 Homebrew game developed by Omsk and published 04 June 1999 on dextrose.com. The game, as you might expect, is a Pong clone. It’s a great place to start when developing games for a particular system. There are a few things that make OMSK Pong interesting:

• The source code has been made public.
  • Images are saved and convered as ppm files
  • There is a .map file. There were no such files in any of the demos included in the SDK.
• There is a rather long readme with some details about the development process.
• Was compiled using PI.
  • This means that the Makefile and Spec file are completely different or absent. The C code is similar to normal N64 C code though.

You can find the source code and the .v64 ROM file for the game here.

Video

The game is about as basic as it gets. It’s a Pong game that allows fora 2-player mode or a one-player mode versus an AI. The game features several images of aeroplanes for the menu screen and each of the result screens, plus a faded background of anime girls for the actual gameplay. The winner is the best of six. The game contains no sound effects or music.

As a game it works alright. The worst part is that when a point is scored, the pallets snap back to the middle (which is disorienting) and the ball/puck starts moving right away. This makes it very easy to miss a shot right after scoring one.

Readme

Looking through the readme file is quite inspiring if you ask me. It doesn’t go into much detail as to what went into developing the game, but we can tell a few things about OMSK Pong from it.

The game was developed using code snippets from Dextrose and a good old fashioned C programming book with some elbow grease. A Doctor V64 was then used to load the ROM onto the console. Omsk converted the image files (ppm format) using the PPM2C program by a user called Widget. I suppose that it does something similar to what my X2C program does.

Besides that, there isn’t much to the OMSK Pong Readme apart from the special thanks to all the people that helped with the code. And let’s not forget my favourite quote:

So if you want to code stop reading this fucking NFO file and start reading at some source code

Code

This code is quite useful to analyse since it has all the basics of making a game, except for the sound, of course. Oddly enough, it follows a similar structure to that of other demos I’ve  looked at such as nu0. It has a main process, it has a definition for the z-buffer and frame buffer, it has display lists and all that fun stuff.

Since there is no spec file included in the demo, I guess it’s safe to assume that the boot function is located in BOOT.C. The purpose of this file is to initialise the operating system and start an initial thread which launches the mainproc function. Nothing really out of the ordinary, but good to have it as reference for some useful function in the setting up of threads.

The bulk of the game code though resides in the MAIN.C file. Within this file, there are two important functions: mainproc and DemoLoop. Let’s have take a look at mainproc first:

void mainproc(void * arg) {
        /* DMA static segment to ram */
        osPiStartDma( & dmaIOMessageBuf, OS_MESG_PRI_NORMAL, OS_READ,
                (u32) _staticSegmentRomStart, staticSegment,
                (u32) _staticSegmentRomEnd - (u32) _staticSegmentRomStart, & dmaMessageQ);

        /* Wait for DMA complete */
        (void) osRecvMesg( & dmaMessageQ, NULL, OS_MESG_BLOCK);

        /* Start rocking */
        DemoLoop();
}

It’s pretty straightforward – it takes the segment (which would usually be defined in the spec file) and loads it into the RDRAM. Then it waits for it to complete and then loads the DemoLoop function which is the actual gameplay for OMSK Pong.

I won’t get into too much detail regarding the rest of the code in DemoLoop, but I will mention some odd ways in which it’s coded. However, there is something that I find a bit odd. It might be the case with other dextrose-era homebrew games, but display lists are run completely differently. Rather than creating a display list and then executing it, the DL is bookended like so:

InitDL();
guSprite2DInit( & MySprite[6], title, 0, 320, 320, 240, G_IM_FMT_RGBA, G_IM_SIZ_16b, 1024, 1024, flipx, flipy, 0, 0, 0, 0);
gSPSprite2D(glistp++, OS_K0_TO_PHYSICAL( & MySprite[6]));
ExecDL();
EndDisplay();

A bit odd, but it works. Rather than having to constantly build display lists externally and then reference them, they are built straight into the code. I guess it makes the coding process a bit more stright forward. Have a look through the source, I’m sure you’ll find more interesting tidbits here and there.

OMSK Pong Gallery

Title menu.

Game screen.

Draw screen.

Player one wins screen.