MovingBlocks
Rapid collisions cause massive amounts of lag.
What you were trying to do: Play the dang game
What actually happened: Huge amounts of lag caused by collisions
How to reproduce: This format doesn't seem very good for this issue, let me just
Issue: Repeated collisions are incredibly taxing on the cpu, causing drops to FPS values better measured in SPF
- Follow around a shop ship until it gets to a planet
- Wait for it to get stuck in some corner somewhere (should only take a few seconds, maybe fix that too)
- Try to do anything and notice it takes orders of magnitude longer because of the lag
Alternatively:
- Be a large ship
- Go to a mine and find a small gap
- Get stuck
- Watch the fireworks as your CPU explodes
Log details and game version: V2.0.0, Android. No crash log because no crash.
Computer details: Android, LGK20
I can reproduce this. Whenever this happens, I get a flood of sound-related error messages in the logcat.
2023-03-20 20:16:06.646 27642-27685 AudioTrack com.miloshpetrov.sol2.android W AUDIO_OUTPUT_FLAG_FAST denied by client; transfer 4, track 44143 Hz, output 48000 Hz
2023-03-20 20:16:07.060 27642-27685 AudioTrack com.miloshpetrov.sol2.android W AUDIO_OUTPUT_FLAG_FAST denied by client; transfer 4, track 44911 Hz, output 48000 Hz
2023-03-20 20:16:07.073 27642-27685 AudioTrack com.miloshpetrov.sol2.android W AUDIO_OUTPUT_FLAG_FAST denied by client; transfer 4, track 43552 Hz, output 48000 Hz
2023-03-20 20:16:07.074 27642-27685 AudioTrack com.miloshpetrov.sol2.android E AudioFlinger could not create track, status: -12
2023-03-20 20:16:07.074 27642-27685 SoundPool com.miloshpetrov.sol2.android E Error creating AudioTrack
Commenting-out the code the plays collision sounds appears to fix the issue, although I've only tested this lightly so-far. https://github.com/MovingBlocks/DestinationSol/blob/fa2a67e059b8bbd6d7a25836d04d999ffb0b860b/engine/src/main/java/org/destinationsol/game/SolContactListener.java#L128-L129
A proper fix for this would probably involve deferring collision sound playback to outside of the collision handler. Re-sampling all the sound effects to 48000Hz might possibly help too but is a bit of a drastic measure.
Perhaps you could change the sound handler or something, make it rate limit the number of sounds that can play at once?
Perhaps you could change the sound handler or something, make it rate limit the number of sounds that can play at once?
That's a good idea and would probably have helped but I discovered something else whilst looking into this.
It turns-out that playing sound effects blocks the current thread. It looks like this is actually a symptom of a very well known issue with the libGDX framework that we're using. The suggested fix is to use the asynchronous audio back-end instead, which does appear to fix this issue for me. I've added the fix.
Actually, I'll leave this issue open for a bit longer just to make sure that I really can't reproduce it anymore after those fixes.
I've been testing this again and I'm pretty confident that the issue is fixed, so I'll actually close it this time.