Rainbow Snake (new game - kind of!)

Here’s the RISC OS version of my BB4W/BBCSDL game, ‘Rainbow Snake’:

http://www.proggies.uk/riscosstuff/riscos/zip/rainbowsnake_riscos.zip

The game is frame-rate independent so should run well across a wide range of RISC OS 5-based machines and screen refresh rates.

Fun, different take of snake game.

KOOL

Thanks, David. :)

I’m probably going to spend the rest of the night tidying up the source code. There’s a lot of garbage in there.

It works on the ARMX6 and the PiHard FOURtress.

A pause key would be a nice addition if possible.

It works on the ARMX6 and the PiHard FOURtress.

Thanks for checking.

A pause key would be a nice addition if possible.

Now implemented. The download has been updated.

fun and pretty. I like it!

fun and pretty. I like it!

Thanks. It’s fun to be dabbling with RISC OS again. :)

Thanks for the game , surprisingly addictive and colourful :-)

Looks like we are having a flurry of games.

fun and pretty. I like it!

I echo that.

I noticed that you crunched it using StrongBS. Was that on a 26-bit machine, or have you a reliable 32-bit version?

Out of interest, I crunched it using my Crunchie and was very pleased to see that it runs, if used with the switches -ap 1 -ma 13000 to append the ‘plum’ library. It is 19k as opposed to StrongBS 15k and the originals 33k+13k.

I was not expecting that. ;-)

Runs well on RPCEMU (RO 5.59). Good work!

@ Terry:

Thanks for the game , surprisingly addictive and colourful :-)

Looks like we are having a flurry of games.

Cheers. I’m thinking of converting some my other BB4W/BBCSDL games – a task not made easy by the fact that I’ve lost the source code for many of them. :-(

Perhaps it’s better to focus on new projects instead.

@ Steve:

I noticed that you crunched it using StrongBS. Was that on a 26-bit machine, or have you a reliable 32-bit version?

As with my recently released ‘Gorillas’ game, the conversion (and subsequent crunching) was done on RPCEmu running RISC OS 5.27, using StrongBS 3.05a. I rarely have problems with it as far as pure BASIC code is concerned (although see below), and it’s always a bit of a relief when a large-ish BASIC program is successfully crunched and runs as it should. Problems sometimes occur when there’s sections of assembler code – like, IIRC, when StrongBS mistakenly appends variables X or x to the branch instruction B, or the variables W or w to MOV. That can be annoying!

Out of interest, I crunched it using my Crunchie and was very pleased to see that it runs

I think it’s about time I acquainted myself with Crunchie, so will download it this evening. It’s always good to have another option! StrongBS seems mostly fine and capable as far as I’m concerned (notwithstanding potential ASM section woes).

Here’s a StrongBS bug which made me temporarily break out in a cold sweat a few days ago. In the Gorillas program, I had a statement something like:

which got crunched to the form

which causes an error. I tried to reproduce this bug just now, but StrongBS is now bloody behaving itself! The bug is obviously of the intermittent variety, and depends on currently unknown factors.

@ Andreas:

Runs well on RPCEMU (RO 5.59). Good work!

Thanks. I think you meant 5.29, though :)

a wide range of RISC OS 5-based machines

My Iyonix 5.28 finds an error at line 100, however double clicking the two modules and then the uncrunched !RunImage and it runs OK.

I tried to reproduce this bug just now, but StrongBS is now bloody behaving itself! The bug is obviously of the intermittent variety, and depends on currently unknown factors.

That’s why I used the word ‘reliable’. ;-)

Cruchie started as a bit of a ‘toy program’, written in BASIC, but it grew and grew. It is capable, but nowhere near as ambitious as StrongBS. It can do assembly, but is a bit cranky about what and how. There are still a few bugs (hello Msrtin), but nothing big, I think. I would be interested in your opinion.

My Iyonix 5.28 finds an error at line 100, however double clicking the two modules and then the uncrunched !RunImage and it runs OK.

Ah, intriguing. Can you tell me what the error message is?

Line 100 of crunched !RunImageX (assuming version 1.02 of the program) is to do with loading the high-score data file from the directory $.!Boot.Choices.RainbowSnake if it exists. If it can’t find the file then it assumes (perhaps stupidly) that the directory doesn’t exist either, in which case it attempts to create it (RainbowSnake) in $.!Boot.Choices. The OS doesn’t raise an error if the directory already exists. So I wonder what’s going on here (if indeed the error is anything to with the high score file or the directory it’s meant to reside in)?

Can you tell me what the error message is?

‘Not found at line 100’
But after rebooting tonight, there was no problem starting RainbowSnake even after deleting the Choices entry and rebooting, everything was solid.
Edit:
But then after running Netsurf and the error is reliably back.

That’s such a happy game! :-D And its little tongue pokes out ^ – ^

$.!Boot.Choices.RainbowSnake

Assuming the location of Choices like that is not reliable: it might not be in !Boot, and !Boot might not be in $, or the current FS/drive might not be the one with !Boot on.

A way to do this would be something like

HiScoreFile_Read$ = "Choices:RainbowSnake.HiScore"
F% = OPENIN HiScoreFile_Read$
...
HiScoreFile_Write$ = "<Choices$Write>.RainbowSnake.HiScore"
REM Ensure the directory exists
OSCLI "CDir <Choices$Write>.RainbowSnake" 
F% = OPENOUT HiScoreFile_Write$

()()()()()()()()()()()()()()()()()()()(8)<

With v1.03 there is a significant problem – it can attempt to close ALL open files, which can cause other applications to fail in unexpected ways.

In source line 850 it tries to open file “$.!Boot.Choices.RainbowSnake.HiScore”.
(Note that <Choices$Write> should be used if you are going to write the file)

If the file does not exist, F% will be zero, but it then does CLOSE#F% which will close all files.
If your case I think the CLOSE#F% and the second OPENIN can simply be removed.

CLOSE# variable should only ever be done if variable is non-zero.

You may find my small StopClose0 module useful to discover such nasty bugs – see www.avisoft.f9.co.uk – and it allows you to fail the program, ignore the CLOSE#0 and continue, or allow the CLOSE (dangerous).

It is also not a good idea to *RMKill modules that you may, or may not have loaded, if they could also be used by other applications. Certainly I use TimerMod elsewhere, and I noticed RainbowSnake had killed it. Incidentally, the latest TimerMod is v4.18 (12 Apr 2020).

The game itself looks good, after a quick play here! Well done.

the location of Choices like that is not reliable

Yes, I think when I switch some activity to RAM, that becomes the current FS, so $.!Boot will not get found.
The Boot$Dir variable would also fix this.

The Boot$Dir variable would also fix this.

Assuming that Choices hasn’t been (legitimately) moved from within !Boot.

Julie’s solution was correct: always read from Choices: and write to Choices$Write.

@ Julie
Thanks for the advice and code snippet. I’ve basically just copied & pasted it into the program :)

@ Martin
I’ve now modified the program to not *RMKill TimerMod and downloaded the latest public version (4.19) of the module. I was wondering whether to also not kill the RDSP module, but I opted to kill it because I haven’t worked out yet how to restore the sound system to its previous state (the system ‘bell’ sound gets hijacked), and simply killing the module seems to do the job. I also noticed that RDSP’s author, with his commercial game ‘Stunt Drivers’, also kills the module upon exiting back to the OS/desktop. Anyway, thanks for the helpful advice. Much appreciated.

—

Rainbow Snake v1.04:
http://www.proggies.uk/riscosstuff/riscos/zip/rainbowsnake_riscos.zip

Assuming that Choices hasn’t been legitimly moved.

Is it legal to move the settings to a local directory of an applicstion? I think that would be a big time saver and would make the the app portable to copy intact to another computer.
After decades of listening to the Choices rap and never having a case for moving it to another drive or computer, I have to wonder.
RISC OS apps mostly can be self contained, they often come with the modules they need, and I think it is handier to have settings local rather than looking in Boot.
It probably isn’t a good to have potentially crashy apps writing to Boot when it could instead be just destroying an unimportant subdirectory when it goes wrong.

I think it is handier to have settings local rather than looking in Boot.

Pros: Easier to move the application to another computer.

Cons: Upgrading the application just got harder. You can’t delete the old application and copy the new one across as that zaps your choices; likewise a “merge” approach has its problems. Something like PackMan should be able to handle the process, but People Are Impatient…

An upgrade wouldn’t have to have the settings directory so it wouldn’t over write it. They have to create one if it is not already there. I guess if you were doing a complete replacement you would drsg a copy of the settings to RAM first. This sort of thing has many easy fixes in RISC OS
If an app left a whole choices dir corrupted that would be hard.

This sort of thing has many easy fixes in RISC OS

But why are you having to come up with “fixes” for a problem of your own making?

Putting an application’s choices inside the application complicates the process of upgrading the application. The only actual benefit accruing is the ease of transferring the application (including choices) to another computer.

The other “benefit” quoted upthread isn’t all that persuasive. If you’re worried about a rogue application messing up the contents of !Boot.Choices, what’s to stop it from messing up other things as well? Can you truly trust anything on that disc after running the rogue application?

We have a long-established mechanism that most are content with.