Let's be more precise here: The hardware test (which are programs (like games) which test a certain functionality of the 3DS without touching most other aspects of the system) would show us how the real 3DS behaves in such situations and allow us to work on Citra to reproduce the behavior (which should produce the same result when running the hardware test).
Having the hardware test alone would not fix the issue.
In fact, a workaround for this issue is very simple and often included in unofficial builds, but we are not certain if the workaround is hiding further issues in the emulation. Therefore it would be a bad idea to include it in the official Citra or bleeding-edge.
As far as I know, we are also not certain yet if the error is caused by bugs / design of the game or problems in the emulation of the game. So if we add a workaround now that might workaround a completely different problems which affects a lot more games.
The current issue is that the game tries to show a 0x0 pixel image in a larger size (say 100x100 pixels).
So you don't have any pixels but want to produce pixels from it. Obviously this is a tricky situation..
The proper way to fix this situation is simple: Check what the hardware does in the situation which currently causes the emulation to stop, then reproduce the behaviour of the hardware in Citra:
- So if the hardware stops, Citra also stops rightfully and we should look for a problem elsewhere which caused us to end up in this situation as clearly the hardware never ended in this situation).
- If the hardware does not stop we can also reproduce that behaviour (but what color is a 0x0 pixel image? = needs research).
Even if it turns out that the hardware never actually arrives at the situation which uses a 0x0 pixel image we can safely add this behaviour as a workaround as we know that IF the hardware had seen a 0x0 image it would have behaved the way we implement it.
We'd then have to figure out where emulation and hardware diverge (which caused the 0x0 image) using more hardware tests.
The cool things about hardware tests is that you can collect all of them and run them once in a while and compare output on a real 3DS compared to output in Citra.
If any of the outputs don't match you know exactly which part of the emulator is broken (the one tested by that specific failed hardware test) as you confirmed other parts as working fine (using the other hardware tests).
You can also go back and re-test on different versions of Citra to see when exactly an error first occured.
