I’m trying to debug a crash on Android, but I can’t play my game long enough to reproduce because when the debugger lags, my character portals through walls and is unable to reach the end of the level. The game runs fine for some time, but then it hits a black screen and I have to wait ~60 seconds for my phone to become responsive again… I checked the peak memory usage and it’s approx 1.1 GB and my phone has 6 GB of memory so I don’t think it’s a memory issue. Anyone know of some way to resolve physics tunneling during debug lag issues?
A way is to do raycasts of the distance your character moves in a frame. This can solve issues caused by big dt spikes.
4 Likes
Thanks! I added code to put the player at the point of the raycast for debug if it goes through a wall and was able to play long enough to get a crash message. I’m seeing “ERROR:GRAPHICS: OpenGLClear(1097): gl error 1285” which indicates out of memory. Is there some way to increase the memory limit for the app? Do you know if the HTML5 heap size affects Android builds? Oddly enough, I checked instances with the on-screen profiler and they are remaining constant each time I enter an area. However, it seems to happen when I die on the same level and it reloads multiple times. Maybe past instances aren’t cleaned up fully before new ones are loaded. I’m not sure if there’s a way to defer collectionfactory creation until another collectionfactory is fully unloaded. EDIT: For this final question, I reworked the level unload/loading code so it now “preloads” the next level storing the info about the next level. Then when the level loaded finals, the last thing it does it message main and tell it that it’s unloaded and then the pre-load data is used to load the next level. Hopefully that will reduce memory competition during the unload/load phase.
1 Like
HTML5 heap size does not impact Android builds.
I’m not sure what to do about Android builds but it might be a setting you can set in the manifest.
It may be time to refactor your project / figure out what is using so much memory and try to reduce it.
Using an inbetween loading screen sounds like it would help, but there many be quick wins you can do if you figure out where memory is being spent. Are all of the meshes taking up unique space in memory?
I managed to reduce the issue (I didn’t see it at all at least, but not 100% sure it’s resolved) by removing the alpha channel from my off-screen buffer and constricting the view area for the game. Also with the level unload/preload/load logic included. Hopefully this will be enough to keep it stable. I’m going to rewrite the AI also to defer updates while the level is loading since they start updating right away and it seems that’s when memory is being pushed to the limit. Do you know if an opengl out of memory error is only related to video memory, or could the instance count/update logic also trigger this?
1 Like