Chapter 1 - June 6th, 2013

It all starts with an idea

Before we can start writing a game, we need to have an idea of what we are going to create.


I have always tried to vary the genre of the games I create, from maze games, vertical shoot-em-up, platform and 3D. One style I have yet to do is a  horizontally scrolling shoot-em-up along the likes of the arcade Scramble so I decided that this was an avenue I wish to explorer.


I decided that rather than do a conversion, I wanted it to be an original game somewhat and so having decided the genre, I then picked a game to base it on and I decided on the 1981 arcade game Scramble by Konami.





Houston. We have a problem!


But straight away I could see a problem. This game and many like it used split screen horizontal scrolling. The entire screen didn't scroll, only the actual game play area while other parts that displayed data were stationary.


The Color Computer 3 has hardware horizontal scrolling but it is for the entire screen.


Another factor I had to take into account was that these games scrolled very smoothly in one or two pixel increments. The minimum hardware horizontal scroll increment that can be done on the Color Computer 3 was four pixels or two bytes. Straight off the bat, I had two technical challenges to contend with.


I had two options...


1. Switch the scrolling to be a software based scroll and move screen data via the CPU. This method provides flexibilty on the size of the area being scrolled but would mean losing a lot of CPU cycles which would leave me with less for sound and animation. My aim was for a game frame rate of 30fps. This is the ideal rate which coincides with the monitor refresh but a software scroll would make that very difficult once all of the game elements are included.


2. Accept the limitations and scroll four pixels. This would mean the scroll would be jerky unless I scrolled fast like the  Color Computer 3 game Crystal City by Jeremy Spiller. This is not ideal since I wanted a slow scroll for this game. I would also need to redraw the data displays for each frame to prevent them from scrolling along with the game. A loss of CPU cycles again.


I wasn't happy with either option and decided that if I couldn't find another way, the game ends here.


I pondered for some time, looking at other games on other systems to understand how they tackled the problem. The techniques they employed could partially be applied to the Color Computer 3 but differences in hardware capabilities still created problems for me.


I recalled a discussion with John Kowalski way back in 2000 when he explained to me his algorithym for parallax scrolling that he had used on his unfinished game Moon Patrol. We also spoke of many techniques to create impossible effects and I began to put all the pieces together to realize a suitable routine that could accomplish many of the special effects I required while not drawing the CPU to it's knees.




Since I will be triggering my sound routine on an interrupt sourced from the horizontal video scanlines, I can keep count of these interrupts so as to alter the position of the horizontal offset in the areas of the screen I require it.


Horizontal Enable mode sets up a screen of 256 bytes (512 pixels) of which 160 bytes (320 pixels) are displayed on the monitor when using the 320x200x16 color video mode. By setting the horizontal offset, I can choose where the displayed 160 bytes will start from. This is how the hozontal hardware scroll works on the Color Computer 3.


If I wanted to prevent the top 30 lines of the displayed screen from scrolling with the rest of the screen, I need to set the offset to zero (screen to leftmost position) when the video scan begins at the top of the screen, wait for the scanline count to reach line 30 then set it back to where the offset is currently meant to be. If this is repeated for every video frame, I will have the top 30 lines of the display non-scrolling.


The next problem of the 4 pixel scrolling can be fixed using video double buffering. This is a technique where a screen is drawn in memory while another screen is being displayed at another memory location. When this screen is drawn up, the video registers are then told to display the new frame. Then we can draw the next frame on the previous frame location and shift it back when done. This has the advantage of only presenting a completed frame for display and eliminates any image tear and flickering of moving objects.


All I need to do is to take it a step further and have 2 horizontally enabled displays in memory, each 1 byte apart so that when the same display byte boundary is set, one frame will be 1 byte ahead. This effectively creates a 1 byte (2 pixel) scroll.



With the initial technical issues out of the way, the next step is to finalize the rest of the game idea. 




Copyright 2013 by Nickolas Marentes