Hedge1970 wrote: ↑Tue Mar 26, 2019 8:43 am
Hehe the irony is not lost on me, editing a game built in a zx spectrum so it works on a zx spectrum emulator
Well, it’s not so much the fault of an emulator as one of the quirks of the Spectrum itself. Some emulators have an option of enabling or disabling the pre–Issue 3 Spectrum keyboard behavior; others don’t. In this instance, the game was (presumably) developed on a later 48K Speccy, which returns a different value of Bit 6 upon reading from port 254. As is, the game wouldn’t work on real Issue 1 and Issue 2 Spectrums either.
There were a bunch of commercial games that suffered from the same problem, so in that respect the game is as genuine as they come.
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Can't you just put something in the code to, e.g. do an IN on the title screen when no keys are pressed, then put that in a variable and then do something like key = var - IN xxxxx to work out the key being pressed? That way you don't lose the ability to move diagonally, as you do with INKEY$.
I think the use of keys B/N for left/right so they're in separate IN commands is clever, though you don't need to detect both of those pressed at once so O/P with the same IN isn't too hard.
It's a good game and very fast and responsive for BASIC. I did think about the suggestion of a penalty for missing a drop, but losing time is probably all the penalty you need. I do think the time limit is a bit tight though, especially as the third screen gets very crowded. You may have got too good at your own game while working on it!
