Posts of News

6502 Game Library Update 1

2011-07-12T23:35:04.954Z

Things have been a little slow and bumpy at times, but I'm making progress with my endeavor to develop a cross platform game library for 6502 based systems.

Below are pictures of the same "game" for the C64 and the NES. Obviously, they're using different graphics. The NES version (right) is a little behind, but that's because it's a bit harder to program the NES.

However, I just made a breakthrough, which is setting up the NES to use the MMC5 mapper. It allows me to color each character graphic (8x8 pixels) with its own color, as oppose to 2x2 character blocks. It's not really a good picture to see this, as there is only one good example of such (the fourth row down). The MMC5 is a pain to program but this will allow me to match the capabilities of the C64.

Because of what I had to go through to get this monster of a configuration working on the NES, I've taken some time to research and evaluate the practicality of targeting the other 6502 systems.

I have pretty good faith that I'll be able to port the library to the Atari 400/800. I've considered the Atari 2600 in the past, but it turns out its CPU is a heavily restricted version of the 6502 which only provides 128 bytes of RAM. This would greatly hamper the quality of any game I'd make for the C64 or NES.

It was brought to my attention that the successors of the 2600 were likely more apt. It turns out the 5200 is nearly identical to the Atari 400/800; so, that's good news. However, the 5200 was not very successful. The 7800 was more successful; however, its harder varied from the last few Atari systems a good deal. My verdict is to hold off on targeting all Atari systems for now.

I plan on supporting the Apple IIe. I just ordered an old out of print book "Apple Graphics and Arcade Game Design" which should help with that endeavor. If all goes well, I should be able to have a version of my game that stutters under the processing pressure and has terrible sound--I just couldn't resist.

I have my hands full, but it should be fun.

6502 Game Library Update 2

2011-07-22T04:37:49.009Z

So, I've been wrapping my brain around the Apple II lately. The book "Apple Graphics & Arcade Game Design" has proved to be of help. I've been poking around with BASIC and the built-in assembler on the Apple IIe (via the AppleWin emulator).

It has never been so apparent to me that the Apple II was just not a gaming machine. The graphics interface is atrocious. Polling the single joystick interface is way overly complicated. The sound is likely to be as abysmal but I haven't delved into that yet (this book does not cover sound, unfortunately). These three elements; in how they were implemented on the Apple II, makes some practical sense but it's clear that gaming was an afterthought... reading the joystick is more or less a hack on an interface that is probably better suited for reading analog gauges of sorts.

My initial run at creating a proof a concept has been surprisingly successful. The game library runs minimally (without alot of features) on the Apple II, but it appears as though there is enough room to grow.

The screenshot shows a rough (and clearly inaccurate) representation of the game shown in previous posts (for the C64/NES). The mainly vertical purple line on the left is a tracer of when the "sprite" falls from the sky and lands on the ground, due to gravity. The tracers are from the graphics being drawn but not erased. There is some reasonable bad screen wrapping going on, which causes the four main horizontal sections. The arcs you see are when the "sprite" walks and jumps. All of this not coming as a surprise though, which is good!

I've applied the same pre-processed table technique I've learned from Georg Rottensteiner, in order to quickly determine the video memory addresses of each horizontal line. It wasn't a simple task--fortunately, the book by Jeffrey Stanton lays down a formula for determining line addresses as well. In the end, I've managed to create the address lookup tables in assembly (formatted for ACME) as follows:

SCREEN_LINE_OFFSET_TABLE_LO

!set y=0

!do while y < SCREEN_LINE_HEIGHT {

!set a=y/64

!set d=y-(64*a)

!set b=d/8

!set c=d-(8*b)

!byte ( HI_RES_PAGE_1 + ( 1024 * c ) +

( 128 * b ) +

( SCREEN_LINE_WIDTH * a ) )

& 0x00ff

!set y=y+1

}

SCREEN_LINE_OFFSET_TABLE_HI

!set y=0

!do while y < SCREEN_LINE_HEIGHT {

!set a=y/64

!set d=y-(64*a)

!set b=d/8

!set c=d-(8*b)

!byte ( ( HI_RES_PAGE_1 +

( 1024 * c ) +

( 128 * b ) +

( SCREEN_LINE_WIDTH * a ) )

& 0xff00 ) >> 8

!set y=y+1

}

As you can tell from the screenshot, I'm not drawing proper sprites or background graphics. Instead, I'm only drawing the bytes that are 7 pixel wide lines. I'll need to devise a system for doing both which likely will incorporate the tables listed above, require an additional table, and perhaps a block of screen character RAM. I'm going to probably apply the preshifting technique laid down by another great 6502 mind, Bill Budge, in his article "Preshift-Table Graphics on Your Apple". I'm going to have to wrap my head around that concept a couple times. The intent is clear; the solution to Woz's crazy video system is not.

Authentic 8-bit Development

2011-03-08T17:44:08.175Z

I've been taking a small break from working on a secret undisclosed 8-bit remake at the moment.

However, I want to mention and link to a fairly slow paced Commodore 64 game development tutorial by a fellow of the name Endurion, posted on the RetroRemakes website. It's all done in assembly and the author has even posted some of his own custom C64 graphics tools--good modern C64 tools can be hard to find. More importantly, a tutorial of this kind does not exist online as far as I know. Kudos to Endurion for sharing his knowledge of C64 game development.

Between posts I've been researching how to also write NES games as well. Three good sources are:

My goal is to create a game engine which will compose of two different implementations: one for C64 and one for NES. Then, provide a shell to develop games which can be assembled for both systems. In order to ensure as much compatibility as possible, alot of provisions and compromises are needed to be made, namely with the large difference between video on each system. Being both of these systems use the 6502 CPU, it's not completely inconceivable to branch out this project to also target the Atari 400/800, the Atari 2600, and the Apple II. Granted, adding compatibility for each additional system ends up limiting the games that use this engine (ie lowest number of possible sprites, colors, screen resolution, number of audio voices, etc).

Work on Wolfenstein

2010-02-16T00:23:27.169Z

I don't have time lately to work on my Castle Wolfenstein remake. However, I did manage to get some work done that I have not documented here.

I shifted my interests from poking around the DOS "castle" file towards disassembling the Commodore 64 version. I have managed to find almost all of the same "castle" data in this version's memory. It seems as though Silas Warner simply mirrored that file's contents in memory.

I will most likely resume this work, during the Summer, after I graduate. Although I felt my work on puzMule was more sacred, I will try to make this project open source as soon as possible. I'm enjoying using Google Code for my school project right now. I will be hosting it there, as well.

I turns out so far that the original Castle Wolfenstein is very simple overall. This is no where near the task of remaking MULE. The most complex thing about CW is the map generation. The SS movement is also still somewhat of a mystery so far--but I believe that to be pretty simple too.

Wolfenstein definitely had some technical achievements, like the way the castle state and its rooms and contents are saved and, of course, the digitized voice, but these are hardly obstacles or technical achievements today.

This project will not be as much of a purist attempt as my MULE remake. I will try right away to incorporate elements from both Castle Wolfenstein and Beyond Castle Wolfenstein, such as the knife, dragging of bodies, closets, chests, alarms, grenades, etc).

Castle Wolfenstein 2D

2010-01-03T17:17:11.346Z

Good old Castle Wolfenstein. I was just digging through some old classic DOS games the other day and I came upon the DOS version of this game. Although the Commodore 64 version is far superior than any of the others, including the Atari and Apple II versions, this one gives me a certain advantage.

Before I thought about remaking M.U.L.E., I wanted to work on this game first. I started working on it well before I could program without training wheels. So, the effort didn't really go too far. Although recently I vowed not to deviate and start too many projects and never complete any of them, it is obvious this project doesn't count, as it's one of my first.

Anyhow, the DOS version is fairly crappy (I can't seem to get joysticks to work, even under dosbox). However, all the files within the game are easily accessible, particular the one called "castle," which is the file that Silas Warner used for both the save game state and the level data. Naturally, I've been hex editing the crap out of this file. I'm finding some pretty good stuff.

This is good because I can't seem to run Castle Wolfenstein well on any of the Commodore emulators I have tried. I think the way that disk access is done with the game throws them for a loop. Accessing the files within Commodore "disk" files is a pain as well. The only positive side of trying to work with the C64 version is that I am fairly good with 6502 assembly, whereas I am pretty clueless with DOS 8086 assembly.

Anyhow, maybe I'll post some of the cool findings about CW eventually.

Java game engine update

2009-10-26T03:07:52.090Z

I've worked a little on my game engine this weekend. I went ahead and added some functionality that I felt was essential: graphics scaling. That includes mostly the ability to display sprites at smaller or larger dimensions. Getting that done wasn't terrible, for the most part.

However, I more importantly wanted to be able to scale the display. My work is Java applet-based; so the display doesn't dynamically change size like a windowed program would. But, I wanted this functionality to be there for later. Another benefit I get from doing so is being able to have a small area to draw on and then scale it up to something that is easily visible. This approach is more efficient than scaling up all the smaller sub-images on a large display.

Plus, this approach works great for remaking classic 8-bit games that use something like a 320 x 240 resolution. As always, go ahead and check out the progress at:

http://www.siue.edu/~adieffe/projects/TestGame/TestGame.html

Java game development progress

2009-10-16T22:45:21.832Z

Well, I've made some headway learning Java and porting my game engine to it. Currently, I'm refraining from using JOGL, a sort of OpenGL implementation. I do plan on adding that eventually. I certainly plan on using JOAL (OpenAL) as well, as Java's sound API is VERY lackluster. I'm sure it's good for a lot of things; just not what I want it to do... well. JInput will also be used for joystick support and I suppose it may be able to perform the mouse cursor locking feature that is used in many games (first-person shooters).

Anyhow, you can check out my progress here:

http://www.siue.edu/~adieffe/projects/TestGame/TestGame.html

Java puzMule, here we come!

Java for puzMULE

2009-07-08T15:52:52.815Z

I have been interested in learning Java, lately. The imminent rise of Google, Android, and the Cloud has made me reconsider something I wasn't too keen on learning say five years ago. The announcement of the Google Chrome OS reasserts my notion of playing games (and not just the small minigames we are used to) in our web-browsers.

I toyed with the OpenGL/Java based library JOGL a little. I was impressed with its performance. So, now I'm interested in porting my simple game engine into Java. Ultimately, this change would be writing puzMULE in Java as well. Perhaps then I won't have to worry about a Mac OS X port. Better yet, I don't have to worry about messing with my girlfriend's Macbook to make it.

I don't have time right now to learn Java, unfortunately. I am disappointed in my school, SIUE, for not teaching it. I think Java is pretty important now and it will probably stay that way. C/C++ is good and I'm glad I learned it, but I'm a cross platform guy. I suppose there are certain drawbacks in that category with Java, as not all devices support it, yet a C compiler exists for just about every architecture.

Maybe in the months ahead, you might see a Java based puzMULE.