Stargate arcade style game converted from RISC OS

[Hated Moron]

On 06/07/2022 09:32, terryswanb wrote (cross-posted from the Discussion Group):

During the lock down of 2020 I decided to have a go at writing a game for RISC OS called Stargate. This was quite
a learning curve because it was the first game I had ever written.

I have been looking at BBC_SDL over the last few weeks and decided to have a go at converting Stargate to run
on BBC_SDL I must say it was quite a smooth exerience:-

I also own BBC4W so I dropped the original RISC OS BASIC program into BBC4W and this allowed me to copy and paste
the routines into the BBC_SDL editor.

Things that are different :-
Some sound effects have changed the original used the SOUND statement for some effects I decided to use some WAV files.

The collision detection changed, In the RISC OS version I was using the POINT command to read colours to detect if I had
hit anything of interest, this was quite fast in RISC OS as I was using reading an writing to a local memory sprite before updating
the screen. This was quite slow in SDL I suspect reading from the screen takes time, I changed the routine to compare the
location of objects on the screen, This worked rather well and with a bit of adjustment seems to works fine.

The music took a while to get right , I wanted to play different pieces of music one after the other, I found I could read
how many bytes were left in the audio queue and when empty I triggered a new music file, This worked fine until I started to
add sound effects and after reading Richards Audiolib comments I realised that the sound effects were being written into
the music file being played this had the effect of causing the audio queue to never empty until sound effects stopped. What
I decided to do was stop the effects when the buffer is nearly empty , Also if you switched off
the music the sound effects also stopped I got round this by playing a MP3 that contained silence this allowed the music
to be off and the sound effects on without making changes to the program.

I noticed that the frames per second was sometimes dropping (Normally 60fps), Then I realised that I forgot *REFRESH OFF
(problem solved!) I suspect BBC_SDL was trying to update the screen automatically at the time that I then issued a *REFRESH

Hopefully some of the above may be of use to others, there maybe better ways of doing things this is new to me

Anyway I have a application version that runs on windows and have included the source in the code directory so if anyone
wants to improve on my efforts the code is there and your welcome to tweak it and maybe let me know if I have done anything
silly (quite possible)

You can download from https://www.mbelect.co.uk/SDL/Stargate.zip

Game play is not deep avoid things and blast them The later levels get very intense
Instructions are included in the game but (X=right Z=Left Return=Fire)
Let me know how you get on and if it works OK

This is great, thanks! Have you tried running it on other platforms (MacOS, Linux, in-browser etc)? If not would you like me to test it on them for you?

[Hated Moron]

On 06/07/2022 11:05, terryswanb wrote:

No I have not tried it on any other platforms yet, please test if you can I would be interested as to how well it works on other platforms.

I'm a bit tied up with other (non-software) things at the moment, but hopefully I'll get around to it before too long. I did notice that I cannot just click on 'Compile' and leave everything at the default settings because the embedded files aren't correctly selected. So the first thing I'll want to do, for convenience, is to add a whole load of REM!Embed directives to sort that issue.

This maybe a silly question but once you have an application generated by BBC_SDL for the ipad can it be download and run
on another device or do you also need the UDID for the device as well?

iOS is a real pain (as are Apple generally, sadly)! If you want to run your app on a machine that already has BBC BASIC installed (so the UDID is registered) the easiest way is to create a home-screen shortcut - I repeated the instructions for doing that recently. To run it on a machine that doesn't have BBC BASIC installed is currently impractical; I'd love to be able to create an iOS equivalent to my BBC2APK tool for Android, but I don't know how - or even whether it is possible. Even if it is, you would almost certainly need a Mac to do it.

[Hated Moron]

On 06/07/2022 14:17, terryswanb wrote:

It was the law of unintended consequences I thought I was being clever using a FOR loop to load the graphics
now I see why it didn't compile (we learn a little every day

There's nothing wrong with loading resources in a loop, often you will need to do something like that when there are a large number of graphics or sound files with numeric filenames, or the filenames are in DATA statements, or something similar.

I wouldn't suggest not doing that simply in order to make it work in the absence of compiler directives. Rather, add the necessary REM!Embed directives (at the end of the program if you prefer them to be out of the way).

Keeping the program code compact is of practical value, in that it will make the 'application bundle' smaller and may even speed execution by improving cache efficiency. Compiler directives, however, are stripped out when building the application and can be as verbose as you like without having any impact on the bundle size or performance.

Anyway, I'm sorry to say that your program doesn't run on any other platform because you are (no doubt accidentally) calling the Win32 GetTickCount() API which is of course totally Windows-specific. Probably what you meant to call was `SDL_GetTicks()`.

Another issue I've noticed is that your graphics 'sprites' do not have a transparent background when running in a browser. I suspect this is something to do with bit-depth, possibly you are assuming that it will always be 24-bpp RGB which isn't guaranteed on all platforms (particularly mobile platforms which often use 16-bpp). To fix that I had to convert your GIFs to have a genuinely transparent background rather than relying on making black transparent.

With those changes it does run in a browser (although you'll need a fast PC to compensate for the overhead of Web Assembly code). The load time is quite long because of the large number of resource files, but it's worth the wait!

[Hated Moron]

The program has mis-matched REPEAT...UNTILs, can you guide me to where the fix needs to be made? The outline main loop, showing the error, is as follows:

Code: Select all

      REPEAT  <- this is unmatched
        ...
        REPEAT
          ...
        UNTIL FALSE
        END

[Hated Moron]

On 06/07/2022 23:00, terryswanb wrote:

It is the very first REPEAT command just below the REMs of the main loop
I must have copied it by accident when moving things around.

OK I have now deleted that line. The 'Cross Reference' utility is still reporting an error, however: it appears that there are mis-matched IF...ENDIFs in PROCIntroTicker (there are nine IF...THEN statements but ten ENDIF statements!). What do I need to do to fix this please?

Incidentally don't forget the CASE...ENDCASE statement (available in ARM BASIC V and later) as a neater, and probably faster, way of taking different actions than lots of separate IF...ENDIF clauses.

[Hated Moron]

On 08/07/2022 19:28, terryswanb wrote:

I have now uploaded a new version of stargate with transparent graphics.
Running the cross reference utility reports some variables incompatible with Lowercase Keywords
as I never use lowercase keywords I have ignored these warnings, hopefully no one feels to strongly about this.

You can download a new version below:-
https://www.mbelect.co.uk/SDL/stargate.zip

You can just download the source file here :-
https://www.mbelect.co.uk/SDL/stargate.bbc

I created a web app to test the graphics see below:-
https://wasm.bbcbasic.co.uk/bbcsdl.html ... argate.bbb

Thank you. I've still not got around to trying it in MacOS and Linux, but will attempt to do that fairly soon.

It deserves to be featured at proggies.uk but sadly David Williams seems to have gone off the radar (I hope it's not more serious than that) so probably that won't happen.

[Hated Moron]

I've still not got around to trying it in MacOS and Linux, but will attempt to do that fairly soon.

I've now tried it on both and I'm pleased to say it runs OK. The only minor thing I noticed was that in MacOS it paused for a couple of seconds during the start-up phase, probably when it was loading or initialising the music, and also briefly when changing music 'track'. It may be that my relatively old Mac Mini's sound system is a bit on the slow side.

If this conversion has given you a taste for BBCSDL games you might like to check out the supplied gfxlib.bbc library and the associated documentation in gfxlib_docs.pdf. This gives access to the highest-performance 2D graphics readily available from SDL 2.0 and should outperform *MDISPLAY as well as providing features it doesn't support like image rotation.

[Hated Moron]

To get a feel for the performance on less-capable hardware, it runs at about 40 fps on my Raspberry Pi 4 (64-bits), at least in the early stages. I did see it drop as low as 35 fps in more frenetic episodes, but of course I'm always killed before it gets really stressed! Have you considered a demo mode?

I'd expect that you could achieve a significant performance boost by using the routines in gfxlib.bbc, not least because the conversion from GIF then happens just once on loading rather than multiple times on display, as is inevitably the case when using *MDISPLAY.

[Hated Moron]

On 10/07/2022 15:25, terryswanb wrote:

When you say a demo mode, there is the intro screen at the start were the game plays by itself?

That's nice, but I was thinking more of the feature David Williams included in Forces of Darkness, in which the entire game could be played, from start to finish, by replaying one of his successful sessions back from a data file. Admittedly it's more valuable in the case of that kind of game because it's more of a 'quest' in which the stages have to be tackled in sequence, and there are a limited number of ways to achieve success.

It's far from trivial to implement, because the game has to have both a mechanism for recording every move and action of the player, in sufficient detail that it can be replayed and the end result predicted precisely, and playing it back. To give an idea of the difficulties involved, FoD has to have two different data files, one for when it's played on an x86 (with 80-bit floats) and another for ARM (with 64-bit floats)! Even the minutest differences in computation of trajectories etc. are enough to change the outcome over a game that lasts several minutes.

So not at all something I would expect to be retro-fitted to an existing game, far too much work with limited benefit. But when it's a game like FoD invaluable for testing and to prove it really can be completed.

[Hated Moron]

On 11/07/2022 20:07, terryswanb wrote:

I have changed the program to use GFXlib my computers here all run the game at 60FPS so I can't tell
if there is much improvement.

It's helped on my Raspberry Pi 4: now a solid 50 fps (which is the refresh rate of the monitor/TV) in the intro screen.

Are you happy for it to be promoted and the links to be published, e.g. on Facebook and/or Twitter?