1. Forum
  2. Usenet
  3. COMP.SYS.ACORN.PROGRAMMER

  • Instability in rectangular cursor

    From Steve Drain@21:1/5 to Richard Ashbery on Fri Nov 13 14:10:05 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Ashbery@21:1/5 to All on Fri Nov 13 13:17:57 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Ashbery@21:1/5 to [email protected] on Fri Nov 13 17:12:44 2020
    In article <rom466$13m9$[email protected]>, Steve Drain
    <[email protected]> wrote:
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Fryatt@21:1/5 to Richard Ashbery on Fri Nov 13 19:24:09 2020
    On 13 Nov, Richard Ashbery wrote in message
    <[email protected]>:

    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Drain@21:1/5 to All on Fri Nov 13 20:33:00 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Ashbery@21:1/5 to [email protected] on Sun Nov 15 13:20:21 2020
    On 13 Nov in comp.sys.acorn.programmer, Steve Fryatt
    <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)