XNA Blog

Today i finished Pit. It is running on my xbox 360 right now and i am currently in full retro mode - almost played for two hours before i was finally able to pick up my camcorder and do a little video of the gameplay. Here is an embedded youtube link to a little presentation of the game:

I am quite pleased with the final result. The game is just as playable and enjoyable as the 25 year old original plus it runs on my favourite console. Concerning the control scheme i decided to take a somewhat unconventional way. As i wanted to do it digital and the digipad of the 360 is plain and simple the most horrible one i ever encountered on any game system i went for the shoulder buttons. There is just going right or going left anyway so that seemed like a good approach. Turns out it works pretty well.

Here is a link to the published windows binary. I decided not to release the source because i am shure the only thing someone could learn from it is how to produce bloated and inefficient code. If someone is interested in the source for running the game on the xbox360 contact me via email and i will send it.

In case someone knowing the original Pit is reading this: Yes, there are several differences to the original which i implemented on purpose:

o There is no extra screen after loosing a life telling your score and how many lifes you have left - that information is readily available from the main game screen so i don’t see the point (apart from annoying and generally irritating the player)

o There is no extra game over screen because i think the avarage-intelligent player will very well notice when he wasted his last life.

o When hit by one of those deadly raindrops (yeah, i did some research, those falling things are not stones, they are supposed to be raindrops) you will not be greeted by that annoying color-strobe effect of your remains.

o The walking sounds are different. (Thats actually myself now making clicking sounds in front of the integrated micro of my laptop). That is because i couldn’t get my audio software to record those faint walking sounds and i didn’t have the nerve to mess around with a machine monitor in my vic-20 emulator to hunt for the original sound data.

o I modified the instructions screen to my new control scheme (keys a and d or gamepad shoulder buttons). While doing that i took the liberty of centering some of the lines to make it a little less optically appalling than the original (have a look at that here).

Now that i have done Pit it soon will be time to think about the next project. It will either be a port of my ‘Scharping Attack’ space invaders clone or another VIC-20 or C-64 game port.

Today i made serious progress with ‘Pit’. Starting from scratch i began by displaying the sprite representing the ground (yeah, great achievement…). After that i did the three blockades that stop the stones from falling on your head but slowly deteriorate from the impacts. Implementing the falling stones presented me with the first real challenge. I wanted to code them as a list of a struct, but that approach grinded to a sudden hold when i didn’t manage to change the struct values (namely the y-position) in a foreach loop. After almost two hours of trying to get that to work (searching the web din’t help much) i decided to screw that and went for an array instead. Feels a bit clumsy but works, so who cares - it’s my first XNA project anway.

The next thing was to code the collision detection between the stones and the barrier - using ‘higher’ programming languages as blitz basic i was accustomned to do that by calling already existing functions - here i had to do it all by myself. After a short time i realised it wasn’t that big of a problem though, it went quite smoothly.

So here is what i have as of now:

Falling stones, randomly generated. Collision detection between stones and barriers with code that handles the decay of the barrier. A player sprite that can move and collision detection between that sprite and the falling stones. So what do do now is implement further game logic (score, loosing life if hit by stone and the collecting/delivering of the main objective, namely the money bag). I also have to do the title and instruction screens and plan to do a little intro simulating the loading of the game using the VIC-20’s LOAD “PIT”,8 command.

In the screenshot on the upper left you can see the number 597 which actually is not the score but represents the x-position of the player sprite and is generated by an instance of my CommodoreTextscreen class - that class came in quite handy for providing realtime debugging information right on the game screen several times today.

I realise this is a very simple and primitive game but considering that i did not have any C# nor C++ (and very little C) experience before starting this blog i am quite pleased with the progress i made. If there are no more big obstacles to overcome the game may even be finished tomorrow. I will definately make an xbox 360 version of it and coding the gamepad control system may be the biggest remaining challenge as i don’t know yet if i should go for analog or digital controls, so there may be some experimenting to do.

Well, almost. I did not implement lower case characters yet (never liked those on the original so i may never do that) and some of the character symbols are not printable yet. Anyway, the class is in a state that is perfectly usable for my ‘Pit’ project, so i think i will get back to that soon.

Here are some examples of the textscreen class at work: The first one shows how the screen of a standard VIC-20 looks like after the machine is powered on. Notice the ridiculously large amount of 3583 basic bytes free (the machine had a total of 5KB memory).

The second picture shows some of the printable characters (letters, numbers and symbols/special characters). The characters can be either printed normal or inverted.

The third one shows an exact replica of the instruction screen of ‘Pit’. Yes, it actually looks that ugly.

By the way, i made up my mind concering the aspect ratio and virtual pixel size i am going to use for ‘Pit’. Despite my desire to use as much of the 16:9 display as possible, i decided to go for the original 4:3 ratio (as depicted in the screenshots above). That of course means i have to redraw all sprites which isn’t too bad considering their whopping number of… 14.

One of the two (maybe three) readers of this blog may remember me writing about getting sidetracked easily in my second blog entry. Guess what - yeah, right. It happened again. Originally i intended to code some game logic for ‘Pit’ today. Just as i was about to start one big question came to mind: Should i utilize the object oriented programming capabilities of C# or stick to the classic way and stuff everything in one class regardless of that making sense or not. The second choice seemed kind of like cheating so it was time to do it the hard way.

While writing the commodore-charset scrolltext i already ratted out from using oop, so this time i wanted to do it the proper way: Creating a class devoted to handle screen output concerning the original Commodore charset. Some hours after starting that attempt i can say that i finally start to grasp the basic(!) concepts of oop. At least i think so. Anyway, here is what was achieved today:

I did a class that on instantiating sets up a text-screen represented by an array of up to 100×100 characters with absolutely free choice of pixel ratio and onscreen positioning. A VIC-20 screen for example would be set up with

screen1 = new CommodoreTextscreen(@”Sprites\pixel”, 22, 23, 4, 3, 450, 44, Color.DarkGray);

That would result in a screen consisting of 22 columns, 23 rows with a virtual pixel ratio of 4 pixels width und 3 pixels height. The offset from the top left of the display would be 450 (real) pixels horizontally and 44 (real) pixels vertically. Background color would be dark grey. That is the one you see in the picture to the right. There are 2 other instances of the CommodoreTextscreen on the left side (black background, tiny font) and on the bottom (blue background, tall font).

After instantiating the screen there are several methods i can use on the screen:

screen1.Print(string, col, row, color) will print a string into the screen array (called from the update method of the parent class).

screen1.DrawScreen() will actually work through the SpriteBatch neccessary to plot the content of the array onto the display (called from the draw method of the parent class).

screen1.ClearScreen() resets the array to blank.

screen1.PrintXY(string, xlocation, ylocation, pixelwidth, pixelheight, color) If i don’t want to restrict myself to the columns/rows of a predefined screen size this method can be used to draw a string using the commodore charset in any x/y pixel ratio on any physical position on the display. This method was used for the ‘BIG’ and ‘TEST’ output on the screenshot. This one has to be called from the draw method of the parent class.

Right now the CommodoreTextscreen class can only display capitalized letters and blanks, so the next thing i have to work on is how to encode all those special characters from the PETSCII charset into something i can represent in a standard C# string variable. Furthermore i think some values of the screen instance will be done as properties so they can be changed on-the-fly.

XNA is fun!

So back to my conversion of the old VIC-20 game ‘Pit’. As my first priority is a Xbox360 version of the game the screen resolution i am going for will be 1280×720 (Windows version will have that resolution, too). The VIC-20 had a resolution of 176×184 - sounds odd, but you have to take into account that the pixels had a width/heigth ratio of 13/10 resulting in a (subjective) res of more like 245×184.

Doing some calculations i soon realised that, alas, i had a little problem here: As written in my last blog entry i want the graphics to be as close to the original as possible. If i wanted to go with the original 4:3 aspect ratio and keep the distinctive pixel-form the highest possible resolution that fits inside the 1280×720 screen would be 880×552 and i would end up with a screen usage ratio that sucks about as much as it does in other xbox live arcade remakes.

I don’t mind wasting parts of my tv-screen to get the real experience (i like 2.35 widescreen movies and the black bars don’t bother me at all). But this is a little extreme, so there has to be a compromise! The next thing that came to mind was to stretch the picture horizontally, just as many widescreen tvs do with 4:3 signals. (Even VICE, the VIC-20 emulator does stretch the screen output to almost 16:9), so i shortly tinkered with the thought of doing the same which would have ended up looking somehow like that:

Seeing there still would be a large part of the screen idling around and the stretching would be very obvious i dismissed that alternative quite fast. The third option would be to use a pixel (and therefor aspect) ratio of 6:4 - this would fill almost all of the screen’s width while beeing only slightly stretched horizontally compared to the 4:3 ratio. This solution comes with a price, though: The real resolution of this variant is 1056×736 - so vertically there would be 16 Pixels cropped from the output. That is exactly half a character row - 4 virtual pixels.

I think i can live with that, at least for this game wich has quite a lot of ‘headroom’ anyway. So here are the ‘Pit’ sprites repainted with 6×4 pixel blocks (image was resized of course):

Yes, that’s all there is concerning graphics (with the exception of the title screen which is drawn with symbols of the original charset). Ah, that were the times a running-animation consisted of only two frames…..

Well, the next step will be to actually code some game logic, which i will start tomorrow.

That’s my problem - i get easily sidetracked. In my last post i listed the potential first projects for starting my exciting xna adventure. Well, late in the afternoon i decided to go for the Pit remake bringing some old VC-20 magic to the Xbox 360 and Windows. Immediately after making that decision it was clear that i wanted to stay as close to the original as possible. That, of course, includes to use the original Commodore charset for the project. So i started to search the internet for a bitmap font that came as close as possible to the real charset.

I found one, but soon realized that it lost its authenticity as soon as i tried to scale it - it just didn’t look right anymore. So there was only one way to go: I obtained the original dump of the VC-20 charset rom which consists of an 8×8 binary matrix of the original characters, an ‘A’ for example is represented as follows:

000111000 (hex 24)
001000100 (hex 36)
010000010 (hex 66)
011111110 (hex 126)
010000010 (hex 66)
010000010 (hex 66)
010000010 (hex 66)
000000000 (hex 0)

Simple binary logic - a ‘1′ is where a pixel is to be drawn, a ‘0′ where not.

I always was fascinated by the demo scene in the good old C64 and Amiga days, so the first test how to bring the VC-20 character rom on the Xbox 360 screen logically was to code a simple scrolltext routine. Who doesn’t like scrolltexts? Seriously!

So here is what i came up with after my first day with xna - at first i sort of exaggerated what i was able to do and in my megalomania tried to code a whole class devited to do all sorts of output using the 8×8 charset. After realising there was so much more to learn before doing that i decide to start really simple:

This is basicly a very simple tile engine which uses the data of the VC-20 character rom as the map (which is generated on the fly depending on the text which is to be scrolled). Nothing big at all, but it was very rewarding to see it on the ‘big screen’ running on a 360 console.

It uses a single sprite (25×25 pixels) that represents one pixel of the charset, so the original data is upscaled without loosing any detail. any fancy bitmap font would have looked much better, but this is the spirit of ‘oldskool’ and it was a good exercise before starting something scary such as coding a real game.

Anyway, i feel more confident now - achievement unlocked.

PS: Never mind the jerkyness of the video - in reality it really looks quite smooth. I swear. Really.

So here i am, planning to play around with the new XNA from Microsoft. If you read this you probably know what that is, so i will skip further explanations.

This blog will document my process (if any) in learning the ins and outs of C# and the XNA game studio. I will also post news and point out interesting XNA projects.

Right now i am learning the basics about C# - never did oop before, so everything is quite unfamiliar to me. I am not entirely new to programming though, so i think i will get everything sorted out eventually.

At the moment i am just playing around and reading some tutorials. I plan on doing one or more of the following primitive projects which i already implemented in the past mainly using Blitz3D:

- Scharping Attack - Typical ‘Space Invaders’ clone, using the face of a (formerly) well known german politician as the aliens. Was planned out as some sort of satire but ended up being just ridiculous. Funny, nontheless.

- Dirks’ Brainquest - Two player maze type game. One player has to navigate through a maze (that represents a brain, oh how creative) while the second player steers a reticle trying to shoot the other player.

- Pit - Remake of an old Commodore VIC-20 game. One of the first games i ever played - you control a guy collecting moneybags from the right of the screen transporting them to the left. Rinse and repeat. The problem is that he must dodge falling stones while doing that. Here is a screenshot from the original game:

- Cube Demo - Realtime calculated texture on a cube. There still is an executable from the old Blitz3D implemantation here.

My final goal is to develop some little but nice demos/games/apps for the Xbox 360 but almost everything will start as a windows app first.

Well, enough for now - i am off to learn some more C#.