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.
18 comments:
There is something strange going on with this version. Sometimes it seems to activate cheat modes such as the see-through-walls and the elevator cheat automatically. Also it seems to do silly things with the high score, maybe it doesn't load it at startup?
Hmm, maybe ANC isn't stabile after all... I haven't noticed any other oddities than weird player pulser counts in subgame, but I've used ANC in multiple places in the latest version.
When x-ray vision got activated, were the droids behind walls grey (cheat activated) or black (visibility check went bonkers)?
BTW, Happy New Year to everyone!
Saving highscore to ide64 crashes c128. I've got to test it on a c64 again, maybe it was the saving that caused the cheat bug. Apart from the pulser bug I also encountered one time a door that didn't open and a droid appearing from a dead end corridor.
For the IDE64 crash I have a simple explanation. Comment from the source: doesn't work with IDE64 because of active IRQ under its ROM. Easily fixable.
There's something fun going on with the high score tho, and that one didn't get any testing after changes... The result is that trash is written to memory before file is written, and when it's reloaded during next load it has potential of overwriting random memory as one part of save file is used as a memory pointer. No, I'm not concerned about the security vulnerability this creates ;)
If the door doesn't open try to find another way to the other side of it if possible, and check if there's droid stuck against the door. Door problems can be solved by visiting another deck, but doesn't fix the bug, of course.
Droid appearing from "nowhere" can be caused by droid teleportation which the game does if there are no free sprites when new droid should become visible. In that case the game selects random waypoint outside current view and sends droid there. The easiest deck to see this is bridge. Kill the droid coming from right, then do a mad run to the left and go back right. If droid got teleported to the rightmost waypoint you will meet it there.
Well, I played it with the ide64 killed and it looked for the high score upon startup but didn't save it after game over. This time I didn't notice other bugs, but maybe that's because there wasn't a high score on the floppy :)
Heh, did you notice that I secretly updated the archive? ;)
Game is still buggy, sometimes ship completion crashes the game. That's probably caused by too much time used inside section where interrupts are disabled. If there is an interrupt waiting when CLI is reached, interrupt will occurr immediately and my top split code doesn't like that.
Saving high score may still be buggy, I will check it again tomorrow (well, today actually). I may have to waste six bytes of memory to make it work... :)
I tested the newer version, now the score saving crashed c128d saving to 1571.
Btw, you probably say I am imagining things, but is the subgame timer running faster on c128? Right after c64 it certainly feels so. Good practice, though ;)
...and it also crashes c64+1541-II.
I also noticed when you're blasted down to 001 from a higher droid, you get the higher droid's pulsers on next transfer.
I may have used low stack memory when saving, and it seems that for some reason thew very bottom of stack gets corrupted. This usually means crash.
I noticed the pulser count bug myself, but haven't fixed it yet.
Subgame timer might run at constant 25 Hz on C128 instead of 25/33 Hz like it does on C64. This should be easily fixable (but that's what I said about the save bug too...)
New version, fixes pulser count bug and might fix high score save bug. Delete your old high score file, as it isn't compatible any more.
Another update, now subgame should last 12 seconds on every computer. As this is longer than original, I may have to give enemies one more pulser to compensate for the slower pace.
Ok, this time it saved the high score to ide64 but not to 1571. And the subgame is definitely longer, I'd say too long. The original length would be best, though it's been ages since I actually played the original :)
Unfortunately the original subgame runs at 2 or 3 display frames per update which means accurately timing it isn't that straightforward. (Update here is half of count - are you confuzed yet? ;)
I can either slow subgame down to 12 seconds, attempt 50/50 distribution between "fast" and "slow" frames for 10 seconds (quite near the original) or speed up the code to run it at constant 2 frames per update, cutting time down to 8 seconds. The last one might be too cruel, I guess that's what C128 did in the previous versions.
No wonder subgame runs so lowly, processing one half of playfield takes about one display frame. I bet that's because of cramming it into smallest possible space instead of aiming for speed.
To tell the truth, the subgame has received the least amount of TLC in the rewrite process (sound FX routine kept that place a long time, though), so the above doesn't surprise me one bit. Time to rectify that, as I spotted several places where I can make it both faster and smaller.
This might be a stupid question bud, but i have looked all over the place.
Paradroid One is all well and good but does anyone remember Paradroid 2, i could have sworn i had that for the Amiga way back when.
if you or anyone reading this can give me any information on it, it would be really helpful.
if you wanna get in touch please drop me a line at :
cwill@blackpool.ac.uk
Paradroid 90? It was available for Amiga and Atari ST.
Found your project after stumbling across the Zzap 64 development diary that Andrew Braybrook submitted while making the original - was curious since I was aware of the competition and metal editions of the game and to find that someone had decided to update the classic gem couldn't wait to try it out for myself. Alas I keep getting 404s when trying to download the redux.zip file linked from this blog :(
Hope to have a chance to savour this classic in a new form once again. Kudos Mr.Tnt.
Also in reply to Chris Willitts above: I think it might have been Paradroid 2, a PD remake of the game. I do remember playing this myself, and although not amazing did put a smile on my face back in the Amiga days. See: http://hol.abime.net/4360
Post a Comment