In the old days when I first started developing (or trying to develop) games as I child the only tool I had was the BASIC programming language that came with CoCo. The ability to create sound in BASIC paused processing of everything else. This resulted in little to no time spent on developing background music or sound effects. At least that was the case for me. I generally skipped over that part. Graphics was the main thing I could develop without incurring any real penalties to the user. This process was very tedious in BASIC.
My first days of development were on the CoCo 3. It's BASIC came with extended functions for the new high resolution screens. We used to use a series of HDRAW commands as well as HSET, HPAINT, HLINE, and HPRINT to code in the "drawing" of our graphics to the screen. Then we'd use the functions HGET and HPUT to store and pull graphics from the 8k (more like 7k for the BASIC user) buffer. It often took hours to produce anything worth looking at AND in most cases there was a lot of settling or compromise as the HDRAW command has some flaws with the way it outputted to the screen. I think a good portion of that can be attributed to the fact that each byte of data on the high resolution graphics screen (we always used HSCREEN2, 320x192x16 colors) was equivalent to 2 pixels as opposed to 1. I never even knew that until I was much older. In addition, when "putting" the graphics back on the screen there was no real good transparency solution using BASIC.
Once you completed "drawing" all of your graphics to the screen and storing them in the buffer you could start the real meat and potatoes... the program. It's worth mentioning too that all of this "graphics processing" ate away at the RAM allocated to your BASIC program. So you were working against yourself from the very start. I remember it being pretty fun, but I also was 6 or so years old with no agenda whatsoever!
Programming in BASIC on the CoCo was simple. You started each line with a number and entered in some commands/ functions that were pretty straight forward and easy to memorize. PRINT, for example. The name of the command pretty much hinted to you its function in one word. The CoCo's programming editor was terrible by today's standards, but for the time it was alright. The only thing I had to compare to at the time was the IBM PC Jr.'s BASIC that I played with at school. It used the exact same keys for editing.
To edit you had to type EDIT insert line number here and press enter. You could hit the right and left arrow keys to move the cursor left and right over the characters. You could also use the search function "S" to "find" a certain character. A number preceding the S would "jump" to the Xth occurrence of said character. For example 3-S-C would find the 3rd instance of C and jump there. Then you hit the C key to change the character. There were a few other editing functions, but you get the general idea of how bad it was!
As I got older I developed my own tools for developing games or used other resources that were already created for me. I was tired of the somewhat hokey results I got from hours of HDRAW's and made a very primitive sprite editor. The program opened up with a large grid that's size was predetermined. Next to that was a display of the actual image. A palette was displayed somewhere and so on. You used the arrow keys to move the cursor around in the grid and pressed SPACE or ENTER to set the current color on the grid and in the actual image. This enabled you to be much more precise by setting pixels instead of using the HDRAW function. This eventually evolved into a GUI type sprite editor that I still use to get ideas out, but I have even started leaving that one in the dust. Here's an example of the standing frame of the new Downland 2 dude drawn using the latest evolution of my CoCo 3 sprite editor.
There is definitely a downside to this and that is that the VCC emulator is very lenient when it comes to things working. Often times something will work on the emulator that won't work on the real hardware. This is mainly due to issues with the interrupt timer and that within the emulator ALL memory address are read/ write enabled. That is NOT the case on the real hardware. Repair of those issues are currently in process. If you're going to be a serious developer for the CoCo 3 and use some advanced assembly techniques I strongly suggest you also have a real machine for testing. Your programs will blow things up if not!
I have not spent much time using a debugger. Because of the way you can instantly compile and check most of the bugs are worked out as we go, but that has not always been the case. We had an issue during "Timberman" where on MAME and real hardware a random gray pixel would show up on the title screen. It was in different places on the screen depending on which system you ran it on. VCC never showed, "the gray glitch of 2017." My friend Simon ran the game through the MAME debugger and found that in some of my code for compiling the title sprite there was a stray instruction writing gray pixels to a screen memory address. The game was nearly finished and rewriting the title compiling code would throw some things off. So we made a patch at the beginning of the program to correct the problem. Even though I don't have much experience with a debugger myself I strongly recommend a good debugger for solving problems like this and others.
I mentioned in the paragraph above, "...code for compiling the title sprite..." Sprite compiling is key for a fast CoCo game. Sprites are basically the graphic that depicts a character or object on the game screen. There are generally 2 types of sprites. Hardware and software. When it comes to the CoCo hardware sprites do not exist, so software is your only option. There are generally 2 ways (that I know) for storing and rendering sprites on the CoCo. You can either use a buffer that you copy from OR you can compile your sprites. Compiling is simply a set of instructions to "draw" the sprite directly to the screen.
I compile my sprites as it is the fastest method, but it takes more memory for storage. I do it manually. It's slow and it's tedious, but the compiler programs I've used (although very well written and DO produce great compiled sprites!) do not produce the optimized solution without editing. I found I was editing them a lot anyway so it seemed easier to just continue manually. To do so I use a combination of GIMP, Excel and Notepad. As stated above I use GIMP to create all of my graphics. I will then take that into an Excel grid as a hexadecimal "map" of values that make up the graphics. X's equal a nybble that needs to be masked with the background. I'll then go line by line writing a series of assembly instructions to compile that graphic. There are other methods I'm sure, but this is what I do.
As I touched on previously, compiled sprites take a lot of memory. In order to "pack" all of these graphics and sounds into a single loading .BIN file you have to use a compressor. Again, Simon, introduced me to one known as Dzip. You can take any type of file and compress it. There is even decompression code written for 6809 assembly. It's simple. Compress the file using Dzip in the DOS command prompt. Include it in you program assembly file and decompress as needed into RAM. TO DO- Add link to Dzip download.
I won't talk much about HOW to produce sound on the CoCo or even how to use an Audio editing program here. To make a good game on the CoCo you should use some background music and some sound effects. One or the other is fine too! In order to do so I recommend Audacity for editing and converting digital samples for sound effects. It is free and does everything you need it to.
For creating background music we recommend OpenMT. It's also free. Essentially it is a sequencer that can output an audio map that you can throw right into your assembly program. Insert sound engine and BOOM! you have background music.
The next tool is a work in process for me. A tile editor. All those cool tiles you made in GIMP should have a map for rendering sitting somewhere in your assembly program. For my tile editor I intend to create a PC based program. Basically you can select 1 of any of the tiles and place it on the grid. The program will then store it's tile ID in a tile map. This will be outputted to a file that is compatible with the assembler. More on this as I get it created.
Most of you probably already knew that you needed a set of tools to develop video games, but perhaps you didn't know what they were. There are more than what I've mentioned here, but for retro gaming these will get you to the finish line
Don't use a butter-knife to turn in that screw. Hell, don't even use that old fashioned screw driver. Get a 18v cordless drill and let IT do the work for you... unless of course the job doesn't call for it. Knowing when and how to use each tool is just as essential as having the tool in your toolbox. My example above with sprite compilers is a perfect example. There are plenty of good ones available, but for my games needs I find it best to compile by hand. In some cases too the buffering method was just fine and saved me a ton of work. You will learn and adapt as you go, but this should provide a nice base to start with. Thanks for reading. There is a summarized list of tools below.
Graphics editor- Use for generating/ editing and exporting all graphics. We recommend GIMP.
Text editor- Use for writing and editing code. Notepad is perfect for this.
6809 Assembler- Use to compile assembly code into binary program. LW Asm works wonderfully!
Debugger- Use to analyze code and find out why things are messed up! I hear MAME's is great.
Sprite compiler- Use one of these to make compiling your beautiful graphics master pieces in to fast drawing sprites. Additionally editing will likely still be required. Count your cycles and see!
Spreadsheet- Use to manually create a map of the hexadecimal values of graphic images. This is used to compile manually. Excel or Open Office are great examples.
Audio Editor- Use to record, edit and export audio for sound effects. Audacity is awesome and it's free!
Compressor- Use to compress code. Examples are graphics and audio. Must have a decompessor that is compatible with 6809 assembly code. We recommend Dzip.
Audio Sequencer-Use for creating and exporting code for background music. OpenMT is a fine option.
Tile editor- Use to visually layout tiles to create a level. Then this will be converted to data that can be interpretted by the assembler. WIP on this one for us! We challenge you to create your own!
Good old fashioned Color Computer-because they're sweet! Oh... you'll need one for testing too!
