It turns out I was not doing rotation and scaling correctly in this case, so I went back and redid that code. With a better understanding how it was supposed to work, the rewrite was more accurate and also quite a bit faster since I got rid of the floating point arithmetic. It gives a couple fps boost to games that use mode 7 stuff. Now the demo works correctly:
I'll probably go back and do the same clean up for rotation and scaling of sprites, might get a small performance boost from that too.
Now that I finally have a Metroid Zero Mission cart I will be testing that game and associated ROM hacks.
Fixing it was pretty simple, but it's possible I'll need to redo sprite rendering in the future if there are other side effects.
The next thing I'll do is fix the weird behavior involving DMA in ROM area.
I wish I could have such a strong motivation to deal with my stuff! Great work once again! I went through your repository and the console-verified GBA publications and, I guess it makes sense to clarify the things. I assume a gbmv input file recorded in an elder version of GBAHawk (say, 2.06) will playback in the latest version, so there's is no point in marking them in the repository. However, you mentioned RNG manipulations for some of the games to become verified, like you had to add some blank frames here and there to make the movie successfully play on a real GBA. Does it make sense to store these input files as well, for example, in "gbmv files verified" folder? Even if this final step of input adjustment has to be done for each verifying device independently, this at least will give verifiers the right whereabouts where to add or remove blank frames.
In scope of TAS movies provision to test emulation accuracy, I'd like to provide two movies (following previously posted Duke Nukem Advance movie): - Serious Sam Advance: User movie #638512881522132559 - Doom: User movie #638513118358303271 Speaking of Doom. For some reason, GBAHawk doesn't make an in-game save. I don't know if I should create an issue on GitHub or maybe I missed some warning on this regard, but since battery-backed saves were mentioned in previous verifications, I think that means the emulator must be capable of doing saves. For comparison, here is my BizHawk 2.6.1 TAS, where game is being saved just fine: User movie #74380673068812668
So I noticed there's some audio mixing issues that I first noticed for games like https://tasvideos.org/9040S in GBAHawk. In the first level's track, there's a guitar like instrument that comes in (might be a different instrument idk what it would be) that is mixed pretty quietly in comparison to the console footage in that submission. I make a video highlighting the differences using mGBA as a comparison: Link to video In the TAS itself, this part of the track kicks in at around 1:06.
Wow, not sure how you were able to notice that
Hey look buddy, I'm an engineer. That means I solve problems. Not problems like "What is software," because that would fall within the purview of your conundrums of philosophy. I solve practical problems. For instance, how am I gonna stop some high-wattage thread-ripping monster of a CPU dead in its tracks? The answer: use code. And if that don't work? Use more code.
I'm not a fan of how you've forked the BizHawk repo—or to be more precise, how you did not. It makes it much harder to track differences and share fixes, and it turned what could have been a simple task of building GBAHawk with Nix into an hours-long slog. (Final result here.) And was deleting every OSTailoredCode.IsUnixHost check really necessary?
0801431A: 4778 Bx (R15)
0801431E: 00000000 (fail) AND (no flags) R00, R00, (R00 << 00)