It's a fair point well made. I've just spent a few hours removing FRAME and COPYCHR$ to make a 1.0 and 1.1 compliant version. I want to be judged on the 1.1 as it's enhanced over 1.0. I appreciate you spotting it, this is my first entry and hadn't considered the difference in ROMs, I won't make that mistake again. I've updated the instructions, put an astro.bas and astro1.bas on the disc and submitted an update. Thank you
Viewing post in Astro-Cavern (Amstrad CPC) by VirtualJames comments
Hey love this! I put myself under pressure to resolve the 1.0 requirement as you were quite right, and once I realised, I couldn't take the easy way out and say 6128 only! I'll make sure I consider ROM upgrades in future. I'd be keen to see how to get around two TEST commands, I'll email you, thank you
Yes, it's not Compulsory to write it in BASIC 1.0 and in the past entries weren't rated based on which BASIC they could or couldn't work on unless someone said "Here's my Game it's for the Amstrad CPC 464/664/6128 and Plus Range", though I don't know that for sure.
It's simply a view I hold that Games should be able to run on any machine, though Get some of those things become difficult when 10 Lines is concerned - normally it's the extra parameters in the graphical commands which leaves BASIC 1.0 behind in the amount of space saved.
Though take a look at my game "Revisiting the Exit" from the 2025 contest, it's PUR-120 though had to work hard to get it like that and it was a reworked version between "Find The Exit" from the 2022 in the PUR-80 and "Find the Exit Red" from the same year in the PUR-120.
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!
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.