Gorillas (new game)

Well, not really new, but here’s the RISC OS version of an old-ish (2012) game of mine with one or two enhancements. It’s taken 4 or 5 days to convert the original BB4W version, due in large part to BASIC V not supporting structures. :’-(

https://tinyurl.com/y7hjpfpc

Minimum system requirements: Raspberry Pi 2 (or something at least as fast in terms of CPU and RAM speed – the RPi 1/Zero is too slow). Will run under RPCEmu but needs a fast host machine. The game runs in a 800×600, 16M-colour screen mode.

Have fun, and do watch out for those exploding bananas.

Hi David

I get screen mode not available at line 40 on my Titanium

I tried the uncrunched and get screen mode not available at line 270

I copied the following DEFPROC from my lastest version !Stargate game and got it to work.

DEFFNAllocateAndChangeMode(W%,H%,colour$)

DEFAllocateScreenMemory(M%,W%,H%)

And added

200 bitsPP%=FNAllocateAndChangeMode(800,600,“16M”)

Looks like we are both having fun with Modes :-)

It a very good game nice graphics :-)

Terry wrote: “I get screen mode not available at line 40 on my Titanium”

Thanks, Terry. I’m a bit surprised about that error message because I thought (obviously wrongly!) that the way I set up a screen mode was fairly standard and ‘safe’:

ScrW% = 800
ScrH% = 600
DIM Mode% 23
Mode%!0 = 1
Mode%!4 = ScrW%
Mode%!8 = ScrH%
Mode%!12 = 5
Mode%!16 = -1
Mode%!20 = -1
SYS “OS_ScreenMode”, 0, Mode%

The Titanium definitely has enough RAM, but for some reason it’s choking on that mode setup attempt. Can anyone say why that is?

Anyway, thanks for the feedback and I’m glad you got it up and running.

May I ask what frame rate you got on the Titanium? Does it match the screen’s refresh rate?

Cheers.

I got 60 Fps works fine as far as I can tell.

I used the OS commands to read in a few modes and filled in the mode block to match see below:-

DIM Mode% 39

Mode%!0  = 1
Mode%!4  = ScrW%
Mode%!8  = ScrH%
IF colour$="256":Mode%!12 = 3:bpp%=8   :REM (3)2x2x2=8
IF colour$="16M":Mode%!12 = 5:bpp%=32  :REM (5)2x2x2x2x2=32
Mode%!16 = -1
Mode%!20 = 3
IF colour$="256":Mode%!24 = &FF:REM -1 for 16M &FF(255)
IF colour$="16M":Mode%!24 = -1
Mode%!28 = 0
IF colour$="256":Mode%!32 = &80:REM &FF 16384 for 16M  (&80)255
IF colour$="16M":Mode%!32 = 16384
Mode%!36 = -1

Hi

I just changed the mode block in gorillas to:-

DIM Mode% 40
Mode%!0  = 1
Mode%!4  = ScrW%
Mode%!8  = ScrH%
Mode%!12 = 5
Mode%!16 = -1
Mode%!20 = 3
Mode%!24 = -1
Mode%!28 = 0
Mode%!32 = 16384
Mode%!36 = -1
SYS "OS_ScreenMode", 0, Mode% : OFF

It now works OK on the Titanium

Thanks again. I think it’s time to reacquaint myself with the relevant sections of the PRMs. :-)

“I just changed the mode block in gorillas to:-”

“It now works OK on the Titanium”

But unfortunately not my Raspberry Pi 4 running RISC OS 5.28. I have no idea why. Perhaps the RPi 4’s CONFIG.TXT and/or CMDLINE.TXT boot files need tweaking.

Works on the Raspberry Pi models 2B and 3B, and under RPCEmu.

So, I need to find a way of a setting up a 800×600 16M screen mode which keeps all the RPi models and the Titanium happy.

Using the uncrunched Gorillas BASIC I found this MODE string was required to get 800×600 on a Titanium :-

MODE  "X800 Y600 C16M LTRGB F60"

The “missing” bit in the original mode block is the TRGB setting which is described here.

This mode block works here :-

DIM Mode% 31
Mode%!0  = 1
Mode%!4  = ScrW%
Mode%!8  = ScrH%
Mode%!12 = 5
Mode%!16 = 60
Mode%!20 = 0
Mode%!24 = 1 << 14
Mode%!28 =-1
SYS "OS_ScreenMode", 0, Mode% : OFF

Note that 1 << 14 = 16384

The downside is that this is only for platforms with this colour format.

Reading the block first might help, I have not tried it.

HTH.

Use the X form of the SWI and try to set the normal TBGR format. If that fails, then simply set the TRGB flag and call the SWI again. That’s what I did for Virus.

It’s a shame there’s no easy way to specify “I want a screen mode of X x Y and since I’m using OS routines I don’t care what order the colours are in”.

This is getting crazy :-)

If I run !Virus on the Titanium is fails because it cannot get the 800×600 mode it needs.?

I think it was jeffery lee who posted the code below, this calls Service_EnumerateScreenModes
via OS_ScreenMode 2 on the Titanium it returns 567 modes I’m not sure if that means they are all valid or that the hardware could support them?

Does anyone know it may be that we have to call this and get the closest mode we are looking for?

SYS "OS_ScreenMode",2 TO ,,,,,,,size%
size%=-size%
DIM block% size%
SYS "OS_ScreenMode",2,,,,,,block%,size% TO ,,count%
count%=-count%
PRINT count%;" modes in ";size%;" bytes"
WHILE count%>0
  count%-=1
  CASE block%?4 OF
    WHEN 1:
      PRINT "X";block%!8;" Y";block%!12;" depth ";block%!16;" rate ";block%!20;" name ";FNname(block%+24)
    WHEN 3:
      PRINT "X";block%!8;" Y";block%!12;" ncolour ";block%!16;" flags ";STR$~(block%!20);" log2bpp ";block%!24;" rate ";block%!28;" name ";FNname(block%+32)
    OTHERWISE:
      PRINT "Unknown format ";block%?4
  ENDCASE
  block% += block%!0


ENDWHILE
END

DEF FNname(a%)
A$=""
WHILE a%?0 > 0
  A$ += CHR$(a%?0)
  a%+=1
ENDWHILE
=A$

Reading the block first might help, I have not tried it.

SYS "OS_ReadModeVariable",-1, 0 TO ,,flag% gets the colour order flags.

Use the X form of the SWI and try to set the normal TBGR format. If that fails, then simply set the TRGB flag and call the SWI again. That’s what I did for Virus.
It’s a shame there’s no easy way to specify “I want a screen mode of X x Y and since I’m using OS routines I don’t care what order the colours are in”.

Hear, Hear. I had to do the same song and dance in !Doom.

Is there an easy way / system call to tell what modes the Display Manager uses for the WIMP?

Perhaps this would be the way to get a realiable screen mode?.

David Can you Download the program from below I have tried it on the
Titanium and PI2B+ and the Iyonix and it works on all.

www.mbelect.co.uk/RISCOS/progs/ChangeMode.zip

Cheers

David Can you Download the program from below I have tried it on the
Titanium and PI2B+ and the Iyonix and it works on all.

Yes, thanks for that. It works on both my Raspberry Pi 2B and 4.

Thanks also to everyone else who has contributed advice and information.

The only issue I’m dealing with on the RPi4 is that, unlike my other Pi models (Zero, 2B, 3B, 3B+), the 4:3 aspect ratio of the 800×600 screen mode is not preserved; the display is stretched horizontally to fill the entire screen.

Incidentally, PROCAllocateScreenMemory assumes that you want to set up 3 screen banks (for triple buffering), but as you’ve probably noticed with Gorillas, the game uses only a single screen bank. It sets up a 800×600 32-bpp sprite as a back buffer, then draws all the graphics on that, then ‘blits’ the final image via OS_SpriteOp, which is flipping fast these days (probably because it’s GPU-accelerated). Fast enough not to bother with double or triple buffering, and much more convenient. Others may take a different view, of course.

Glad to hear that it works on your setup.

I have not looked at your program in that amount of detail.
Its good to hear that you can only use a single screen bank.
I’ll have a closer look , might be something I use in the future :-)

Incidentally, PROCAllocateScreenMemory assumes that you want to set up 3 screen banks (for triple buffering), but as you’ve probably noticed with Gorillas, the game uses only a single screen bank. It sets up a 800×600 32-bpp sprite as a back buffer, then draws all the graphics on that, then ‘blits’ the final image via OS_SpriteOp, which is flipping fast these days (probably because it’s GPU-accelerated). Fast enough not to bother with double or triple buffering, and much more convenient. Others may take a different view, of course.

Just a quick update.

I changed (Bodged) !stargate to use a single screen and you are correct it run slightly faster
Plotting to a sprite must be quicker than to the screen?

Do you know if reading from a sprite is also quicker than the screen?.

Do you know if reading from a sprite is also quicker than the screen?

In my experience it is quicker.

Read-modify-write operations (such as alpha blending) can be much slower when accessing ‘screen memory’ (at least on the Raspberry Pi and other GPU-based hardware), which is the main reason why I’ve opted to render all the graphics to a RISC OS sprite (or occasionally a private buffer which amounts to the same thing) and then finally ‘blit’ to the screen with SpriteOp. I learnt earlier this year that SpriteOp (34) draws non-masked sprites (assuming no fancy plotting action) at least as fast as my custom plotters (masked sprite plotting via SpriteOp is still comparatively slow, but nevertheless fast enough for many uses).

—

On the Gorillas front, the game is now almost completely frame-rate independent (I should’ve done that in the first place), so that it’s more playable on e.g. the Raspberry Pi Zero and under emulation, and across wildly different screen refresh rates (we’re up to 120 Hz nowadays, aren’t we?). I’ll release the updated version in a few days when I’ve fixed one or two annoying little issues.

Thanks for the feedback, David. I think the performance of the program is largely down to main memory bandwidth which is significantly greater on the RPi 2 than the RPi 1B+ (maybe 5 or 6 times faster, IIRC). Displaying an 800×600 32-bpp bitmap every frame is quite onerous on the memory system (about 1.8 Mb of data per frame). And the way I’ve done it (using a sprite as a rendering surface, rather than a screen bank) effectively means twice as much data being transferred.

Gorillas is an all time classic. I did use a lot the web version… So I really like the RISC OS port :)

Hey I remember this game! (last seen as a CP/M port in Turbo Modula-2 :)
Cool version, looks great, plays good!

Just released version 1.03, which has the following changes:

- Game is (mostly) frame-rate independent, so things happen at the same rate regardless machine speed and monitor refresh rate.

- Should run ok on the Titanium (thanks Terry), if not then it’s my fault.

- You can disable VSync waiting by clicking the option on the title/menu screen. Useful for slower machines.

- You get a sound effect and congratulatory message if you kill your opponent on the first go of a round (as well as getting to go first on the next round).

- Source code tidied up a bit, but could do with more tidying.

- For possibly improved performance, by default the program has BASICVFP load and run the game. If BASICVFP isn’t available, then comment-out the relevant line in the !Run file, and uncomment the last line of the !Run file. Perhaps I should automate this check somehow within the !Run file?

- Game uses David J. Ruck’s TimerMod for the accurate timing. So thanks are due to him.

Download:

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