Overview
This game started out as an expansion to my Retrochallenge 2011 Winter Warmup entry. I made a Turbo Pascal 7 unit to implement the undocumented 160x100 16 color graphics mode on the original CGA card -- and decided to make a game with it. Since that original demo it has grown into a full fledged game with most of the familiar "Pac-type" elements present.
Support has been added for a wide array of early PC sound cards ranging from the simple PC speaker right up through to the Adlib series of sound cards.
Keyboard Controls
ARROWS W,A,S,D 8,6,4,2 |
Player Movement * Generally you are best off pressing the movement key BEFORE you reach the turn. |
---|---|
O | Toggle Sound On/Off |
J |
Recalibrate Joystick *If enabled from command line with /joy |
ENTER RETURN |
Start Game at menu |
ESC | Exit Game to Menu Exit Program from Menu |
Command Line Options
All command line options are case insensitive
/safe | Do not reprogram CRTC on EGA/VGA. Better compatibility on oddball hardware, but has some aspect ratio issues |
---|---|
/speaker | Force PC Speaker sound |
/tandySound | Force Tandy/PCJr sound |
/adlib | Force Adlib/Sound Blaster |
/cms |
Force CMS/Game Blaster sound On CMS/Game Blaster cards you may append an address thus: |
/cms:220 |
Value in hex, valid range: 210,220,230,240,250,260 220 is the default. |
/mt32 /gm /midi |
Force Roland MT-32 MIDI Force General MIDI Force Custom MIDI MIDI device should support 24 semitone pitch bender range or allow setting via RPN Which Microsoft GS WaveTable does not support... Set value ranges as below |
/mt32:330 /gm:330 /midi:330 |
Value in hex, valid range: 220,230,240,250,300,320,330,332,334,336,340,350. 330 is the default. |
/joy |
Enable Joystick Support Joystick support can cause crashes/slowdowns/other issues with certain incompatible joystick interfaces... or if you don't have the joystick actually plugged in. |
/debug | Pauses on startup to show subsystem messages. |
/? or /help | Displays this help information |
Video Technical
The video mode this game runs in is actually a sneaky trick with text. Because of this it originally only worked on the CGA card. Basically you fill the screen with character code $DD, which has half the character filled with the foreground color and half with the background color. This nets you a 160x25 "semigraphics" mode where to set pixels you just change the foreground for even numbered pixels and background for odd numbered. To get that up to 100 vertical pixels you reprogram the CGA registers to make it think all characters are only 2px tall.
Back in the early 90's Geoffrey Silverton figured out that you could implement it on the EGA and VGA cards by adjusting their character heights in a similar fashion, though you faced the problem of every other column on the VGA being one px wider than the others, and on the EGA you ended up with a blank bar across the bottom seventh of the screen with the aspect ratio messed up since 350 does not divide evenly by 100. This 'broken' but working mode of operation can be triggered on those cards using the /safe switch.
I have expanded upon that by way of my knowledge of the EGA card. The EGA can be used with a CGA monitor, though that restricts it's highest resolution to 640x200... This means that unlike when the EGA is plugged into an EGA monitor the text mode is actual mode 3, and not the expanded 720x350 mode 3+. The VGA by way of backwards compatibility ALSO has the actual mode 3 timing information stored in it's BIOS -- so all we have to do to get the actual 160x100 mode implemented is reprogram the display timings to the actual 80x25 text mode that uses a 640x200 resolution. This appears to work on most EGA and VGA cards I have tested with the exception of some laptop LCD's. Should you have graphics corruption on the EGA or VGA you should use /safe when starting the program. In /safe the aspect ratio will be incorrect on the EGA and there may be some odd distortion on VGA cards, but the game will run in a playable fashion.
Ideally the game should give you the CGA palette where color 6 is set to brown instead of ochre, however on many EGA cards the commands to reprogram the palette appear to be broken with the bits working as RGBi instead of RGBrgb. I suspect this is a side effect of reprogramming the CRTC into the CGA 200 mode 3, though I've been unable to determine where in the CRTC data this is turned on or off (or if it even can). As such on EGA systems I have left the yellow-ochre color in place.
Sound Technical
Originally I was only going to implement support for the PC speaker and Tandy Sound -- both of which are remarkably simple to program (once you understand the PIT)... but having a soundblaster 1.0 in one of my testbed machines I decided to try and implement the original "Creative Music System" or C/MS, which is also known as a Game Blaster. (the predecessor to the Sound Blaster). All game effects are programmed to work on a three voice system, so the extra channels in the C/MS went unused.
There is no reliable way to auto-detect the presence of a C/MS card that I'm aware of (if anyone cares to correct me on that I'd love to hear it!) so to use it you must start the program from the command line with /cms.
I figured while I was adding Game Blaster support, I would also program it to work with the Adlib card so owners of later model Sound Blasters aren't left out in the cold. The Adlib FM music is actually NOT as versatile at making sound effects IMHO as while it has several hundred more programming options, the card is painfully slow to program due to the delays used in it's port handling, and that pretty much everything is based on sine-waves making it very hard to get a "strong" sound out of it. EVERYTHING from the adlib sounds muddy or metallic.
As such, to my ears at least the C/MS and Tandy remain the best choice for audio when/if they are available.
The MIDI support is limited and, well... MIDI really wasn't designed for sound effects. The best sounding is on a MT-32 which is really what I designed it for, though later General MIDI devices that support a wider pitch bender range may work in a decent fashion. A 'custom midi' setting file 'PAT_CUST.DAT' is present to allow you to set up custom tone banks. See 'custMidi.txt' for more information.
Running it under DosBox
If you want to try this game on a modern non-DOS computer your best bet will be to run it under DosBox. Much of the game's development cycle was performed using DosBox for testing so it should run flawlessly. The best settings to use for DOSBOX are:
machine=cga
core=auto
cputype=auto
cycles=auto
oplmode=cms
You should then start the program with the /cms command line option for the best sound quality. The game should run well in just about any dosbox configuration given the support for all major color video cards and adlib support.
On Windows systems I highly recommend you set output=ddraw
or even better output=direct3d
, the latter only being present on SVN builds. (last time I checked). Linux and OSX users naturally should try the various OpenGL renderers.
Game Logic
The game logic is similar in most respects to the original, though due to the 8:3 reduction in game resolution many elements had to be dropped or faked. For example the animation appeared jerky trying to make the ghosts move faster or slower than PakuPaku, so they are for the most part the same speed. In the original you could take corners faster than the ghosts by clipping the edges of each turn -- this was called "cornering" by most players. It was impractical to recreate that at such a low resolution so instead I gave the player a one pixel "boot in the patoot" at every corner to give a slight advantage.
When the ghost go into 'flee' mode when you eat one of the four super-pellets the ghosts are cut to half speed -- this proved using the 'random movement' logic to be too easy despite being remarkably close to the original game's logic. As such I have changed their flee logic to be a bit more intelligent, making you have to put a bit more effort into hunting them down.
Likewise their pursuit mode logic is a bit different -- for the most part the red ghost still tracks you directly, the magenta ghost tries to get in front of you, the cyan one's accuracy decreases the further away the red one is from you, and the brown one is still a bit... silly... but they've been tweaked with a bit of randomness to make them a hair less predictable. Likewise the movement restructions of not being able to turn upwards at the two center "T" shaped maze section while present, has a 1 in 10 chance of being ignored... just to give players a bit of a surprise every once in a while.
The level progressions follow the original game fairly closely, the entire game speeding up or slowing down depending on the level you are playing. The fastest level speed is pretty quick, even compared to the original so be ready for a bit of a challenge in that department.
Revisions
9 November 2011 Revision 1.6 ( Public ) |
|
---|---|
21 March 2011 Revision 1.5 ( public ) |
|
20 March 2011 Revision 1.5 Beta ( private ) |
Version 1.4 was a train wreck -- I was using CVS on the code tree since version 1.2, and when I built 1.4 it had code regressions across the entire beast to problems I've not seen since the 0.89 alpha... So I've scrapped that nonsense and will just go back to doing it by hand as I pretty much had to brute force recode to clean up that mess anyways. Particularly annoying was large sections of code reverting back to their 1.1 and 1.2 incarnations. Ended up like every time I'm forced into using extra 'tools' for HTML/CSS/PHP -- it's ALWAYS a broken buggy disaster; how do people even use this ****? I swear, I've not had problems that bad with code since I was forced into working with Dreamweaver, Jquery AND some rubbish CSS framework -- all three of which just result in disasters. "Programmers Tools" -- I swear the only thing about these things that can be called professional grade tools are the people promoting their use. |
5 March 2011 Revision 1.4 ( Public ) |
|
13 February 2011 Revision 1.3 ( Public ) |
|
10 February 2011 Revision 1.2 ( Public ) |
Two days after the initial 1.0 release, and I'm already up to Rev 1.2. I've upped it to that number because I've rewritten the entire sprite engine from scratch. This has increased the memory footprint of the game to a "whopping" 70k, but by allocating an extra 16k to make two back-buffers I've completely eliminated flicker on 4.77mhz machines (though true CGA cards WILL have snow, not a lot I can do about that!). The speedup and improvement to how it's drawn was so good, I removed the speed test AND the /vsync option completely! This technique should have occurred to me sooner, but I was so obsessed with not using memory. Even at 70k a machine with only 128k of RAM should be fine, even under DOS 3. |
9 February 2011 Revision 1.1 Alpha ( Private ) |
Minor improvements to the renderer |
8 February 2011 Revision 1.01 ( Public ) |
Fixed bug with level up voice sticking between levels |
4 February 2011 Revision 1.0 ( Public ) |
Initial Release |