This also happened to me, i have absolutely no clue why this could happen

This is also happening with me. it has been reset twice in one day without any warning. please fix it

Hi this is randomly happening to me also but in minish cap, started happening after second elemental was obtained.

I also have had the same resetting issue with the latest version at time of commenting, 0.8.1 QT-version on different computers running different OSes (Windows and Linux (Ubuntu)). It seems to happen even earlier for me since I had several resets in different zones of the beginning Stardust fields. As I walked across and played in these zones, various slowdowns and sprite flickering indicated issues even before the crashes and resets too.

I never had this issue on any other GBA emulators I have used over the years like VBA-M. I also wondered if this issue is also related to the sprite flickering that is obvious in the first scene (welcome of fake queen bean) of a new game regardless of graphic options selected.

After understanding what type of project mGBA is and finding out that lots of time has gone in to trying to make it the best and most complete gba emulator to date, I wanted to provide a reproducible way to generate the crash. In doing so I learned more about the way it resets and something weird about mGBA save states.

One particular place the game crashes / resets the most is when you are on the the stardust field first ever jumping yellow platforms. As you jump on the stairs leading to the yellow platforms you will find the flickering start to happen and once you get on the yellow platforms and hop left and right you will see major flickering and definite slowdowns. Hop enough times moving left and right without getting off and the game should reset. On reset you may see that the passport pictures of Mario and Luigi of the normal save file are corrupted before hitting play.

Things get stranger when you use save states while on the flickering yellow platforms. When you do, flickering will still occur, but if you perform more hops before a crash occurs and reload that same save state without resetting the emulation, flickering with the potential for crashing will still be there. If you reset the emulation (Ctr-R) and go straight to loading the same state, the flickering, slowdowns, and crashes (as far as I've tested) will no longer be there.

One way to create a constant reproducible error is to use that yellow platform save state, exit the zone to left, re-enter the zone, and walk to the yellow platforms. Alternatively create a save state just before entering the zone with the yellow platforms.

Looking back at all these details, I wondered if this issue had nothing to do with the emulation core and more with Qt integration so I tried with the the SDL-version and the same savestate with the game still crashing. I will probably test more things out and post more comments, but let me know if I should post screenshots, video, save files / save-states, or any other information.

After various more testing, flickering, slowdowns, and potentially/hopefully crashes stop when Game Overrides -> Autodetect is unchecked and Gameboy Player features is also unchecked. Not sure why "Saving" those settings are not remembered between mGBA sessions but if remembered the game performs more like on VBA-M in multiple areas.

This is an unfortunate setting to have to uncheck since the rumble feature of the game would be cool to have for more "immersive" plays and something unique to this emulator. I might look through the code and create debug modes to try and determine what lines the game is tripping up on...but I already foresee that to take many more hours for setup and understanding Gameboy Player specifics.

The game is flickery on Game Boy Player hardware, too. VBA is also known to have emulation problems with this game: http://tasvideos.org/GameResources/GBx/MarioAndLuigiSuperstarSaga.html#ActionCommandGlitch

The resets seem to happen during screen transitions. Disabling autodetect and Game Boy Player features did not fix the resets for me.

Any chance that you could enable rewind, rewind to the beginning of a transition before it resets and send a savestate?

Any chance that you could enable rewind, rewind to the beginning of a transition before it resets and send a savestate?

Have enabled rewind. Will savestate if the reset happens again.

@endrift Rewinding the emulator let me undo the restart, but exiting the area again post-rewind didn't reproduce the reset.

Try rewinding to the beginning of the transition, not before the transition

Are these problems unique to the PC version? I tried playing my own dumped PAL copy on my Wii and started a new game. I played for over 40 minutes and did not catch a single issue; no resets or graphical glitches.

I've been using a nightly version from the 13th of October 2021.

The game is flickery on Game Boy Player hardware, too. VBA is also known to have emulation problems with this game: http://tasvideos.org/GameResources/GBx/MarioAndLuigiSuperstarSaga.html#ActionCommandGlitch

I think there might be something emulation related to it. On the standalone emulator on Switch, the game is not flickering for me, but on Retroarch (newest core, Switch), it flickers when there are too many sprites on screen (opening scene is a good example), and when new speech bubbles are displayed.

I got the flickering + random restarts thing on SuperStar Saga on the latest stable/development version of mgba.
I think that disabling the GameBoy Player indeed helps.
Tried without using a BIOS here.

Using a BIOS fixed the issue it seems.
So you have to use a BIOS if you don't want to get random restarts (doesnt help with the flickering though).

There appears to be a bug in the GBP-specific code that has it return to the BIOS improperly when doing some stuff with interrupts, somewhere around 0x801AA00. It's hard to tell exactly what's going on, but the end result is that it gets flung into IRQ handler with invalid values in the mGBA custom BIOS, which can cause it to jump to invalid areas of the BIOS. This gets weird and eventually the game resets, it seems. The function is called often so it's hard to tell exactly when it goes wrong before it actually goes wrong. I'm working on a "fix" but I'm not sure it'll always work; all I did was shift around some registers that were getting clobbered. Further, the code that was being invoked has changed dramatically since this issue was filed, so I'm unsure it's the same root cause. But we'll see.