Have a nice summer solstice(ish)

To honor the sun I give you a new release - or two releases actually.

My plan was to build an unified version with both graphic sets held in memory all the time, but that didn't happen due lack of memory. Too bad, having different graphics on different decks would have given some more variety to the game.

I did manage to fit all necessary data into memory, but as I had to
EOR fonts together there was no way to swap between them without temporary 2 KB buffer. You really can't unpack LZ data and EOR it simultaneously, which took me way too long to realize.

While it would have been possible to do the EOR in two passes with the 1 KB buffer I do have, I didn't bother with that as I would have to drop dual graphics as soon as I need the memory back anyway.

Oh, I did fix one single pixel bug in the hires font too :)

Edit: I also added single pixel bug into Metal Edition - when you clear deck the first time, there may be extra pixel in the background star. That one is gone as soon as you move a bit vertically, so I won't do another build just to fix it.

Not quite dead yet

Here is little something for you who fear that the project is dead. Not much have changed though:

• Subgame should now take 10 seconds regardless whether you're playing on C64 or C128. That's still slightly longer than original, but way better than 12 seconds.


• Game should finally be Drean 64 compatible. I thought I put the code for this into the game 18 months ago, but apparently I didn't. Well, who's going to send me a Drean 64/128 so I can actually test it?


• Most likely there are some other changes too, it was six weeks ago when I last touched the source. The only reason I did it now was to fix the download link.

Note: if you for some reason want to archive every single release, then do yourself a favor. Don't use build number as filename part! It was never meant for that. Instead, parse it as BB-DDMMYY where BB is daily build count, DD is day of month, MM is month and YY is year. Then reorder these as YYMMDDBB and when using that as part of filename you get chronologically sorted list.

Edit: Drean compatibility is now confirmed, thanks to the_woz. Check out his blog, especially Drean-specific entries.

Have a nice winter solstice

For those too busy to read any further, click here.

Important: archive updated January 2nd, you need to delete old high score file as it's not compatible any more.

Due to some rather unfortunate events in the family I haven't had as much time for PR as I would have liked to, so there are no major changes. Minor changes include:

• fixed all but one of known bugs.
• 2500 bonus points if you clear a ship without shooting any enemy droids. Note that if you hit a single droid on ship one, you won't get bonus even if you clear ship two without any shooting as hit counter is preserved from one ship to the next (same is done with accuracy calculation).
• you can reduce enemy droid pulser count in the subgame by damaging them. This doesn't have much effect with the higher class droids, and you will have to cope with whatever energy the droid has left...
• background stars are a bit more interesting now.
• as always, it's slightly smaller and faster :)
  

As I haven't had much time to test this one, report any oddities please.

Changes which didn't make it to this version:

• subgame bonus points for 11-1 / 12-0 wins. No time to fix the bugs caused by this...
• raiders. You know, those annoying rogue droids in Paradroid'90.

Even if my time for coding has been limited, that doesn't mean that I haven't thought about the game during the slow times at work. I'm positive that the actual playing area can be enlarged by t least one character row. With C128 I think it might be possible to do two or three additional rows without the game slowing down. We'll see if I ever have time for that.

I'm sane, thank you :P

Contrary to some other claims I'm not crazy, or at least I imagine so.

That's not the only error in Paradroid talk page - so here we have (drumroll, please)

The Definite C64 Paradroid Version Guide

• Paradroid (original), 1985


• Paradroid Competition Edition, 1986
  This one is identical to the original, except that it has some vertical blank waits removed. That allows the game run faster most of the time.
  Scroll code is unchanged, whoever wrote that it was enhanced clearly hasn't disassembled all versions and done comparisons between them...


• Paradroid Metal Edition a.k.a. Heavy Metal Paradroid, 1986
  Minor changes, mostly allowing the use of multicolor chars, remaining ones save couple of cycles and/or bytes here and there.
  Uses C128 2 MHz mode in top/bottom border for higher speed.
  Fixes the decimal mode flag bug which causes weird sound fx in earlier versions.
  Some scroll text changes - this includes two bad chars which seem to be in every original ME tape!


• Paradroid Redux, 2006-
  Nanos gigantium humeris insidentes.

Tweaking

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!

Wasting time

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

MirrorSprite
 
    ldy  #0
    sty  src
    sty  .5+1
 
;   src = A<<6 | $4000
 
    sec
    ror
    ror  src
    lsr
    ror  src
    sta  src+1
 
;   ptr = X<<6 | $4000
 
    txa
    sec
    ror
    ror  .5+1
    lsr
    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
 
    inx
    dec  bytesLeft
    bne  .2
 
    txa
;   sec            ; asserted with "bcc .3"
    sbc  #6
    bpl  .1
 
    rts
 

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

Update: cycle counts were way off...

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?