Optimized Game Timer Loop Update #2
Ok, so I spent the weekend (well the free-time part anyway), looking at the timer and found that in its current form it works best at 30FPS across all platforms. With updateAfterEvent turned on, you might still run the risk of an older computer with a new FP10 plugin not working (in the future), but so far this configuration works fine on all systems I tested,
I am not content though, so for now, if you are using the Sleep Based Active Render Game Loop Timer with a frame rate above 30, then I suggest turning off the updateAfterEvent and replacing it with stage.invalidate(). This doesn’t seem to have the exact same smoothing reaction as updateAfterEvent, and it might just be a placebo, but it makes me feel better to have something it its place for for now.
Also, it is best (like I said up above) to try to keep the FPS at 30 with or without the updateAfterEvent turned on.
Now, I did work on 6 different timers in an attempt to profile a game while running and reset the frame rate and or turn off UpdateAfterEvent dynamically. It actually worked, but while the game played the FPS would continue to drop to the minimum I set no matter what I tried. This is because it never knew exactly when the game-play started or how long to continue profiling before it was satisfied. It just began profiling as soon as the application started (even on the menu screens). I keep my render loop and my game code decoupled and to continue to do this, I didn’t want them to know too much about the state of the other. I added code to wait a specified number of frames and then lock in the current frame rate. This seemed to work if the player started the game up right away, but if the player sat on the title screen for too long of a time, then the render profiler would assume the game was fine and when the player got to the game it would not profile any more. Yes, I *could* have hard-coded it to start when the game play started. I began to do this, but stopped when I realized that if I added in a processor intensive menu screen or opening animation, the game might freeze before the profiling even began.
So, I will be modifying the timer to add in a game independent profiler that will start as the game begins (before menus and intros, etc) and use the first few seconds to profile the system off screen and choose an appropriate frame rate. If the frame rate is lower than my selected minimum, then I will turn off the updateAfterEvent. This complete version will be in the book if it works. I will also post a tutorial here on how to use it properly.
For now though, I am going to stick with the 30FPS max and the updateAfterEvent turned on until I have a working dynamic profiler.
******* Contents os Original Post
About a year and a half ago I posted a tutorial on using an optimized sleep-based game timer loop that included a time slice active renderer. The idea came from the great book, Killer Game Programming in Java, and the AS3 version was perfected by my good friend Chris Cutler and I. Soon after posting this tutorial, I began to get some reports of isolated incidents of it not working properly with the “updateAfterEvent” turned on for the Timer instance. This was isolated to just the Mac Flash CS2 IDE and was mitigated by lowering the frame rate down to 40FPS, so I shrugged it off.
Lately though, I have had to turn the updateAfterEvent off for more and more plug-in variations and now it even affects some games in XP and Windows 7. Those games need to be really pushing the limit of the Flash player to exhibit a problem, but since those are the types of games I like to make, and since the book we are writing focuses a lot of attention on this timer, I have decided to work on a patch this weekend.
I can’t guarantee that is will be completely stable by Sunday, but it is affecting the book deadline so it will need to be fixed fast. Anyone who has seen the silky smooth screen updates using the active renderer with “updateAfterEvent” turned on, and then had to experience it without will appreciate what I am going to attempt to do.
My plan is to have the render loop profile its own attributes (while running the game) to auto discover when it is causing a problem in a player. When it does, it will either automatically turn off the “updateAfterEvent” or it will go further and attempt to realign the frame rate to one that is more compatible with the platform it is running on.
I hope this works…