posted Sep 28, 2012, 8:19 AM by Andrew Dieffenbach
I haven't done much to the game engine lately, but I made some developments that I did not report here. More recently, I've created a Google Code project featuring the WIP (also listed in my Projects page). Like my other game engines, I've dubbed it puzL, or more appropriately:
puzl6502
See the following images to see the progress, so far...
Commodore 64: The Commodore 64 portion is about the same as last time I showed it off. Nothing to say.
Nintendo Entertainment System (NES): I've yet to implement a meta-sprite system for the NES portion, but this screenshot better presents a working MMC5 implementation (notice the 8x8 colored character graphics).
I finally purchased a PowerPak and I applied the awesome mappers written by user loopy, I got my NES version running perfectly on a real NES! Maybe I'll upload proof with a picture, at one point. I learned that using the outside columns on a tube television is a bad idea, as the physical beveled picture frame covers it up.
Apple II: I certainly haven't set up a bitmap sprite yet, still using these lines as placeholders. As you see, there is a vertical column of these lines that begin at the top very compressed and close and then start to distance from each other. The demo I am using, the little person (seen in the C64 version) starts in the middle of the screen and falls due to a very Megaman-like gravity. Since the Apple II had no sprite blitting hardware, the current state of "sprites" or these lines is that, during animation, the previously drawn line is not erased or undrawn (via XOR / XDraw).
Different from the last image are the character graphics. In Hi-Res mode (where I'll be able to have sprite like entities), there is no equivalent of background character graphics, like with a C64 or NES; so, the text you see was drawn as bitmaps. Notice that the characters are closer together than with the C64 and NES versions, this is because a byte of graphical bitmap data on the Apple II in Hi-Res mode represents 7 pixels--that's 8 bits per 7 pixels. Not to get too technical, the reason why one of the bits of a byte does not affect the output of an additional pixel has to do with Steve Wozniak's implementation to get cheap programmable colors out of the Apple II. It's kind of a headache to deal with, but apparently, it can be done.
But the introduction of bitmap character graphics will eventually lead to bitmap sprites. My Apple work so far as been largely attributed to the arcade game development book I mentioned previously and also the tools and example code from Vince Weaver. I only just recently started studying the Prince of Persia code that Jordan Mechner recently released. From what I can tell, it's going to help a lot with the graphics. It's going to be really helpful for sound / music, as the book I mentioned does not cover sound, for some reason (probably because it is almost non-existent on an Apple II).
|
posted Sep 13, 2012, 1:49 PM by Andrew Dieffenbach
[
updated Sep 13, 2012, 2:05 PM
]
I've finally gotten around to fixing up and sharing my 128 KB C64 cartridge circuit design with the Commodore world. I've posted an image of the schematic and a brief explanation (probably more brief than it should be) in my Projects section.
Here is video of the design in action! 128 KB C64 Cartridge Circuit Design |
posted Jul 21, 2011, 9:37 PM by Andrew Dieffenbach
[
updated Jul 21, 2011, 10:20 PM
]
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. |
posted Jul 12, 2011, 4:35 PM by Andrew Dieffenbach
[
updated Sep 13, 2012, 2:15 PM
]
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.
Small update: I figure I'd link to some videos of the engine in action:
Commodore 64 platformer work 1Commodore 64 platformer work 2
|
posted Mar 8, 2011, 9:44 AM by Andrew Dieffenbach
[
updated Mar 8, 2011, 10:27 AM
]
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). |
posted Feb 15, 2010, 4:23 PM by Andrew Dieffenbach
[
updated Feb 15, 2010, 4:50 PM
]
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). |
posted Jan 3, 2010, 9:17 AM by Andrew Dieffenbach
[
updated Jan 3, 2010, 9:32 AM
]
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.
|
posted Oct 25, 2009, 8:07 PM by Andrew Dieffenbach
[
updated Oct 25, 2009, 8:21 PM
]
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 |
posted Oct 16, 2009, 3:45 PM by Andrew Dieffenbach
[
updated Oct 16, 2009, 3:51 PM
]
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! |
posted Jul 8, 2009, 8:52 AM by Andrew Dieffenbach
[
updated Jul 8, 2009, 9:21 AM
]
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.
|
|
