Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Simple raycaster, framerate drop due to not-drawn prints

Author
Message
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 17th Jun 2016 10:03
Hey guys

I noticed a little thing that will cause a serious framerate drop.

I have a simple raycaster, I had some sync() and print(screenFPS()) to see what it was up to during raycasting. BUT, removing the sync() command and leaving to Print(ScreenFPS()) would cause the app to go from 2000 FPS to 140 FPS. Removing the Print() command as well would keep the app running at 2000 FPS.

So it seems that having too many not synced Print commands causes a permanent framerate drop.
13/0
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 17th Jun 2016 12:00
140 FPS is your real FPS.

ScreenFPS() is the time between Syncs. So if you add a sync to print some text, you are shortening the time between syncs.
You should only retain your actual sync() that will be in your final game.

Try this "fast" FPS




And now try the real FPS...


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 21st Jun 2016 10:42
But is the code still looping 2000 times per second? It is a small server app, so I just want it to run as fast as possible (and when in use, there will be no sync() command, so I guess that without sync() it will run as fast as possible).
13/0
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 21st Jun 2016 12:54
It is running as fast as your outermost loop.
But if you add an extra sync() inside that loop, then you are effectively resetting the framerate counter, so it appears faster.
In my example, I am showing the sync rate of the inner loop, which is extremely fast.
In reality, my outer loop is much slower, because it is executing the inner loop 1000 times.
To confuse things, sync() is also a slow command. So the outer loop will be faster when you remove the inner sync.

To cut a long story short....don't add an extra sync to print your debug data. Just use the single sync that will be in your final app.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 22nd Jun 2016 09:11
But isn't that inner loop THE loop while it is running? So for as long as the inner loop is running in a closed loop, then the outer loop doesn't matter? And besides, the framerate drop would only come if I removed the Sync() from the inner loop, but I still had a lot of Print() commands in the inner loop.
13/0
Thestroyer
8
Years of Service
User Offline
Joined: 14th May 2016
Location:
Posted: 22nd Jun 2016 19:01
See it like this: if you print getscreenFPS() the framerate is the time that elapsed between the last sync() command and the getScreenFPS() command. So, if you look at BatVink's 1st example, you put a sync() in the inner loop and you essensially let the sync() command go off 1x per print(). If you look at his 2nd example when you only leave a sync() command in the outer loop you print() 1000x per sync() command. You probably get that when you messure the time that it costs to print() 1000 things it's more than when you print() 1 thing.
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 23rd Jun 2016 08:39
Yes, I do get that it costs more to print x1000. The the FPS was about 2000, then I activate the inner loop with x1000 prints without sync in the inner loop, it does the inner loop and then exits and never returns, but the framerate stays at 140 fps, it never goes back up.
13/0
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 23rd Jun 2016 11:12
I have attached the source code. You can press "R" to select raycaster function, then click anywhere with the mouse on the grid to activate the raycast function. If you rem out the sync command in the raycaster function but leave the print command, the framerate will drop significantly. I tried leaving the app running for a while, the framerate did not go back up even though the raycaster function wasn't running anymore. If you keep the sync command and the print command in the inner loop/raycast function, the framerate does not change much.
13/0

Attachments

Login to view attachments
Thestroyer
8
Years of Service
User Offline
Joined: 14th May 2016
Location:
Posted: 1st Jul 2016 14:39 Edited at: 1st Jul 2016 14:40

This is the part you're talking about, I guess.

Whenever you call the sync() command it sets a timer. When you call the sync() command again the timer will stop and it will start a new timer. The amount of time that has passed when the timer has stopped it uses to calculate your fps.
So let's say 1 sec has passed it will say the fps is 1 frame per second. If you put an extra sync() command in your program you essensially higher the frame rate, because it has to do less before the next sync() command comes.
Basicly what you're doing if you don't comment out the sync() command is letting the computer do in that function is:
do
repeat
start a timer
do something really simple
stop the timer and printing it on the screen
until ...
loop

That would be almost the same as a program that did:
do
start a timer
stop the timer and print it on the screen
loop
just like the starting program you get when you open a the starter file:

Concluding The fps may be higher when you use an exra sync() command in your loop, but it doesn't make your program faster, but it only stops the timer multiple times every time it loops. So what you should do is deleting all sync() command except for the sync() command in your main loop just before 'loop'.
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 2nd Jul 2016 08:28
Quote: "Concluding The fps may be higher when you use an exra sync() command in your loop, but it doesn't make your program faster, but it only stops the timer multiple times every time it loops. So what you should do is deleting all sync() command except for the sync() command in your main loop just before 'loop'."


Let's forget about that extra Sync() command and say it was never there. The problem is the print command. If I have any kind of print command in the inner loop, the framerate will drop, significantly.

But in regards to that Sync() command (just in general, not just with my app), does the Sync() command know anything about what kind of loop it is in? If it doesn't, it shouldn't do anything to frame rate having more or less.
13/0
Thestroyer
8
Years of Service
User Offline
Joined: 14th May 2016
Location:
Posted: 2nd Jul 2016 10:43
Quote: "
Let's forget about that extra Sync() command and say it was never there. The problem is the print command. If I have any kind of print command in the inner loop, the framerate will drop, significantly.
"

I think the reason why the framerate drops if you put a print() command in a small loop is that it executes a lot of times per big loop, so ever time it gets called a bit of your computer's memory will be taken and it will take that memory until the sync() command is called and it will be print on the screen.
I tested it in tier 2 and you can see that it has a big impact on the fps. First i tested it with 1 print command and print FPS. and then with 10000. The framerate dropped from about 1600 to 18.


Quote: "But in regards to that Sync() command (just in general, not just with my app), does the Sync() command know anything about what kind of loop it is in? If it doesn't, it shouldn't do anything to frame rate having more or less."

The sync() command doesn't know in what kind of loop it is, but what it does know is how much time has passed in since the last time it was called, so if it gets called more often it thinks the fps increases, but in reality you're calling the sync() command in a small loop that executes very fast. So your app doesn't run faster if you call sync() in a small loop.
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 4th Jul 2016 10:40
Quote: "I think the reason why the framerate drops if you put a print() command in a small loop is that it executes a lot of times per big loop, so ever time it gets called a bit of your computer's memory will be taken and it will take that memory until the sync() command is called and it will be print on the screen."


But my loop is only called once, the inner loop loops for as many times as it takes for it to finish, and then it is no longer running. But the framerate has still changed and will not go back up, even though this inner loop is no longer called. I can see that you call your inner loop every frame, that is a huge difference from mine, mine is only called once when I click the grid with my mouse.

This framerate problem is not an issue for me, I can just leave out the print command as I don't need it, but I am just curious as to what is causing this.

Quote: "The sync() command doesn't know in what kind of loop it is, but what it does know is how much time has passed in since the last time it was called, so if it gets called more often it thinks the fps increases, but in reality you're calling the sync() command in a small loop that executes very fast. So your app doesn't run faster if you call sync() in a small loop."


If I have a sync() command at the end of a small, fast loop, will it draw the frame and then not draw it again until the frame rate permits another sync()? So having two sync() commands in a small, fast loop would just make the frame be drawn halfway through the frame (if the extra sync() command is somewhere in the middle of the frame/code/loop) and then again at end when it reaches the second sync() command but never faster than the set desired frame rate?
13/0
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 4th Jul 2016 10:45
And having an uncapped frame rate and an extra sync() command in the middle of the code would give each sync() the "burden" of only half the code, thus each sync() command will be called twice as often.
13/0
Thestroyer
8
Years of Service
User Offline
Joined: 14th May 2016
Location:
Posted: 5th Jul 2016 07:48
Yes, sometimes even less.
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 5th Jul 2016 08:44 Edited at: 5th Jul 2016 13:21
Let me try and explain: I have a loop, and I have an inner loop that I can activate. If I activate the inner loop, it will loop several thoasands times and then stop, it will not run again unless I activate it again. If I have a print command in this inner loop, the frame rate will drop from 2000 to 140, after the inner loop has stopped running. EDIT: And there is no sync() in the inner loop.
13/0

Login to post a reply

Server time is: 2024-11-23 22:31:35
Your offset time is: 2024-11-23 22:31:35