Ok, I am getting a spike in the heap snapshots that says “[array]”, but I have no idea what it is. The rest of my spikes are less then 5% of the load, so whatever playcanvas is doing on this is the cause of the spike.
I’ve tried several changes to my code and nothing seems to be improving or changing the reallocation of whatever playcanvas is moving around in memory. I doubt it’s a leak in playcanvas, but I’ve burned more time then I care to spend trying to fix that “random drop in framerate”.
I simply don’t understand enough about the memory use of pc or [array].gc to understand why it’s being flushed and apparently leaking? I did a little bit of digging using chrome debugger and a heap snapshot, and found it’s always something in [array] that’s being flushed and created again. The only time I actually destroy any array in my game, to my knowledge, would be loading and .destroy() on the level objects between the title and the track. But the spike and flushing seems to happen even if the track is left running and simply paused between snapshots.
I also tested a completely blank new scene, and there isn’t this flushing error(the heap stays flat the whole time the page is open). So it’s something I have or am using in the scene/game I made that seems to be causing the garbage flush.
I don’t have the time to figure this out, and according to the debug info all my own code and objects are only filling the garbage collector with 5% of the total garbage being cleaned up. So I don’t think this is going to do much performance-wise, even if I could track it down. (I’m new to the debugger and quickly found out that playcanvas engine is very confusing to fish through using the debugging tools, and I don’t know what I’m really doing or looking for anyway.)
I’d rather spend the rest of the contest time working on polish and two other track layouts, so for now I’m moving on to get those done.
I just figured I would mention this in case someone could tell me more info about what is expected here. That frame drop issue has come up multiple times now, and I don’t even know where to start since I’m completely new to the chrome debugging tools.
(Before you send me links to the google guides, I’ve read them already completely, and still barely understand what they are saying or what to do with the data I get from the windows. I have no idea if what I’m observing has anything to do with the frame freeze at my level of knowledge. Perhaps this is all normal and I’m tracking useless info, I wouldn’t know either way.)
Edit: An additional way of optimizing the game came to mind, but I do not know if Playcanvas gives me access or a control for it. Is there a way to change the “framerate” of the physics or rendering engine’s updates? Or is it stuck at the same rate it is at?
I was thinking on slower devices I could run the frame renderer slower to allow the device to catch up with the physics. What happens now is that the robot gets “pushed” more then the physics rendering can keep up with, resulting in a much faster push. It’s hard to describe, but basically he ends up teleport pushing as the physics engine + my time code try to keep up with the low framerate and large changes to the setup. This causes him to slip through checkpoints and triggers, gain way more speed then he is supposed to be getting, among other odd results.
If I had an override for the frame rendering, I could force the game to drop frames to allow the physics processing if the frame time is below a certain thresh hold to make up for this. Sadly a quick search seems to say playcanvas doesn’t have such a setting and just runs at whatever rate it’s got for the window. Is this info wrong now, or is there still no way to have reliable physics results?