Yes, this is true.
So, the timer is actually counting while the basic program is running. At least that's the only reason I can see for such a large value. So every 64 cycles of basic code should yield a different number. Maybe I just didn't get lucky with my samples. (trying that again.)
There is now a Linux port for z26.
Since I'm on Linux, Stella is basically the emulator I'm going to be running.
Nice. I'll give this a shot at some point in the near future and give my plan b paddle idea another try. I liked supercat's idea too. Splitting the read over a few frames.
The only drawback would be the loss of instant paddle movement from extreme side to side.
However, moving 16 values at a time, per frame, doubled makes 32 pixel movement possible every frame. For almost all paddle moves, this would be really a good comprimise. The only difference the player would experience, over a full on kernel paddle read, would be a latency on extreme moves that could be as high as 1/3 second. (With the paddle value doubled that is.) For my game, that would be totally workable. Going to think his idea over a bit... I'll bet it takes two bytes of storage to implement though.
Right now, I don't need paddle support for the game. I think I probably should be working on is trimming the fat in order to add the last coupla features. I've about 300 bytes left at this point and 3 variables. If I can rewrite some things to free up another byte or two, that will be enough to allow for a power up (faster bullets) and some fast moving ooze drops to avoid while battling the ooze.
Hard to decide if the features are worth more than really intense gameplay would be with the features that exist today...
Edited by potatohead, Fri Aug 5, 2005 1:55 AM.