Found a mysterious command

[RhoSigma]

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
9. NEXT
10. _FPS _AUTO 'regular 30fps again
11.  
12.  

[SMcNeill]

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]

1. $Resize:Smooth
2. Screen _NewImage(1024, 720, 32)
3.  
4.  
5. t# = Timer(0.001)
6. For i = 1 To 1000000
7.  
8. Next
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"
14. Next
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"
21. Next
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"
28. Next
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"
36. Next
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.

[Qwerkey]

... 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!

[luke]

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.

[bplus]

This seems like _Limit but _Limit could be used in any loop. Am I missing something?

Perhaps accessing an internal GL loop?

[RhoSigma]

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]

1. DO
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
2. DO
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)

[bplus]

_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.