Monday, September 24, 2007


Too little time for anything major (yet!) but scoring and subgame have seen some little changes.

  • Bonus score if you do well in subgame. 20% bonus for each remaining pulser if you win 11-1, 40% if you win 12-0

  • 2000 point bonus if you're wimp and use only transfer to overtake the ship. Not enough to compensate for score lost by not shooting droids, as I don't want to encourage that kind of cowardism ;)

  • Shoot droids to pieces before transferring to them - their pulser count reduces by one for every 16 points of damage. Don't forget that you have to cope with whatever energy they have left, though!

In addition to adding small things I've also discarded some ideas

  • Grenades/mines. What to do when droid explodes a mine but there are no free sprites?

  • Two player mode through link cable. That cuts down sprites available for enemy droids and fire, lowering the difficulty considerably. With fever sprites it's also harder to hide the fact that the game teleports droids away if it runs out sprites.

I have doubts about transport pads as well. These would transfer player within a deck, but that would require resetting droid positions to avoid several visibility problems. And that would mean teleporting all droids, meaning you could face the same robot you were running away just a second or two ago half a deck away. You may say that there isn't much realism in the game, but that makes it even more important to preserve what's left of it!

Wednesday, September 5, 2007

Wasting time

How can one waste gazillions of cycles to mirror one sprite? Quite easily, just forget speed and concentrate on compact code.

ldy #0
sty src
sty .5+1
; src = A<<6 | $4000
ror src
ror src
sta src+1
; ptr = X<<6 | $4000
ror .5+1
ror .5+1
sta .5+2
; get sprite multicolor flag
ldy #$3F
lda (src),y
sta tmp2 ; b7=1 if multicolor
lda #60
.1 tax ; x=60,61,62, 57,58,59, ... 3,4,5, 0,1,2
lda #3
sta bytesLeft
.2 dey ; y=62,61,60, 59,58,57, ... 5,4,3, 2,1,0
lda (src),y
sta tmp1
lda #$01
.3 lsr tmp1 ; 5
bit tmp2 ; 8
bpl .4 ;10 hires, 8 loops 1 bit each
php ;13 else multicolor, 4 loops 2 bits each
lsr tmp1 ;18
rol ;20
plp ;24
.4 rol ;26
bcc .3 ;29 8*16=128 / 4*29=116
.5 sta $8000,x ; 63*128=8064
dec bytesLeft
bne .2
; sec ; asserted with "bcc .3"
sbc #6
bpl .1

Hey, I just realized I can make it at least one byte sorter! ;)

Update: cycle counts were way off...

Tuesday, September 4, 2007

Byte Liberation Front

I keep surprising myself with all the memory I can squeeze out when I start trying. When reordering the multicolor charset from the Metal Edition Paradroid I finally took a good peek at the alpha charset. Eliminating duplicate chars and blanks freed another 31*8 bytes and couple more in graphics font. There are several 8-byte data areas I can scatter anywhere in the memory, but to keep it neater I should do some rearranging. Finding the correct data block in binary file whenever I want to change something doesn't sound fun to me.

In case you're wondering about those five blank chars below "8" - "c" and why they aren't used... Chars $28-$2c (top halves of those 1*2 characters) are at offset $0140 and need 40 bytes. (Not so) interestingly that's the same offset and size as 10th character line on screen, which is the first line used for the deck display. To change all sprite pointers and displayed charset with single $d018 write I simply switch from blank screen + blank font to actual game screen and graphics at the correct line. However, VIC-II has already read the character pointers at that time (from blank screen) which means that I have to copy the top line from game screen into the blank screen. That in turn makes chars $28-$2c visible if used because the blank screen is actually the first half of the blank font... So, those chars are unusable as graphic data both in alpha font and in in-game graphics font. That however doesn't mean that they can't be used for anything else ;)

From graphics to sound effects... I found out that I can move the main SFX table partially into the RAM under I/O at a cost of ten cycles every time an effect is started. This filled up the hard-to-use $D000 RAM completely, and freed 160+ bytes elsewhere.

Back to graphics with something which is only an idea so far. Compressing droid parts separately would gain ~600 bytes, but I can do even better. If sprites are decompressed into one continuous block, I can use the previous sprite data as codebook which would give better compression at no extra cost. Extra time used for decompression isn't anything to worry about, no one has complained about the sprite mirroring delay yet and that one takes about 15,000 cycles per sprite, 60,000 cycles in total - even if mirrored sprites aren't used at all!

All these summed up give me more than one kilobyte to play with - but what should I fill it with?