Instability in rectangular cursor

15 views
Skip to first unread message

Richard Ashbery

unread,
Nov 13, 2020, 8:18:46 AM11/13/20
to
Are there any BASIC programmers out there who may have missed my
posting on ROOL > Forums > General about an issue with a routine that
simply animates a rectangular cursor across the screen by moving the
mouse? The mouse overlays another horizontal rectangle but in so doing
results in instability and spoils the rendering. Any solutions would
be welcome.

MODE 1920,1080,32
PX%=0
PY%=0
REPEAT
GCOL 0,0,255
RECTANGLE FILL 0,0,3838,100
MOUSE MX%,MY%,MB%
GCOL 255,0,0
RECTANGLE FILL PX%-50,PY%,100
IF MX%<PX% THEN : PX%=PX%-1 : ENDIF
IF MX%>PX% THEN : PX%=PX%+1 : ENDIF
UNTIL0

Steve Drain

unread,
Nov 13, 2020, 9:11:26 AM11/13/20
to
On 13/11/2020 13:17, Richard Ashbery wrote:

> The mouse overlays another horizontal rectangle but in so doing
> results in instability and spoils the rendering. Any solutions would
> be welcome.

I am not sure I get what you want, but you could try a WAIT before one
or both the RECTANGLE statements.

Richard Ashbery

unread,
Nov 13, 2020, 12:17:28 PM11/13/20
to
In article <rom466$13m9$1...@gioia.aioe.org>, Steve Drain
Thanks for responding.

You make a fair point and although WAIT does work in this example it
dramatically slows down the program that this code has been ripped from.
Please have a look at...

http://www.riscosbasic.uk/problems/Kill_verticals.zip

Unfortunately the program is not named but I believe it may have been
created by Krzysztof Jankowski and can be found on YouTube. The
original program was done in MODE 28 but I wanted to see if I could
convert it for 1080p monitors. Original mouse cursor has instability
issues but these are magnified in 1920 x 1080 modes.

Scoring logic appears slightly odd - it takes a very short time to build
up a huge score - this may require tweaking.

Regards

Richard

Steve Fryatt

unread,
Nov 13, 2020, 2:35:05 PM11/13/20
to
On 13 Nov, Richard Ashbery wrote in message
<58cedbd8...@invalid.addr.uk>:

> You make a fair point and although WAIT does work in this example it
> dramatically slows down the program that this code has been ripped from.

It will do, because it seems to rely on replotting the screen many times a
frame, which is what causes the tearing effect.

WAIT simply pauses the program until the start of the next video frame, when
there's a small window of time in which to update the screen while the video
flyback is happening. If the code is expecting to execute the REPEAT loop
many more per second than the monitor refresh rate, then the game will slow
down as a result.

Unfortunately, you can't change the video refresh rate because that's set by
your monitor, so to fix the tearing you will need to decouple the game
timing from the screen update.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Steve Drain

unread,
Nov 13, 2020, 3:32:59 PM11/13/20
to
There is also the possibility of swapping screen banks, updating
the hidden bank before displaying it.

It is a very, very long time since I did this, but I think I
recollect a ROOL Forum topic about doing it on modern machines
using 3 banks.

--


----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

Richard Ashbery

unread,
Nov 15, 2020, 8:49:25 AM11/15/20
to
On 13 Nov in comp.sys.acorn.programmer, Steve Fryatt
<ne...@stevefryatt.org.uk> wrote:
> > You make a fair point and although WAIT does work in this example
> > it dramatically slows down the program that this code has been
> > ripped from.

> It will do, because it seems to rely on replotting the screen many
> times a frame, which is what causes the tearing effect.

> WAIT simply pauses the program until the start of the next video
> frame, when there's a small window of time in which to update the
> screen while the video flyback is happening. If the code is
> expecting to execute the REPEAT loop many more per second than the
> monitor refresh rate, then the game will slow down as a result.

> Unfortunately, you can't change the video refresh rate because
> that's set by your monitor, so to fix the tearing you will need to
> decouple the game timing from the screen update.

Thanks Steve for the explanation. It looks as though a complete rewrite
is necessary. Steve D indicated that triple buffering may be required -
I briefly had a look at this but understanding the process is
challenging - maybe it's time for a revisit.

My simplified version does away with the mouse cursor and relies on the
wash colour to erase the verticals - it seems to work just as well but
doesn't look so pretty.

Richard

Reply all
Reply to author
Forward
0 new messages