I agree, I hadn't considered it when I started writing, as you'll know, it was hard enough to cram it all in, it probably took me longer than it should have but once I'd started, I had to finish.
I took a look at "Revisited the Exit" and it's brilliant. Really impressive to see how you managed to iterate on your 2022 versions and squeeze the reworked game into the PUR-120 category. That takes some serious optimization skills. Awesome work!
Viewing post in Astro-Cavern (Amstrad CPC) by VirtualJames comments
Thanks, it uses lots of abbreviated control codes in abbreviated print statements to get the job done, a nightmare to type-in if published in a magazine.
In your game, I got it down to one TEST from working out the top pixel of your alien critter. So TEST obviously uses Graphical Coordinates, the game is in MODE 0, x=10 and y=5. So I do the sums initially:-
-32+(10*32) =288
398-(5*16)=318
This gives the top-left hand corner of the next line below your Spaceship, however the point tested won't register with the Alien because it's using the next point along, so to TEST that spot simply
288+4 =292 (I'm adding 4 because it's MODE 0), so with those values in play, I can simply say:
gx=292:gy=318 - which can go after the x & y declared in line 20.
In line 40 which deal with your controls I have to now put gx=gx+32 after x=x+1 and gx=gx-32 after x=x-1, I actually changed this line from INKEY$ to INKEY(), INKEY$ unfortunately is slower than INKEY(), though in my code I'm limited to Moving my Space craft Left & Right. I have written an alternative 4 way directional movement which is used in my Finding the Exit games, Revisiting the Exit uses JOY(), which is also acceptable for this style of game. My version actually removes the FRAME.
In Line 70 where the Collision Test is carried out I've simply got p=TEST(gx,gy):IF p<>0 THEN 100 - so now if an Alien has been detected TEST picks up that and since the Scenery is a Solid Block, that's detected as well.
Here's a program I made back in 2020,:
https://www.cpc-power.com/index.php?page=detail&num=17284
Of a character moving across the screen over some scenery and how much time it takes between COPYCHR$(#0), the 2 examples using TEST - one using Formulas and other more Direct values as well as the Array. The Array comes out the fastest, though isn't practical for fast moving games like this, though as I mentioned earlier TEST can either be slower or faster than COPYCHR$(#0), depending on how it's applied, the simpler the equation works better in that case, which is how I've approached it here.
I did some small changes because the game seems to end in a very narrow cavern unable to progress into. I changed the width variable in line 60 to: w=w+(w>2 AND RND>0.8)-(w<8 AND RND>0.95) which presents some tricky cavities to negotiate, though presented some larger Scores, so I had to end up moving the High score to the Opening Page and just show the Score at the top of screen.
Anyway, there just some suggestions.
Firstly, thanks for the incredibly detailed breakdown. I really apprecaite it. That gx gy graphical coordinate trick is great! I was so focused on calculating the absolute pixel math on the fly every frame that I missed the optimisation, just pre calculate the starting pixel and increment it by 32 or 16 when moving! Eliminating those multiplication cycles to the point where you don't even need FRAME anymore is exactly the kind of magic I love about 8-bit BASIC coding.
I originally used INKEY$ just to easily catch both QWERTY and AZERTY keyboards, but you are right that INKEY() or JOY() is the proper way to shave off those cycles.
Thanks for the heads-up on the cavern width variable (w>2). I'm learning a lot here. I'm by no means the finished article. Much appreciated. I don't think I can submit an update now, with your help, fair play mentioning 1.1 only that prompted me to do a 1.0. When the competition is over I'll put a super optomised version on my account and will credit you with suggestions made.