![]() On the jerky laptop, it dramatically improved the situation, but I suspect that the calls to update_basic (i.e. On my speedy desktop, this locks the game to 60 fps absolutely on even my worst maps (which is dramatically better than before). # Now do one more update, since it's time and return And I mean everything, even Microsoft Paint couldn't run well while it was doing that download.īTW, I think this belongs in learning Ruby actually, as you will need to explore the code. Seems Windows was downloading an update to the HD and that was affecting everything on my computer. A few hours later I got a notice that my computer was ready to update. I had an instance where I dropped all the way to 2 FPS on ACE and did a CTRL+ALT+DEL and found that something was using 99% of my HD (and not the game). Since I couldn't control the playtime I hardcoded my step counter to 9,703 or something like that, as for some reason forcing it to stay 0 also caused the game to get choppy? Maybe there is something in the dll that tries to stop it from having 0 steps or something?Ģ) Windows Update, though any other automatic update program will count. My game started to get choppy when the step counter got over 30,000 or so and my playtime was over 10 hours. Using ACE as I have, I have found a few things which affect frame rates:ġ) The step counter. It's not clear I can _do_ anything about it (if it's in the maker dll) but at least knowing where the problem is would save me a bunch of time writing ever more sophisticated profilers And, if I know where the issue is, there's always the possibility I could come up with some esoteric workaround. So, given that the CPU isn't utilized and I haven't discovered some occasional expensive operation, I'm wondering if something in the frame limiting code is working incorrectly on that laptop. I've written a per-frame profiler to try and see if there's expensive work being done on some frames, but it doesn't seem like there's a smoking gun there (not surprising since most of the VX Ace code base just does brute force updating of all game state on every frame. ![]() Looking at the CPU utilization, even on the hitchy laptop, shows no core on the machine ever getting above 15 or 20% usage. Even on my relatively powerful desktop, there will pretty consistently be frame hitches. I've noticed that a completely unmodified default project (in that empty initial level) has incredibly choppy framerates on certain laptops (like on a version of the MS Surface I have). Does anyone know where the sleep is happening that ensures the game's frame rate is limited? The docs under help talk a little bit about frame limiting in the Graphics module section, so my working hypothesis is that perhaps Graphics.update is doing that sleep internally and won't return until the right amount of time has passed? But, I can't verify that because that module is in the compiled dll, I believe. In order to restrict the game to 60 fps, somebody needs to be doing a sleep before that update method returns. Inside that update() call, we just call Graphics.update, Input.update and update_all_windows in sequence then return.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |