Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: RhoSigma on October 16, 2021, 07:35:46 pm

Title: Found a mysterious command
Post by: RhoSigma on October 16, 2021, 07:35:46 pm
When looking over the registered commands and function list in file \source\subs_functions\subs_functions.bas I found a command, which obviously never got real public attention.

It's _FPS, either be called with a SINGLE number designating the desired fps in the range 1-200 or the keyword _AUTO. The command gets not syntax highlighted yet, has no help page in the IDE nor a Wiki entry or anything else.

After deeper investigation I found, that it was first available in v1.0 build 51. It's purpose is to set the maximum frame refresh rate of the _AUTODISPLAY mode. While this is working for given numeric values in the valid range, the _AUTO keyword otherwise is just resetting it to the regular 30fps, but according to the comments in libqb.cpp it was planned, that the _AUTO mode should also dynamically adjust the refresh rate depending on the current CPU load, which obviously never got implemented.

Code: QB64: [Select]
  1. 'this example doubles the refresh rate every 2.5 mil. loops
  2.  
  3. _FPS 1
  4. FOR x = 0 TO 10000000
  5.     PRINT x
  6.     IF x = 2500000 THEN _FPS 2
  7.     IF x = 5000000 THEN _FPS 4
  8.     IF x = 7500000 THEN _FPS 8
  10. _FPS _AUTO 'regular 30fps again
  11.  
  12.  
Title: Re: Found a mysterious command
Post by: SMcNeill on October 16, 2021, 08:59:12 pm
I remember finding this command once in the past, and then forgot about it...  I was hoping this command could be useful for helping to speed up how slow PRINT is when it comes to a program, but it doesn't help like you might  expect.  I figured fewer print updates (less calls to _DISPLAY), the faster a program might run, but it really seems to make very little difference from my testing here:

Code: QB64: [Select]
  2. Screen _NewImage(1024, 720, 32)
  3.  
  4.  
  5. t# = Timer(0.001)
  6. For i = 1 To 1000000
  7.  
  9. Print Using "###.###### seconds running a blank loop"; Timer(0.001) - t#
  10.  
  11. t# = Timer(0.001)
  12. For i = 1 To 1000000
  13.     Locate 2, 1: Print i; " of 1000000"
  15. Print Using "###.###### seconds running a blank loop with print"; Timer(0.001) - t#
  16.  
  17. _FPS 1
  18. t# = Timer(0.001)
  19. For i = 1 To 1000000
  20.     Locate 4, 1: Print i; " of 1000000"
  22. Print Using "###.###### seconds running a blank loop with print and FPS 1"; Timer(0.001) - t#
  23.  
  24. _FPS 240
  25. t# = Timer(0.001)
  26. For i = 1 To 1000000
  27.     Locate 6, 1: Print i; " of 1000000"
  29. Print Using "###.###### seconds running a blank loop with print and FPS 240"; Timer(0.001) - t#
  30.  
  31. _FPS _Auto
  32. t# = Timer(0.001)
  33. t1# = Timer + .1
  34. For i = 1 To 1000000
  35.     If Timer > t1# Then t1# = Timer + .1: Locate 10, 1: Print i; " of 1000000"
  37. Print Using "###.###### seconds running a blank loop with timed print and normal FPS"; Timer(0.001) - t#
  38.  
  39.  

A loop from 1 to 1,000,000 takes about 0.005 seconds to run on my machine.

By inserting just a simple counter to track progress, that same loop now takes about 12.5 seconds to run, regardless of what the _FPS setting is, from default to 1 to 240.

Seems like the only way to do any sort of reasonable counter is still to only update the display with a reasonable timer like the last example above.  (.1 second updates on completion), which keeps us on 0.03 seconds to completion, adding little overhead to run time.

It's a shame _FPS can't actually help that much with printing speeds, like you'd think it would.  Is there any real use for this command?  I couldn't think of any place where I'd ever need to use it, so I ended up just forgetting it even existed in the past.
Title: Re: Found a mysterious command
Post by: Qwerkey on October 17, 2021, 05:48:30 am
Quote from: RhoSigma on October 16, 2021, 07:35:46 pm
... in file \source\subs_functions\subs_functions.bas I found a command, which obviously never got real public attention.

It's _FPS

Not only a mysterious command, but a 'non-existent' one!  It doesn't appear in the authoritative Wiki and therefore does not exists!
Title: Re: Found a mysterious command
Post by: luke on October 17, 2021, 06:05:16 am
Technically, the _FPS value is the desired rate for the glut display callback to be called (the actual rate may be less if things can't keep up). This function is internal/c/libqb/gui.cpp:GLUT_DISPLAY_REQUEST(), which is what displays images surfaces on screen (including hardware images), actually calss Sub _GL() and handles resizing. Thus it's likely the rate at which _GL() is called, and the maximum frame rate you can get no matter how many times you _PUTIMAGE per second.
Title: Re: Found a mysterious command
Post by: bplus on October 17, 2021, 09:48:17 am
This seems like _Limit but _Limit could be used in any loop. Am I missing something?

Perhaps accessing an internal GL loop?
Title: Re: Found a mysterious command
Post by: RhoSigma on October 17, 2021, 11:52:15 am
Quote from: bplus on October 17, 2021, 09:48:17 am
This seems like _Limit but _Limit could be used in any loop. Am I missing something?

Perhaps accessing an internal GL loop?

In fact it's very similar what a _LIMITed loop with an _DISPLAY at the end would do:

Code: QB64: [Select]
  2.     _LIMIT 20
  3.     'do something
  4.     'draw something
  5.     'print something
  6.     _DISPLAY
  7. LOOP UNTIL whatever
  8.  
  9.  

but _FPS does it without the need to switch _AUTODISPLAY off, hence:

Code: QB64: [Select]
  1. _FPS 20
  3.     'do something
  4.     'draw something
  5.     'print something
  6. LOOP UNTIL whatever
  7.  
  8.  

of course it wouldn't prevent screen flickering, as without _DISPLAY you don't be able to specify where exactly the screen update shall happen, _FPS just simply limits the _AUTODISPLAY refresh rate (see also luke's post above)
Title: Re: Found a mysterious command
Post by: bplus on October 17, 2021, 12:07:06 pm
_Limit works fine without Display, say for not burning out CPU on massive number cruncher or limiting the getting of mouse and keypress polling.

I've been thinking that _FBS might be limiting the _GL automatic drawing it does, thus a need for communication to that.

But that does not make sense if FBS has been around before _GL, but it does have the _underline so not QB45 compatible thing.
Text Only | Text with Attachments