Chapter 13- April 27, 2014
It's been a long time between blogs with several factors delaying my return to CoCo programming such as Christmas/New Year, home and work commitments, the arrival of my Altera DE1 FPGA board and getting sidetracked into the Amiga world for awhile.
The motivation to complete such a project in todays environment poses a challenge for many retro/home brew game developers. It's not as it was in the 80's when you knew that a well done game stood a chance of finding a market. Nowadays, the motivation to spend days, weeks, months developing a game of commercial quality needs to be driven by one's own desire to accept the challenge for their own passion and amusement. If he's lucky, he'll get some glowing reviews from other enthusiasts and if he's really lucky, may even sell enough copies via the net to at least buy himself a few free meals!
Don't give up your day job!
This of course varies dependant on the systems one is developing for. Some people have had good success selling their homebrew games on systems such as the Commodore 64 and Atari's but the CoCo doesn't have as large a user base as these systems. Even then, the income nowadays is not enough to earn a living off.
You won't be driving around the city in a bright red Ferrari off the earnings of any CoCo programming achievements!
So, how does one stay motivated?
With Popstar Pilot, my motivation from the outset was the technical challenge of achieving a hardware split screen with one byte scroll. The simulated dual playfield effect of the title page was also fun but after achieving these two goals, my motivation to complete the remainder of the game seemed like... unpaid work.
I wanted to do this game but the challenge was gone and I knew the only way to resume was to find a new challenge.
Several days of brainstorming and I'd come up with a solution! A few new ideas and a new focus to improve the graphics of the game further with a few more technical whizz-bangs into the design.
I'd achieved a motivational change!
During my distraction into the world of Amigas, I began looking at the various side scroller and platform games available. This gave me several new ideas of what to implement in my game. I liked the use of the Amiga's "copper" processor and how it created a gradient of color in the background of many games and the general look of these games were quite professional and artistic.
The following text is taken from an Amiga Wiki describing the Amiga's copper...
The name is short for "co-processor". The copper is a programmable "finite state machine" that executes a programmed instruction stream, synchronized with the video hardware.
When it is turned on, the copper has three states; either reading an instruction, executing it, or waiting for a specific video beam position. The copper runs a program called the copper list in parallel with the main CPU. The copper runs in sync with the video beam, and it can be used to perform various operations which require video synchronization. Most commonly it is used to control video output, but it can write to most of the chipset registers and thus can be used to initiate blits, set audio registers, or interrupt the CPU.
The copper is often used to change colour registers mid-frame, creating the "raster bars" effect seen commonly in Amiga games. The copper can go further than this and change the background color often enough to make a blocky graphics display without using any bitmap graphics at all.
I wondered if I could incorporate some of these features of the copper into my game? The CoCo doesn't posess such hardware and any background gradient color changes would have to be handled by the 6809 and its use of interrupts. Since my interrupt driven code manages the dual channel sound and hardware split screen scrolling based on timings derived from the horizontal sync, I thought I could also incorporate this background gradient effect without too much effort and extra overhead.
I got cracking and soon I had a background gradient filling the scrolling region of the screen. This was achieved by changing the background color (Color 0) at fixed intervals down the screen. The first problem was the lack of enough colors to create a smooth and subtle gradient. The CoCo uses 2 bits for each of the red, green and blue colors in RGB mode (64 total colors) whereas the Amiga (pre AGA) has 4 bits per red, green and blue (4096 colors).
So the next challenge was to add more colors!
For this, I utilized two sets of palette colors for the gradient and flashed each in alternate video frames thereby mixing the colors onscreen. This expanded my colorset beyond 64 colors and in particular, gave me more of the low intensity colors which is what I wanted. I didn't want this gradient background to dominate the screen and take away the contrast from the foreground graphics (scrolling terrain and sprites) so the gradient had to be dim enough not be overbearing but still be visible. The dim colors also supresses much of the flicker inherant when flashing between the two colorsets.
Eventually I came up with a mix I was happy with and my plan is to maybe have at least two other combinations to provide variation as the game progresses.
Unfortunately, while this works beautifully on a real CoCo, it doesn't seems to work with the VCC emulator properly (I haven't tried MESS) so I've had to manually edit the screenshot below to a close approximation of what the real screen looks like. The real thing looks better than this mockup.
Imagine this with the terrain scrolling and the gradient background moving up and down.
As an added feature, this gradient background can be scrolled up and down effortlessly and I plan to incorporate this as a sort of parallax effect as your player's plane character moves up and down the screen. The background will also move up and down albeit at a slower scale to simulate distance. This vertical movement of the background happens while the foreground terrain scrolls super smoothly from right to left.
The big bonus to all this is that very few additional cpu cycles have been used in the implementation.
While I was at it, I also decided to do a design change of the data displays at the top of the screen (SCORE, FUEL & LIVES).Summary
In summary, my main interrupt routine manages several technical eye-candy functions....
Can I squeeze in anything more? Stay tuned for the next installment!
Copyright 2013 by Nickolas Marentes