Is it okay if you could provide extra input for the credits stage? It's kind of silly for a TAS for the credits to run while the player does nothing but fall into the abyss multiple times.
Saved another 0.72 seconds (primary-submitted replay file for this submission) using the information TAStudio provided, and that truly appears to be the best possible with this set of solutions. (But I still find it a bit of an inconvenient way to do this; a log file would be much better. And then at first I thought, after seeing what TAStudio could do, that it explained how you did this: But it appears that TAStudio loses the ability to do that magic when the GBHawk core is in use, and the replay file you posted was based on the GBHawk one. So how did you do that?
Wait, what? How are you interpreting that graph in that way? It shows 4 frames in a row that are all the same color, against a gray* background. Can you actually tell just by looking at it that it accepts input on the 2nd? Why not the 1st? *I guess it's grayish cyan, using a color-picker, but to my protanomalously colorblind eyes it looks gray. That's not the problem though, as all 4 frames in a row from 1313 to 1316 are the same green (I had to check, to make sure there wasn't just some color difference I wasn't seeing)
Here is the first move in level 1-2, you can see the 'left' button is pressed on the fourth (green) input frame but input is accepted on the second:
These post-submission improvements have all been incorporated into this BizHawk 2.9.1 (Gambatte core) replay file, along with fully optimizing its UI delays. This is now meant to be the primary file associated with this submission, so please ignore the "15:27.21" one and use this 15:13.34 one instead when judging the submission.
How are you writing the replay in the same clean export format as I've been using, which only holds the joypad button for 1 frame exactly when it's needed?
So anyway, yeah, this means I'm going to have to re-solve all the levels that involve filling holes. Wow.
Hello, I'm new and having problems recording longer TAS projects, so I have two questions. Is it normal for Bizhawk / TAStudio to start lagging when recording over 100,000 frames / 5 hours? And is it possible two TASPROJ. / BK2 from the same game and divided into sections to be put together via the input log? Sorry for my English - I use a translator.
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.
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.