That is awesome, though I'm not on Windows, but if the code is on Github I will do a git pull and recompile uzem to get the newest changes and then I'll record a bunch of input captures.uze6666 wrote:Do you have array manipulation or pointer code that could overflow? Array out of bound could be a possibility for the garbage you saw. Since we are pretty much in the dark with this method of investigation, I implemented a controller capture mode in uzem. This allow to debug on uzem with GDB. Are you on Windows? If so:
To capture input:This will write to a file named yourgame.cap. Try replicate the sustained note issue and send me both your .hex and .cap files.Code: Select all
uzem -c YOURGAME.HEX
To replay a capture file:. The capture file with the same name (yourgame.cap) must be in the same folder.Code: Select all
uzem -l YOURGAME.HEX
Attached is uzem 1.31. an me playing ghosty ghost.Code: Select all
uzem -l GGHOST.HEX
Further investigation shows that even with no calls to TriggerFx, or InitMusicPlayer, the patchCurrDeltaTime variables are still incremented. Does that mean that the code that plays sounds is running regardless of using it or not? I tried getting rid of all my sound code to see if the glitches still happen, but it doesn't appear that I can stop the sound code from running. Sometimes I get weird graphical glitches, like the player 1 and 2 sprite drawing all over the place, but the stack looks good, and the actual x and y variables for player 1 and player 2 are correct. It's almost as if it's drawing sprites that aren't defined. If I make it so only a single player is defined, then I can't seem to reproduce the graphical glitches. The exact same code is running for both players, the only difference is I'm more likely to go over on cycles when I'm doing physics and collision detection on two players versus one.
I've looked and looked for any place where I could be writing out of bounds, but most of my loops have constant terminations, and I'm not doing anything too clever.