Chapter 8 - September 3rd, 2013

The Dylan Effect

In 1964, Bob Dylan sang his song The Times They Are A-Changin' which became one of his most famous tracks. He wrote the song as a deliberate attempt to create an anthem of change for the moment.

Change happens all the time, we almost expect it to happen. Often we have change for change sake, we tire of the old and simply want a change. But mostly, change can lead to an improvement in something, in this case, my game.

The artistic part of me has been eyeing the fade-to-black transition that I am using when switching from the title screen to the game screen. This is to be a common effect used throughout the game to signal a change of scene. The more I've looked at it, the less impressed I was with it. The problem stems from the Color Computer 3's limited luminance levels, only four. This makes the fade to black effect too jarring if done slowly or sudden if done fast. To get a smoother fade would require more luminance levels.

I began experimenting and found that a fade to white looked better than a fade to black. Still too short but better. I then thought of taking this resultant white screen back down to the levels required by the next screen.

The end result is that the first screen is faded up to full white then the second screen is brought in by fading each color back down to the required level. This code was more complex than a fade to black or white but I managed to create a subroutine that ended up being shorter and more efficient than my previous. I then set about rewriting the fade-to- white routine using a similar algorithym. I may even look later on at combining the two routines into one. 

I'm happy with the end result and have locked this down as the final transition effect to be used throughout the game. A mockup of my results is shown above right.

Game on!

Now to get back on track and start getting the first pieces of code that actually deal with the gameplay. The first thing to do is setup variables and parameters and draw up the actual game screen.

After my transition effect from the title page, I drew up the various display areas such as Score, Hi-Score, Level Progress Bar, Fuel Bar, Lives and Bombs displays.

I have already allocated the MMU blocks 14-15 as the title storage area (the PopStar Pilot graphic) and MMU blocks 16-17 as the remaining graphics storage area. 

On the right you can see a screenshot of my graphics editor screen Brilliance running on the Amiga and the graphics I have created so far. At the very top is my font. When using graphics mode, we have to provide our own fonts for the displaying of text. The font I like to use for these 80's style arcade games is a font very similar to that used in the arcade machines of that era. It has thick lines which are very easy to read. Only uppercase A-Z and the numbers 0-9 are needed for this game.

Below the fonts, I have chosen to store the entire level progress bar. This saves a lot of code to recreate this bar seeing I had space to store it. If I'm running low later down the track, I will go back to redrawing it with code.

The fuel bar is simpler and I drew that in code using the base graphic elements stored immediately to the right of the level progress bar.

Finally to the right of that is a heart and a bomb graphic which comprises the lives and bomb displays respectively.

Putting this all together,  the image below right shows the game screen setup. Immediately to the right of the Score and Hi-Score labels at the top of the screen will be the numerical readouts for both. The Fuel Bar will later show a blue expanding or contracting color within and I'm thinking of giving the bombs in the bomb display area a small twinkling fuse flame just as a novel effect.

What you can't see in this image is that the blank area in between is actually horizontal scrolling while the top and bottom remain stationary. You can't see it because there is nothing there to see. It is merely scrolling black. Currently it is utilizing the standard 2 byte (4 pixel) hardware scroll. For testing, I usually just throw a few lit pixels into this area and watch it scroll to the left of the screen. It dissappears off the left and after awhile loops around and re-appears on the right to repeat the cycle. Currently it's very smooth but too fast being a 2 byte (4 pixel) scroll.



Points to note

In closing this chapter, I would like to highlight the fact that changing ideas in an effort to improve something created earlier is the norm. There is always something that can be done better. It's a matter of weighing up the benefits with the amount of time and effort required to achieve it and whether in the end it is really worth it. My fade-to-white routine was an artistic improvement while the rewriting and optimisation of the initial fade code itself was a technical improvement.

May I also point out that the code doesn't need to be completely optimized. There is no need to rewrite code until the absolute minimum number of CPU cycles is used if that part of the code does not require it or already achieves the desired execution speed. I usually prefer to prioritize the optimizations in areas where it is crucial.

Using the graphics editor allowed me to experiment with color choices and to position items on the screen until I found the desired look, both from an artistic side and a programming side. This experimenting took longer than the actual coding but is very important to nail the design and avoid many code rewrites later.

Coming up next is the modification to switch to a double buffering scroll routine to create the 1 byte (2 pixel) hardware scrolling.



Copyright 2013 by Nickolas Marentes