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.
