Behaviour of WAIT?

[p_m21987]

Hello,

Sorry, I posted this thread before I had properly tested it. I was wondering if WAIT with no parameters behaved differently in BBCSDL vs BB4W, but now I see that they seem to behave the same. It looks like WAIT with no parameters waits for one centisecond.

I posted this thread because I noticed that my TENIS ball game seemed to run slower on BB4W. I'm going to examine further and see if I can work out why.

Regards,
Patrick

[p_m21987]

Now I know what I was wondering about - it's the behaviour of *REFRESH, not WAIT.
In BBCSDL, *REFRESH seems to wait for vsync. In BB4W, this isn't the case.

I tested it with this short program:

Code: Select all

      *REFRESH OFF

      TIME=0
      C%=0
      REPEAT
        C%+=1
      UNTILTIME>100
      PRINTC%
      *REFRESH


      TIME=0
      C%=0
      REPEAT
        C%+=1:OSCLI"REFRESH"
      UNTILTIME>100
      PRINTC%
      *REFRESH


      TIME=0
      C%=0
      REPEAT
        C%+=1:WAIT
      UNTILTIME>100
      PRINTC%
      *REFRESH

[guest]

It looks like WAIT with no parameters waits for one centisecond.

Well, rather a minimum of one centisecond (it hands back control to the Windows kernel, so a task switch is likely; how long it waits will depend on what other processes are running and how many CPU cores there are).

I noticed that my TENIS ball game seemed to run slower on BB4W.

What made you think that WAIT might be responsible? If your program involves any I/O (i.e. it's not performing purely a computational task), and particularly graphics output, then there's no reason to expect its speed to be at all similar on BB4W and BBCSDL. I've seen programs that run much slower in BBCSDL compared with BB4W, and others that run much faster.

The example program 'squares.bbc' supplied with BBCSDL (all editions) is a case in point: on this PC it runs something like ten times faster in BBCSDL than in BB4W! This is by no means typical, but does indicate just how large the difference can be.

Richard.

[guest]

In BBCSDL, *REFRESH seems to wait for vsync. In BB4W, this isn't the case.

Indeed so, as I've explained before. But that shouldn't mean it runs slower in BB4W, as you described, but rather faster.

Richard.

[p_m21987]

Hello,

What made you think that WAIT might be responsible? If your program involves any I/O (i.e. it's not performing purely a computational task), and particularly graphics output, then there's no reason to expect its speed to be at all similar on BB4W and BBCSDL. I've seen programs that run much slower in BBCSDL compared with BB4W, and others that run much faster.

I got confused and thought it was WAIT because in my game code, WAIT and *REFRESH were next to each other. And that was because I originally wrote the game for RISC OS, where WAIT was there to wait for VSYNC, and originally in the place of the *REFRESH command, there was a procedure call that I wrote to operate RISC OS's features for switching screen banks.

It turned out that the game was running slower in BB4W because of a timing routine in my game. The timing code counts the number of frames drawn for 1 second, and then uses that number to decide how fast the ball should move. This was intended to make it run at the same speed in case of different refresh rates. But it seems that it doesn't work correctly, so the game ended up running too slowly on BB4W.

Patrick