Re: DT in BGT
It appears that tick() was called approximately 43 times in a one-second period, but there are differences in the amount of time between iteration. For example:
Tick called. Elapsed real time is 0 seconds.
Tick called. Elapsed real time is 0.046 seconds.
Then, it almost immediately gets called again:
Tick called. Elapsed real time is 0.054 seconds.
But the next iteration doesn't happen until 0.092. Then 0.101, 0.139, 0.148. The pattern appears to be one call at longer intervals, followed by a very close call after, then a longer time, then a call close: So after 0.148, the longer call at 0.185, then the close at 0.195, then the longer time at 0.231, then close at 245, then long at 277...not sure what this means. Keep in mind that for purposes of this test, I am doing nothing but sitting. No player movement, no movement of the ball. I removed the wait(5). The pattern still appears to hold with tick calls:
Tick called. Elapsed real time is 0 seconds.
Tick called. Elapsed real time is 0.042 seconds.
Tick called. Elapsed real time is 0.046 seconds.
Tick called. Elapsed real time is 0.084 seconds.
Tick called. Elapsed real time is 0.086 seconds.
Tick called. Elapsed real time is 0.124 seconds.
Tick called. Elapsed real time is 0.127 seconds.
Tick called. Elapsed real time is 0.166 seconds.
As you can see, one longer iteration, then a very short one, then a longer one. Next, I added the wait(1000) prior to restarting the timers. I set frame rate to 60. This means that after each 0.016 seconds, a frame should pass. That means that at 0.096 seconds, six frames should have passed. Log shows:
Tick called. Elapsed real time is 0 seconds. Number of frames is 0.
Tick called. Elapsed real time is 0.034 seconds. Number of frames is 1.
Tick called. Elapsed real time is 0.038 seconds. Number of frames is 2.
Tick called. Elapsed real time is 0.068 seconds. Number of frames is 3.
Tick called. Elapsed real time is 0.072 seconds. Number of frames is 4.
Tick called. Elapsed real time is 0.103 seconds. Number of frames is 5.
The pattern still appears to hold. Not sure why the calls to tick aren't more uniform, instead it gets called back to back virtually, then waits, then back to back, then waits. So far, loss of one frame at 0.1 seconds. Log at the bottom shows:
Amount of real time that has passed is 10.003seconds. DT is 0.016666666666666. Number of frames that have passed is 590. So, it appears that I lose one frame every second. What I don't understand is why the tick method basically gets called that way instead of uniformly across the board. Is there a way to improve that? And why now all of a sudden is this appearing to work correctly? Even if there was initial lag after the sounds, wouldn't the first 10 seconds have shown that, say 50 FPS instead of 60, but then the next ten seconds would have shown correctly, since the lag should have been gone by then? In other words, I can see the first ten seconds being affected by the lag, but after the sounds are loaded, the lag goes away and everything after should work correctly, right? Besides, how the hell would loading sounds eat that much of 16 GB of ram that it lags to the point that you lose that much performance? And after sounds are loaded, why doesn't lag go away after the first ten seconds? It seems like Philip really, really must have screwed something up when he made BGT, or Windows has got some serious, serious issues. NOTE: Retesting shows the following:
Amount of real time that has passed is 10.003seconds. DT is 0.016666666666666. Number of frames that have passed is 604.
Amount of real time that has passed is 10.005seconds. DT is 0.016666666666666. Number of frames that have passed is 608.
Amount of real time that has passed is 10.009seconds. DT is 0.016666666666666. Number of frames that have passed is 608.
How I'm getting extra frames I don't know. Is there a way to prevent that? Extra frames could be an issue across machines. Could cause the initial problem I had, ball landing differently on different cords. Really don't want that. NOTE 2: This has also changed my profile results. StartMatch now went down considerably. Not sure why that is, since I actually added a wait there, but look:
Total execution time: 53671 ms
Number of functions called: 9
void clock::tick(): 50275 ms (93.67%)
void StartMatch(bool = true): 1482 ms (2.76%)
int dynamic_menu::run_extended(string, bool, int, bool): 1033 ms (1.92%)
void main(): 863 ms (1.61%)
bool logger::write(string, bool): 6 ms (0.01%)
void MainMenu(): 5 ms (0.01%)
void CheckEvents(): 3 ms (0.01%)
void Voice::speak(string): 2 ms (0%)
I don't understand that. I would have thought the wait call would have lengthened StartMatch. NOTE 3: What, the, fuck? So this time I decided to see what would happen in terms of frame rate if I just walked my player back and forth on the court. Frame rate dropped a little, to 590. But there's the question. Looking at my profile, I see:
Total execution time: 58413 ms
Number of functions called: 11
void clock::tick(): 39733 ms (68.02%)
int dynamic_menu::run_extended(string, bool, int, bool): 14689 ms (25.15%)
The fuck? What does moving my player have to do with the dynamic menu? I do not call dynamic menu when I move. When I don't move, profile looks like this:
Total execution time: 53878 ms
Number of functions called: 8
void clock::tick(): 50429 ms (93.6%)
void StartMatch(bool = true): 1480 ms (2.75%)
int dynamic_menu::run_extended(string, bool, int, bool): 1172 ms (2.18%)
So what the fuck?
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
