Bouncy Ball Public Beta 1

Bouncy Ball Beta 1 is here. See the downloads. This has the lightening fast rendering routine that Simon and myself optimized. Originally a 7 fps C routine to a 50 fps inline assembly routine. I am now running at the Coco’s stock speed of (just under) 1MHz instead of using the 2X speed up on the Coco 3. This also means Bouncy Ball should run on a Coco 2, but I have not tested it yet. The frame rate is buttery smooth but not vsync’ed yet. Some sounds have been added to the game, but in game ball bounce sound is not there yet. And best of all you can now use the keyboard to play!

 

There are a couple bugs still in the game, like a little graphic glitch, and the ball will sometimes freeze or not appear while you are playing. I still have levels to build, and need to tune the scoring. For example, I don’t think you get enough points for each tree you collect. And of course, the end of game sequence.

Levels are still pretty difficult as I am still experimenting to see how hard certain ideas are, and how they feel.

I decided to move the levels from compiled into the game, to files on disk. Unfortunately even though the resulting binary is small enough, the way CMOC organizes is code and data segments, I keep spilling into BASIC’s stack and code areas. For example:

$ parse-coco-bin /tmp/bouncy.bin 
Block at $2800 (10240) of length $3084 (12420): end at $5884
Block at $793F (31039) of length $073D ( 1853): end at $807C
BIN file length: $37D0 (14288)
Entry point    : $2800 (10240)
Content length : $37C1 (14273)
Overhead       :   0.1 %

This ends up spilling into BASIC’s stack space, and a small part of Extended BASIC itself.

The whole 6-bit DAC thing is quite a mystery to me. Back in the day (sorry John I said it), when I was toiling away in BASIC on the Coco, I only used the SOUND command. I haven’t progressed past that point yet in C. So sound is just using the stock sound function in CMOC, which is calling out to BASIC’s SOUND routine. The C function looks like this:

void sound(byte tone, byte duration)
{
    asm("PSHS", "U");  // protect U from Color Basic code
    * (byte *) 0x8C = tone;
    * (word *) 0x8D = ((word) duration) << 2;
    asm("JSR", "$A956");
    asm("PULS", "U");
}

This has the unfortunate result of halting the game while the sound plays, which makes for very jerky game play. Not what we want here.

But all is not lost! Simon has passed along some sound routines for me to play around with, and refuses to let me ship without a most excellent ball bounce sound. I’ll play around over the next little while and see what I come up with. It’s unclear to me if generating the sound is better then using a sampled sound. For a simple beep sound, generated is likely the way to go.

Level Editor

So I was sitting at work the other day, and just couldn’t force myself to look at another line of buggy, over engineered Java code. So I fired up putty and connected to a Linux box. Since I was experimenting with ncurses, I decided that a nice console based level editor would be easy to make. Over the next few hours I got it so I could drop tiles on the screen, save/load, and finally scrolling to the right for long levels.

I had previously been using a spreadsheet to create the levels, but found that a little cumbersome. The level editor makes it painless to whip something up.

CMOC
I also wanted to mention Jamie Cho has been working on optimizing CMOC and used my render sample as his test bed. By simply unrolling the loops, and removing the tile lookup (as I did in my final renderer) he was able to get about 23 fps. Further optimizations to CMOC resulted in a whopping 40 fps! Not bad for C, eh? Assembly still has the edge by a comfortable margin, but 40fps is very playable. So don’t be afraid to write your game or app in C. The time you save in development, will give you plenty of time to optimize and implement inline assembly where needed.