Early demo game needs some testing

Hi

Can some of you try this demo of a little game I started writing, It was inspired by:-

1. being locked in
2. !virus by Rick Murray
3. BASIC demos by David Williams
4. I have never tried to write a game
5. I am always doing serious stuff and needed a distraction.
6. See how fast BASIC is on newer machines
7. Its sort of based on stargate for the Acorn Atom (search youtube)

I would like you to try this on different versions of RISC OS machines
I have a titanium and get 75fps with almost any reasonable setting.

It uses MODE 28 (640,480,256) which I think is available on most machines as standard.

I have tried it on a Rpi model 2B+ and I get 50fps with up to 30 alien
critters.

What you can do so far (not much)

There are 4 stargates at the top of the screen once they start to spin, It
wont be long before your not alone. Each of the alien critters can only
arrive through a spinning stargate. You can close the gate by hitting it in
the centre of the gate.

You move your ship with X,Z on the keyboard and fire with Enter/Return

Each alien has 26 collision points that detect if they are being hit.

Your ship is indestructible so the critters just hit you and bite the dust
this is either because your indestructible or I have not written the
detection code for the Rocket Ship yet :-)

When you start the game you are asked how many aliens and the speed that
they appear and the spin up speed of the startgates

I am interested what fps you get, I wrote a version in BASIC and a version
in C and have similar performance with regards to fps on the two machines
I have here.

I will work on the BASIC one if I get some good results back, I think the
Rpi 2 is probably the lowest spec machine that this will work on?.

Let me know what you think?.

I am using RDSP (thank you) for the sound effects, I have just used ones from the examples that are supplied, so if anyone has any graphics / sounds they
would be quite welcomed as these two areas are not my strong point.

you can download from here:-
www.mbelect.co.uk/RISCOS/progs/Stargate.zip

Be gentle its my first attempt :-)

Thanks

I tried to run it on my ARMX6 and got No room for this DIM.

Try increasing the next memory in the tasks manager

WimpSlot needs to 800k.

On both the Titanium and RPi4 the frame rate was 60fps.

The horizontal movement of the gun was a bit fast for my fingers but to be fair I am not a game player.

Overall it is impressive what BASIC can achieve.

Terry, for a first attempt and at a very early stage of developement, well done.

Just a few points.

1..You need collision detection on players ship obviously. You mentioned this yourself.

2..Make the players ship a little smaller. Try half the size in both X and Y. It is too easily hit.

3..Give the players ship some form of shields that go down over time before dying. Maybe based on a level of difficulty.

4..Have the settings for number of aliens and spin up of the stargates a preset. Maybe dependant on the difficulty level. See 3 above.

5..In your !Run file incorporate a WimpSlot command to set up the memory it needs to run. This will stop all the " No room for this DIM " errors.

I think these are easily achievable based on what you have done so far and will also make it a much more playable and fun game. These are just my initial thoughts and not a wish list. Maybe these will set you off on a different tangent and you will have better ideas. Good luck.

I too have been developing my own first real game for a while and thanks too Rick Murray, he persuaded me too continue and finish it so continue with your game so you can gauge what you are capable of. You may find you might want to do more.

It ran at 60fps on my PI 2B+ on middly settings.

Greg

Sorry, haven’t looked at it yet, but thinking about which screen modes to use which will work for everyone; mode 28 (640×48) should still work on every monitor (thanks to PC’s still booting up in VGA mode), but is very low resolution for doing anything. Mode 32 (800×600) might still won most monitors but is still quite low res. I think it’s probably time to standardise on Full HD (1920×1080), but that might stretch BASIC a bit!

David, can a PI use 1920 × 1080 triple buffered ?

I’ve been considering, for my game, maybe the next game having the settings allow player too choose the resolution. Or maybe in the initialising stage setting a MODE relevant to what the machine / monitor can display and then setting the game up too that MODE.

Hi

Thanks for the replies

I have a few idea’s with regards to how the games can progress as it levels up.

In the original there was a longer wait before the aliens came through the stargates
this allowed you to shut them on lower levels and score points, could also enable a shield?.
Occasionally an alien would shoot directly down from the startgate to catch you out at higher levels.

At lower levels only 1,2 gates could open at a time. increasing as you level up.

Different types of alien

I will add the wimp slot command

I left the graphics larger than they would be to put the system under more pressure
mainly I was interested in seeing if people get a stable fps to see if it was
worth carrying on with the BASIC version. I just wanted a way of getting as many sprites on
the screen at the same time to test the fps.

Its temping to write it in C but interesting to see how good BASIC could be?.

With regards to the screen mode I think a higher res game might be a mark2 game
I will see if I make it to the end of this one :-) , baby steps.

David, can a PI use 1920 × 1080 triple buffered ?

I know the Pi 3B I have running RISC OS can double buffer at Full HD, I’ve never needed to triple buffer in any of my code, I’ll have to give it a go sometime.

The only reason why I ask David is because I seem to recall it was advisable to use tripple buffering on a PI as it does VSync / screen refresh a little different to the legacy machines and therefore screen tearing could of been an issue. I may be remembering this a little wrong.

Out of curiosity Terry does your game use double buffering or tripple buffering.

It uses triple buffering I did try double buffering but on the PI
there was flashing / tearing of some graphics.

thanks too Rick Murray, he persuaded me too continue

Crap! You sent me an update recently didn’t you? I’m going to have to rummage around my mailbox to retrieve it. It’s been… hectic here. Wasn’t terribly well early last week, and I’m finding this extra half hour a day (FFS, that’s like only 2½ hours a week!) really takes it out of me. Either that or my body has suddenly realised “dude, you’re an old fart now”.

Still, no excuse, is it? Especially when your game is that bloody good that it would actually be criminal to not carry on with it!

Yeah, the Pi can provide a fake VSync which I think comes at a specific interval that doesn’t necessarily bear any resemblence to when the top of the screen is being drawn. It might depend upon whether RISC OS is controlling the GPU directly, or whether the GPU is outputting the same thing to the display and faking everything else for RISC OS. I use the latter, because my monitor is 1280×1024 so doesn’t do FullHD or arbitrary modes, so it’s useful to have the GPU rescale “whatever” to fit the display. From FullHD down to MODE 13, it all works. But the size effect is that triple buffering is needed for a nice solid display.

I thought I’d read that right somewhere about the buffering.

Rick no probs lol. I’m struggling to find a decent amount of time myself. Thanks for the nice comment.

Good job this game isn’t a commercial jobby with deadlines, i’d be screwed by now lol.

Like with you Terry its a case off one step at a time. I have to say though it has been a fantastic learning curve on game developement and programming in general. So much to take in and so many ahh haa moments.

60 fps with settings 50 50 50 on a Pi 1. Very good work!

Increasing the Next slot and the game works on the ARMX6 at 60FPS.

Wasn’t terribly well early last week, and I’m finding this extra half hour a day (FFS, that’s like only 2½ hours a week!) really takes it out of me

Nothing that occupies the news channels¹ I trust?
If it was, then be aware it “kinda lingers”

¹ All the channels with space not filled by sulky Sam and his team of half-wits²

Authentic Steve, taken to Aldershot → https://www.riscosopen.org/forum/forums/12/topics/15910

If the fake Vsync comes at a specific intervals I wonder
if you could use a timer to ignore it?

50hz(fps) = 20ms so if you got a Vsync to early 19ms or less
then could you ignore it?

I seem to remember Timermod module which from memory would be fast
enough to test this out?

I haven’t looked in any detail, but I think the problem boils down to what RISC OS thinks is going on versus what is actually going on.

My monitor is refreshed by the GPU at 60Hz (used to be 75Hz but there didn’t seem much point when the LCD panel runs at 60Hz). RISC OS says, if I remember correctly, 53Hz in the display manager (no idea where that comes from) and when testing my game and counting VSyncs per 100cs, it did give a figure around 60Hz.

So it appears that the sync is more or less correct, just not at the actual point where the sync is supposed to happen.

The hard way around this is to jump on a high resolution timer and run your own sync locked into VSync, only happening at the right time (and hope it doesn’t vary depending on the clock speed the things are running at, actual output resolution, firmware version, Pi model, blah blah).

The easy way is to just allocate a bit more screen memory and triple buffer.

My curiosity got the better of me.

I wrote a little BASIC program to time Vsyncs
It first works out the time an average Vsync takes
then adds 3% to get an upper limit.

It the compares 1000 Vsyncs with the upper limit.

The PI appears to send late Vsyncs at whatever refresh rate you have your screen set to.

So if you have a refresh rate of 60hz you will get late Vsyncs at 60,120,180 etc

If I run the program on the Titanium I get no output (no late Vsyncs)

You can try it for yourself ?

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

Just tried running that remotely against a mini.m and RPi 3B, don’t quite understand the output as its showing a lot of variability. Could it not print a summary line at the end with the average time and +/- variation?

Its strange The problem seemed to come and go
Earlier today I could repeat the timing error
This afternoon is stopped and now its back

I will see if I can get it to be more reliable

I get ‘unknown or missing variable’ error, I have the ‘next’ set to 800K, what am I doing wrong?

@DavidS was the fps stable when you tried the Game?

@Graham I dont know why your getting that error? try downloading the archive again.

I have updated the Vsync program, which can be downloaded from here:-
www.mbelect.co.uk/RISCOS/progs/Vsync.zip

Could you try it on a PI and let me know if you get around 15,16 errors?

When I run it here on the Titanium I get no errors
maybe 1 sometimes (Could be interrupts maybe?)

When I run it on my PI I get 16 sometimes 15 see above and the Vsyncs do seem to be @ the monitor refresh rate?.

There’s quite a bit of variation in the timings between runs, and number of errors.

Running remotely (mimi.m connected to monitor HDMI, but Display Port in use, Pi 3B HDMI switched out):-

Mini.m; vsync 59.22Hz, 53 errors.
Pi 3B; vsync 59.15Hz, 8 errors.

Running locally (HDMI active on both):-

Mini.m; vsync 60.04Hz, 0 errors
Pi 3B; vsync 59.95Hz, 0 errors