2600 ATARI REVISITED
Epyx asked me if I would be interested in doing some Atari 2600 work. Here we go again.
But this time I _did_ get paid. I worked on Winter/Summer/California Games for the 2600.
Wow. Now we are talking strange programming. The 2600 draws to the TV screen a line at
a time with each line taking exactly 76 cycles. If you crossed into 77 cycles the screen
would tear and stretch out past the bottom. I found out that you could use code for data.
Halfpipe took advantage of that, but its the ONLY known code that did NOT tear the screen
using 77 cycles for a frame or two. Why? No answer, it just works. I coded Halfpipe,
Speed skating, Rowing, Biathlon Shooting, Surfing, and the sound generator used for the series.
I had made my own sprite generator on the Apple-II for 2600 objects. This allowed me
to easily make animation sequences I needed for the Halfpipe and other objects. It still
amazes me how a 87 byte sound generator could have so many functions. Thanks to my
work at Passport, I was the man for the job. I did the sound effects and music for the
Epyx Game series. But, alas, Atari was already on the downhill slope and picking up
speed. I needed something new to do.
CALLING DICK TRACY
Apple-II software jobs were still hanging on by a thread when I started working for
Decision Development Corporation. They had a job to do a Dick Tracy game on the Apple-II.
When I called, they were a bit reluctant to interview me. I was a tad arrogant when I
stated, "Oh, you don't want state of the art coding, with double Hi-res screens, 3 voice
sounds with a drum track and my newest 25khz PCM sound code for human voice." After a brief
pause, they called me down to show them what I can do for them. I was hired and soon met
David Mullich at Disney. They had a video tape of the Nintendo version of the game and
a skeleton IBM version. I said its very doable on the Apple-II.
I worked for about a year on the project. I was trained by the Disney artists and I even
have a letter stating that Disney was amazed at the quality of artwork I was producing
without being a professional artist. That my style was very close to their licensing guide.
The mugshots were the hardest to do. I created my own camera capture routine and took
the photos from the movie and digitized them for use on the Apple-II. I then went beyond
the 140 horizontal pixel res and pushed it to 280 pixels and beyond. It was the only way
I could "move Flattop's nose 1/2 pixel to the right".
Now I had the original handwritten scores for Dick Tracy in hand. I quickly coded them
for my 3 voice + drum driver. Now for the opening voice, "Calling Dick Tracy". After
recording it from the source tape, I compressed it into the disk and all was pretty much
done, or was it. During this time I met several times with David and discussed how the
IBM version was doing. The Apple-II version had better sound, graphics and gameplay.
David showed them the Apple-II version and wanted the IBM programmers to duplicate it.
They couldn't, so Disney decided NOT to release the state-of-art Apple-II version without
having the IBM version to back it up. So there goes another year of my life and having
another stillborn game go unreleased.
BACK TO EDUCATION
Needless to say, I was heart broken after all that work I put into Dick Tracy, only to have
it shelved. My next project was to recreate the Plymouth Pilgrim's crossing and settlements
in the New World. I worked with a friend on this one. He was in his 60's at the time and
wondered if he could handle the programming. I would do all of the graphics and hard parts
for him and he would handle the historical part of the game. The project went very well,
and I further dove into FM synth hardware. I created the music for the game using my own
instrument tables for the Sound Blaster FM chip. I then coded the PC speaker to duplicate
the music as much as it could. I created a 3D driver for the sailing across the Atlantic
section and within the bay.
Now came the "chores" section. I made a logging game where you ride a log down the river
to the settlement to increase your "wood" supply for cooking. A fishing game for the
food and fertilizer used for growing crops. The turkey shoot was another fun game to create
for the project. If you hit the turkey with your bullet, its feathers would fly off leaving
a naked turkey covering itself. The game chats had characters with moving mouths and eyes.
Chatting with the ship's captain or a nearby indian chief allowed you to trade your goods
for other needed supplies.
This game went well and was followed by the earlier 1607 Jamestown simulation. More characters,
a walkaround map, and more things to do, just to survive to the end of the game. Brooke,
my friend also co-authored this game with me. This time we embedded video clips into the game
and now you had to manage your workers (slaves) as well as doing other timely tasks in the
game. Everyone in the game now could be seen speaking. PilgrimQuest and NobleQuest were in
the can.
CREATIVE INSIGHTS
After staying with DDC for three years, I was presented with token raise and a NEW employment
contract that I had to sign. After reading the contract, I declined. I wanted several
paragraphs changed or eliminated. They didn't. So I drove back home and saw an ad in the
paper. I thought the name looked familiar. It was an old friend from Apple days that started
his own company. I gave him a call. I was unemployed for about 15 minutes. I started the
next day. My 1st tasks there was to do more sound work for the Sega Genesis and Alien Legacy.
I used my FM instrument creator for the Genesis, and a programmer there said its the best
sounding instruments that he had heard coming from a Genesis.
DOOM was just released on the PC. They were very interested in doing a game similar to that
one. I started coding bitmap rendering routines for the IBM systems now. I had another idea.
Binary Split And Pairing - B.S.A.P. Bitmap rendering used a source-stepper and a
destination-stepper to draw the pixels to the screen. The source-stepper would have to check
for a rollover to see if it had to advance to the next source pixel. This was done on every
pixel that was to be plotted. My insight was to pre-process the source-stepper so that I knew
the source would not roll to the next pixel -or- that the source would always change on the
next pixel. Now I could draw a bitmap with approximately 95% accuracy but at nearly double
the speed. Tests showed that I could further increase the speed by having more splits.
Source steps of less than 0x8000 would require two plotted pixels before a source change.
Dividing that down, less than 0x4000 would require four plotted pixels before a source change.
This technique leveled off at around 0x2000 having eight uniquely coded subroutines that
handled the source change only when needed. The twin split had the best rendering accuracy,
but the 8 way split was alot faster. So can you really see that the bitmap is a pixel off
when a spaceship is flying across the screen at warp speeds?
Next I started experimenting with a new way to draw sprites. Since DOOM had 3D enivronments
but only 2D "enemies", I started working on a method to draw 3D sprites. I like to call it
"spoke" rendering. Each horizontal line of the bitmap would be wrapped around a "surface of
revolution". Picture a Lathe sideways. Each line wrapped around whatever width was on that
line. Rendering a pawn chess piece is a good example. Now the enemies had volume. This
technique was further expanded to allow a "surface" height for each spoke. Now you could
model a nose and deep set eyes into your object. Last variation was adding rotation to
rendering and adding live light shading to the bitmap colors. My Earth Wrap demo is a
good example of spoke rendering.
My next task was more toward the fun side of things. ScreenToyz was a desktop toy that
plugged inline into the keyboard. They had 3 characters, each with their own toy. TNT
Tad had a box of dynamite with a T-handle on top. Stitch (Frankenstein) had a electrical
knife switch and Latrina had her toilet. These were screensavers that did nasty things
to the characters and your screen. Blowing up your desktop into fragments, watching your
desktop flush itself into the center of your screen, and having the entire desktop fall like
a steel plate to the bottom of your screen. Each character had its own sound effects and
mini games that you could play on your desktop. I was proud to see my work on C|NET TV,
a program about computers and software.
JAVA AND SABGAMES
The Internet was just getting popular and Java was in its 1st release. I looked at it
for a bit and then decided that I could start my own Internet game arcade. Pachinko
came to life in about 4 hours. It was a hit. In fact, all of the games that I released
on the Internet were top rated at JARS and other Java review sites. I then proceeded to
code, A-Train - A bullet train scrolling game. StarJAM - A musical puzzle game where you
place various given blocks on a grid which change the direction of the ball. When the
grid is close to full, it sounds like "Hey Joe" with lead notes being played whenever the
ball hit a block. AirRescue - A helicopter flying game where you drop lifesaving rings
to drowning people in the water. SurfH2o - a scrolling surfing game surfing Pipeline.
SABgolf - A beautiful 18 hole course with a course Editor to make or edit the holes.
SABbowl - An in your face bowling simulator.
Alpine - A downhill skiing game with slalom flags. Many of the games carried along web
scores for comparing yourself to others on the 'net. I marketed many of the games and
continued to make custom versions of these games for clients. Webgammon - A 10 table
backgammon parlor with chat and spectator "lurking" to watch others play to learn the game.
Webgammon was the biggest Java game I coded. This was done using the CGI interface and Perl.
Webgammon supported 5 languages. English, French, Greek, Turkish/Farsi and Spanish. Many hours
were spent figuring out which CGI interface to use with Java. After many games "died" in mid-game
I had had to find out why. Simple answer, sending a packet from one computer does not
guarantee its arrival to another computer. I saw about 1 packet in about 100 being "lost"
stopping further gameplay. I decided on a simple solution. Send two packets with the same
info and let the software figure out dups. It worked like a charm and ALL games then
were completed from start to finish.
After coding all of these games and reusing all of the routines in its "bulk" form, I decided
I was going to write a interpreted language using Java as a parser. SABfx was born. Simple
plain text, no compiling, quick turnaround. I started coding games in SABfx and found out
that I could create games quicker and with a smaller footprint. GalaxyTag, Sleeper, Tracers,
and Par3 Solitaire came to life. I then added an external data file loading and parsing code
to SABfx and Slot-a-Meal was born. I had the sabgames.com domain name, but it lapsed during
my house remodel that left me offline for over a year. That is why you are on sabgames.net.
MOBILE GAMING
I was contacted by an old friend from Creative Insights for some contract work doing a
golf solitaire game (modeled after my Par3 Solitaire) deck generator. These are all
winnable decks for use on a mobile handheld phone. Players would compete for the
fastest time solving the deck. Soon thereafter I was contracted again
to do a Boulder Dash Maze generator for Atlas Mobile. This was a very large project and
they wanted to have preset "modules" that could be placed on the maze grid. I created a
full featured Maze editor with auto generating object placements. Likewise, all of the
mazes created had to be solveable with at least one path to the exit. Maze size and level
of complexity were simple keystrokes. The generator part also wrote finished mazes to a
file so that they could have 100's of mazes available for the cell phones at any time.
My next cell phone project was Water Balloon Drop for Infospace. This was my 1st exposure
to BREW and its related development programs. I had to install Visual C Net on my computer
along with the BREW ARM compiler. I had to make animation strips from the individual cels
of animation for the various game characters. Size again became job one. Dealing with the
various handset quirks, slow key response, slow blurry screens were a chore and at the same
time fun, when I found a solution to each problem.
Infospace then wanted me to do a remake of the Frogger game they had on Verizon Wireless.
The game I started with was less than 1/2 done, when compared with the original arcade game.
Most of the game elements were never coded. They also wanted to add a deluxe version of Frogger
to the existing game. I found an arcade machine emulator online and the original Frogger
arcade ROM image. I played the game back in the 80's in the arcades, so I knew what was missing.
The non-scrolling flip screen Frogger was replaced with the full vertical scrolling arcade
version. The missing enemies were added. The missing levels were added. I did stumble
across the original arcade game bug where you would die if you jumped on the right edge of a
log in the river section. The arcade game would change every 5th log into an aligator and you
would be safe on the aligator's nose IF its mouth were shut. However, if the mouth was open
as it scrolled offscreen to the right, the image was changed to a log BUT the unsafe area where
the mouth was would become unsafe even on a log. I fixed that bug. The stock version was done
and the Deluxe version with various frog powerups were now added to the game.
BREW is a good starting point for coding games for handsets. If you structure your code properly,
the conversion into J2ME becomes less of a headache. I learned my lesson from WBD and the J2ME
porting of Frogger went smoothly with only a few frame rate hiccups. Turnaround time was
around 10 seconds for BREW Frogger assembly and checkout. However, J2ME Frogger took well over
a minute to compile the same code. For game development, timing is everything and I like to work
fast.
FLASH IN THE PLAN
I am now actively searching for my next job. I am open to just about anything from device
drivers to games. I am investigating Flash and ActionScript and I am starting to
produce code. I have started reworking SurfH2o into its Flash counterpart. I was very
impressed with the graphics and views in Transworld Surfing on the PS2. I think that Flash
could do a pretty decent job replicating it. That's about it for now. -SAB
Stay tuned for further resume developments. This space is available for rent or lease. ;o)
If you have any questions, please feel free to E-mail them to me using the address
shown at the top of this page. -SAB
