I suddenly think Gimmick must be in that list. Though the game is not famous at all, it appears as a TAS gem and it's unique features get abused insanely well. It has a deep and complicated engine and really conduct the sense of TASing the gameplay way.I'd vote for Gimmick to stay. We honestly don't need to throw it away in favor of more Mario. There's nothing wrong with having both co-exist, except for "rules" that hardly anyone agree on in the first place.
I've made some progress on VS System, and now you can play some VS system games on NESHawk.
There is no 'insert coin' feature yet, but you can play in free play mode by setting dipswitches 1,2,3 to '1' in the NES->advanced settings tab, then reboot core.
This is a work in progress, so some games will still be incompatible, but I should be able to make rapid progress and have it pretty well finished by the next release. Right now you can play VS Super Mario Bros and several other games from the dev build.
*NOTE* Controller registers are reversed in VS System, so EMUHawk player 2 is VS System player 1, so make sure you set up player 2's controller. I might end up changing this to normal later but for accuracy right now that's how it works.
The difference is that of one settable register on hardware that is on the cart (8-bit register?), to three specific bits set and all others cleared out of 16384.
The default branch always begins from zeroed out RAM. On a case-by-case basis, "arbitrary starting RAM state" submissions can be accepted to Moons, much as we do with "game end glitch" runs. We never draw a distinction between runs based on the number of bits they flip, unless that number is 0.
My question, entirely unrelated to the setting of RAM beforehand, is why you use abilities with no result early in the run (0:24, 0:35), and why you fire one Bomb too many at around 4:08 - there's nothing in the way, you just launch an extra Bomb into the wall for no apparent reason.
Having played this game before, I had no idea it had music! How bizarre. The version I'm used to just plays a droning sound wave. If I understand correctly, music is only enabled if an uninitialized value in memory happens to be set to 1?
What are the actual values written in this run?
Right, I remember discussing this with adelikat on IRC some time ago, when he was about to add this feature, and his opinion (and mine too) is that such runs shouldn't be obsoleting the ones that don't manipulate startup RAM. Because it won't be a fair competition, after more than a whole decade of not using this in TASes.
This severe graphical bug in Recca's title screen after you beat the game (or use a debug/stage select feature to start from e.g. Area 1) still persists:
Wow, that's annoying. Any way to fix this, or to add an onlatch and onclock event to lua similar to LSNES? The amount of reads isn't the only important piece of information - knowing when the data is actually latched is very (and more) important.
1) Does event.oninputpoll poll for input any time latch happens? Or just once per frame?
2) Will it be possible to use/read/get subframe input in the future? Not important for these runs, but already shown to be important for some ACE runs that have no emulator with working native support.