Improved Game Engine Framework and more…

2009 March 3

Whoa, it’s been a while since I last updated!  That’s partly due to so-called Real Life eating up my time, and partly due to me spending time arranging and launching my first podcast, the Mozomedia Music Podcast.  While that has meant a drought for this blog, the good news is that I want to feature Apple II-generated original music on that podcast, and that means I’m motivated to a) make some more soundsets for Michael J Mahon’s Real Time Synthesizer b) make a ‘play the Mockingboard with your Apple II keyboard’ Applesoft program that’s hopefully superior to the pathetic ‘play with the keyboard’ program that’s included with the Mockingboard demo disk.

In Search of an Engine…

Even better news for this blog — I’ve been obsessing over, and have successfully cobbled together an Apple II game engine framework recently.  The basic idea was to have the ideal handful of speedy machine language routines handling graphics and sound that would be called when needed from an Applesoft BASIC program – the BASIC program would handle input and general game logic.  Of course, such a set-up would not work for an action game (because of Applesoft slowness) or for scrolling graphics, etc, but it could be sufficient for an adventure game, simple strategy game, or turn-based, light RPG game.

Out with the old…

I actually collected such a game framework previously, for my Scruffy and the Sword game idea — that first framework involved the combo of ProntoDOS for disk loading speed, Beagle Graphics routines for images and hi-res text, and a little assembly language program (also by the Beagle Brothers) for simple music.  Well, that will still be a great framework for that game, but I’ve become unenthused about that implementing that particular game and that previous framework has some problems.  Beagle Graphics is wonderful for making it easy to produce quickly produce nice hi-res pictures thanks to mouse control, various geometric shapes being available, etc.  But the graphics it generated, even when compressed with the nifty program Double.Scrunch, were still fairly hefty in size — I could hope to maybe get 40 or so of them on a disk that held no other files.

It would be far superior to use a program like Penguin Software’s The Graphics Magician, which records the steps used to draw a graphic instead of saving every point on the screen, which allows for amazingly compressed images files (really vector-construction instruction files) that are speedily reconstructed by TGM’s included assembly routines.  I would be able to get 200 or so such files on a single disk compared to Beagle Graphic’s 40.  Also TGM allows you to designate certain images as ‘objects’ that are to be drawn over other images at chosen x,y locations.   For example you could have a table background and one bottle image, but draw 3 copies of the bottle image on the table at different locations.

The main issue I had with The Graphics Magician was that its controls, esp. compared to Beagle Graphics, were horrible.  Using the joystick to guide the crosshair cursor was too unwieldy, even in its restricted movement ‘zoom’ mode.  Fortunately, I found on a disk image of a version of The Graphics Magician released later than the physical copy I own, and this later release has a mouse control mode. This makes all the difference in the world in terms of achieving the desired image!  Unfortunately, I don’t have a mouse for my actual Apple II’s, and this mouse mode hangs in the Virtual II emulator, but it does works perfectly in AppleWin, so I’m fine with booting into my Windows Boot Camp partition to do some Apple II image scrawling.

Memory Wrangling

The other issue with Beagle Graphics is that its machine language routines did not play nice with some sound routines I wanted to use.  I tried the sound routines one-at-a-time in conjunction with Beagle Graphics, but there was always some kind of memory conflict that clobbered the sound routine.  The only one that worked was the most basic of the ones I was contemplating.  Graphics Magician, on the other hand, offers two different versions of its main drawing routine, one that resides in high memory ( 36096 / $8D00 ), one in low (4096 / $1000).   Using the low memory version, I was able to run Joe Strout’s very versatile Sound Wizard routine with no conflicts!  (Sound Wizard’s on the 1990 disk from the Sam Stoddard Nibble program collection available here.)

I didn’t leave the Beagle Brothers completely behind, though – I still want to use ProntoDOS for its impressive boost to read/writing from disks.  Also, this time around I’m utilizing ProntoDOS’s DOS-Up program which I foolishly overlooked before.  DOS-Up moves DOS into the language card/RAM card area of memory ($D000-$FFFF),  leaving a huge extra swath of high memory (around 10k) available for use.  This solved another problem, because normally the one disadvantage of using the low-memory version of Graphics Magician’s PICDRAW is that the safe buffer for storing pictures/variables reduces from from around 12k to 3k.  However, with DOS-UP, suddenly there’s a nice wide expanse of high RAM that can be loaded with many TGM images for swift recall (instead of reading images from a disk each time they need to be displayed, it’s possible to load multiple images into memory at once at the beginning (or at various transition points) so they can be speedily summoned).

The one remaining snag was The Graphics Magician’s character generation routine, HPRINT.  The routine itself worked fine, but the process of Applesoft looping through ASCII characters in memory and plugging them into proper locations for HPRINT to work on made the printing of a single line a slowish affair, and the printing of a screen’s worth of text would be painfuly slow (unless you wanted to always have a ‘typing typewriter’ kind of effect).  So this lead me to write my first (!) assembly language program, HPRINTHOOK.  It’s very simple, but gets the job done.  From BASIC, you poke in the starting address of the ASCII text you want to read (the text has been previously BLOADED into memory), poke the text’s x and y screen locations for HPRINT, and then call HPRINTHOOK, which handles looping through the ASCII codes in memory and handing them off to HPRINT immensely faster than Applesoft does.  It also handles carriage returns (signified by a $04 byte in the string of ASCII) and returns to the Applesoft program upon hitting a $00 byte (which serves as an ‘end of message’ delimiter).

So with those programs, the framework’s memory usage is lined up like this:

  • 39936 to 48815 ($9C00 to $BEAF) — Space for Graphics Magician images, binary ASCII files loaded into memory for quick access, etc
  • 39600 ($9AB0) — HPRINTHOOK
  • 39424 ($9A00) — HPRINT PL
  • 36864 ($9000) — SOUND WIZARD
  • 16384 – 36608 ($4000 to $8F00 ) — BASIC program and variables (HIMEM is set to 36608, BASIC program start has been poked to begin at Hi-Res page 2, $4000)
  • 8192-16384 ($2000 – $4000) — Hi Res Page 1
  • 5120 – 8192 ($1400 – $2000) — free space for misc.
  • 2048 – 5120 – ($800 – $1400) — PICDRAWL

So that gives a good amount of room to play, both for the BASIC program, and for big chunks of graphics/ASCII text in high memory — and Sound Wizard is left unscathed and ready to sound-effect-ize.

Here’s a screenshot from a test of the framework running on Virtual II (apologies to Tom Wham for bastardizing one of his wonderful Awful Green Things):

Not the best that’s achievable with The Graphics Magician, but the test draws the Awful Green Thing, then draws the exclamation point as an Object Image over the Awful Green Thing, then Sound Wizard is called to play two effects to make sure it hasn’t been clobbered by any other routines, and finally HPRINTHOOK reads some ASCII bloaded into high memory and prints it out near instantly.  All of the routines are happily working together!  And the test also worked in AppleWin and on my actual Apple IIe and IIc.

Now to decide exactly what game to make with the framework (I have several ideas swirling around…)


P.S. I haven’t completely neglected my Apple II game-playing during these past months – I’ve enjoyed sporadic bouts of Bard’s Tale III on the Virtual II emulator (an emulator’s save state can come in handy) and Might and Magic II: Gates to Another World on my real IIe (very entertained by double hi-res graphics the likes of which I never witnessed on the Apple II grew up with).  I find it strangely addicting to level grind in both of them, but I am greatly wary of how vast both of the games are — the level-grinding/exploration could literally go on for hundreds of hours, so I’m not sure how long I’ll stick with them, but they’re definitely highly playable and refined dungeon/outdoor crawls of their era.  Bard’s Tale III screenshot:

5 Comments leave one →
2009 March 4

This is so cool! I’m psyched to see all of this old tech again– Dollar signs used to indicate hexadecimal (just like it says we’re supposed to do– right there in the Book of Exodus), moving the start-of-BASIC pointer (make sure that first byte is set to $00, or FPBASIC will die), ProntoDOS. Good times.

Check out Electric Duet for sound, too– that’s how I made my game music in the olden days. Two different voices/tones coming from hardware capable of only clicks. Good ol’ $C030, love that address.

I look forward to reading about your further work on this project. Sadly, I’ll have to get my retro-geeking vicariously through you. If only “real life” didn’t require so damned much of my time… *sigh*

2009 March 5

Thanks, jeff! I’ll take a look at Electric Duet. Hopefully real life won’t devour this project as well, though it could very easily happen…

2009 April 21

WHOA!!! I totally just realized I made it to your Bards Quest party! What a freaking honor, to adventure with the likes of Tom Merritt and Brian Eno! What class am I?

2009 April 23

You, my friend, are a Gnome Conjurer, and a damn fine one. I know, you might be screaming “Gnome!?” But wait, you look pretty badass in these robes as you mutter Conjury Magicks:

(However, I have left you all stranded in an early dungeon for a couple of months, though, so that is fair reason to be pissed.)

2009 July 30
Jonathan permalink

Yeah, I’ve written a few Hi-Res character generators. IMHO you might as well just redirect the character output vector and then let basic send it to the screen. Rather than messing around with POKEing which does a bunch of DEC/HEX conversion. The most CPU intensive part is, of course if you want scrolling text.

Leave A Comment

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS