Rougol talk demos & games update

I have updated my Stargate game to run either in the desktop or fullscreen, all of my games use the same animation technique which is demonstrated in the demo files also available from the website.

Demo files
!SimpleDemo The minimum amount of files needed to operate (easier to understand).

!ModesDemo Adapts the sprites used (Mode28) to your current screen.

!ShowDemo The main demo I used in the talk contains slides I used as prompts (may be of use to others) allows demonstration of the fact that drawing a sprite to the screen can ignore the Vsync with good results?

The games and demos include full sources these can be used in your own programs in anyway :-)

If you find any of these interesting download from:-

www.mbelect.co.uk/RISCOS/

Thanks Terry and again, great talk and presentation! :)

To echo Paolo’s sentiments. Thank you for sharing the files, your RISC OS game writing experiences, and an informative talk. I’d expect the files to be useful to anyone looking to write a game using RISC OS.

I wrote about the process of creating my game, through the first sixteen days of December.
Start at https://heyrick.eu/blog/index.php?diary=20211201

Thanks for the feedback with regards to the talk.

When I first started looking at writing a game either there was no source code supplied or it was a complete complex game which can be quite difficult to follow.

Hopefully if people look at the demo files and then the games they should be able to follow my efforts.

If anyone can improve on my creations or make an effort to write their own games, that’s fine.

When I first started looking at writing a game either there was no source code supplied or it was a complete complex game which can be quite difficult to follow.

The problem I ran into was that there are numerous platform games with source around (as Mamie is a platformer), but they rely upon frameworks and libraries that do all the hard parts. Yeah, it’s apparently easy to write a complicated game for another system (Linux?), but when you’re looking at a blank screen and the description of OS_SpriteOp, it’s a whole different matter.

So my game was written by thinking “what is going to happen here” and then “what code makes that work”.

I was actually surprised how little information there was on creating a game (any game) by directly splatting sprites onto the screen and handling frame-by-frame animation, given that’s pretty much how the SMS/NES era rolled, not to mention a retro revival of the old games. I guess fitting a complete game (sprites, music, map, and all the code) into 32K is a lost art…

Interesting idea, drawing to a canvas.

The method I used, along with triple buffering and drawing directly to the screen, was to fix the animation to “about 50fps”.

At the beginning of the loop, I call screen_switchbank() which waits for VSync, and then sets up the next bank to show and write to.
As this returns, note the time of our return (in centiseconds).

Then all the game logic and drawing happens. It uses named sprite plots rather than looking up by address. Mostly because it worked fast enough on a Pi2 that I didn’t feel the need to add the complication of using sprite addresses.

At the end:

do {} while ( (Time_Monotonic() - framestart) < 2 );

This stretches the redraw loop to actually run at ~50Hz. The VSync is to guard against screen tearing as banks are switched, and the triple buffering means it’s all nice and smooth. But most importantly, consistent. It shouldn’t be running a quarter faster because you’re using a faster refresh rate!

Tested with a monitor running at 60Hz, and at 75Hz.

Today’s lesson, folks… more than one way to crack a nut. :-)

The VSync is to guard against screen tearing as banks are switched, and the triple buffering means it’s all nice and smooth.

Triple buffering is also necessary on the PIs to prevent tearing because the VSyncs on these machines are fake ones.

That is the interesting thing, none of my games use any kind of Vsync detection at all and work fine on PIs ,Iyonix and Titanium. No triple or double buffering is used?.

Drawing to a canvas sprite and then ploting the whole canvas sprite to the screen in one go seems to give very good results.?

I would be interested to know why this works so well, any ideas?

Also the canvas sprite can be converted to any screen mode as the last operation. Perfect for plotting on to the desktop.

@ Terry

Quick fix, !Demo is missing WimpSlot -min xxxxk in the !Run file, this can cause issues if a user did not set a Next Slot large enough.

Drawing to a canvas sprite and then ploting the whole canvas sprite to the screen in one go seems to give very good results.?

Technically that is still “double buffering” although if not in a traditional sense.

I used similar approaches many many years ago on the PC 128 and other 8 bit micros. Generated the graphic on a RAM bank (16KB, 8KB for the graphics info and 8KB for the colour info) and then push that bank straight into video RAM.

Except, back then, the were a bunch of tricks to reduce the amount of “rewritten screen” and to sync the plot, for example waiting for a HALT signal or use the “floating bus” (on the ZX Spectrum 48K), which was a wait loop to capture the ULA attribute bytes being rewritten and when finding the appropriate one trigger a rewrite using the correspondent from the “shadow” screen.

Your approach of writing on a canvas and then just write the whole thing on the screen seems somewhat similar to these old approaches. It’s surely interesting that such type of approach still work well on machine like the RPi with Gigs of clock speed.

Quick question, have you tried it yet when implementing parallactic scrolling (parallax)? (ie scrolling background and using multiple backgrounds to simulate parallactic effect on the eye)

Thanks

I think you mean parallax scrolling.

By definition paralytic scrolling couldn’t. ;)

Technically that is still “double buffering” although if not in a traditional sense

David Williams who wrote !Gorillas suggested I try writing a Sprite to the screen for speed I don’t know if he noticed the Vsync effect?

Yes I realise that its a form of double buffering but if you take the situation below:-

If I run Stargate in fullscreen MODE28 my refreash rate on the Titanium is 75Hz (FPS)
Stargate runs at 60 FPS and increases by 1 FPS per level. The game is not Vsynced (No WAIT command is used ) but does not produce any tearing efects?, even though it might be running anywhere between 60 to 70 FPS or higher.

The same can be said of Munchy which starts at 50FPS and increases during play?

So the question is why can you write a whole sprite to the screen at any time you like and there is no tearing effect or if it is there is so small you can’t see it?

Don’t forget that in a MODE28 screen the whole screen is being replaced at whatever FPS my game is running at so you would expect some tearing?

This works within the emulators,Iyonix,PI2B,PI400,Titanium still interesting?

BTW I’m not complaining because when running under the desktop if wait for Vsync is NOT used the programs generally exit quicker allowing better multi-tasking. :-)

@ Rick

I think you mean parallax scrolling.

By definition paralytic scrolling couldn’t. ;)

Oh dear! I am so sorry, it was the autocorrect I am using… I guess it was better when I was doing my own miss-spellings XD

Edited and thanks!

@ Terry

So the question is why can you write a whole sprite to the screen at any time you like and there is no tearing effect or if it is there is so small you can’t see it?

Maybe we can find some answers here:
OS_SpriteOp: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/vdu/vdugrafg#L217

Calling for display a sprit eon screen using ext coords: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/vdu/vdugrafg#L1128

Display a sprite on the screen: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/vdu/vdugrafg#L1191

I have now fixed the missing wimpslot (Thanks Paolo)

I have also uploaded some desktop Demos these are files I used before creating the desktop version of my games, mainly just testing out Ideas.

See Readme from zip file below, not very exciting but might be of use to someone.

!DeskDemo (has slides runs in desktop same as show demo) uses Wimp_Poll
!Clouds (badly drawn clouds used to test graphics) uses Wimp_PollIdle

!DeskDemo
If you switch off/on the Vsync you can see the effect on the Wimp poll especially if the FPS
exceeds the monitor Vsync.

!Clouds
Just draws clouds one of the first tests I did using Wimp_PollIdle running at 100 PPS 50FPS

Download from www.mbelect.co.uk/RISCOS

Thanks Terry!

Your work is indeed extremely interesting :)