- [solved] latest runme crash with stack=0 when loading the title screen
- runme triggers a crash of desmume-cli, version 0.9.11 when --cflash-path is used to grant access to data items
- same runme can be launched when no --cflash-path is provided
- same runme works fine when emulated on old desmume (0.9.6, 32-bit, running on old laptop), even with --cflash-path
- same runme crashes when emulated on old desmume (0.9.6) rebuilt on 64-bit system, with --cflash-path
- SchoolTest can read the title screen, but suffers the same "stuck-on-the-title-screen" bug as observed on the Androïd emulator
- desmume 0.9.11 apparently doesn't emulate bad address / invalid instruction. That's not going to help.
Si les tests automatiques avaient plutôt bien supporté le passage d'un vieux devkitpro à un plus récent, les outils du type "runMe" et le test du jeu s'en sortent moins bien. Il n'y aura probablement pas de "release Noël" de School Rush ...
Second priority will be to figure out whether the "latest devkitpro/libnds-1.5.12" team still properly support the "register exception handler" feature.
Finally, I'll have to try freshly compiled SchoolTest against my old desmume, just to check where the regression is.
sp = 0 crash is there because some code in GameScript::parseline[case 's'] decided to save sp's value at [sp+0] rather than in a register (as with "g++ 4.5.1"). that's already a bit odd: 'mov r3, r7' (with r7 playing the role of the stackframe base address) could have worked instead of 'ld r3, [r7,0]'. More odd is the fact that for some reason, the value in [sp+0] got trashed and no longer contains sp, but 0. Oddest is that it all happened when almost no code is run (just a call to siscanf), and never occur when there's a .spr file to load...
ReplyDeletecould be worth investigating with the emulator if I ever manage to reproduce the issue.
Issue happens when requesting an animation that is missing in the .spr file and parsing further (i.e. trying to create a state based on that animation).