TASing has always been about overcoming human limitations, and show what it would be like if a perfect superhuman were to play the game to its absolute perfection. And Ocarina of Time any% would be the absolutely perfect place for this. When did this change?
The OoT topic on the forum here has been dead for a long time.
Action 52 is broken as of a few versions ago it appears. Still broken in the latest dev build. It launches into one of the minigames and you can't make it to the main menu. This is in NESHawk and QuickNES doesn't support it.
Good job! Are you doing anything in particular to track horizontal position or speed?
What is the significance of this category? Why no doors? All the categories are made up, and the doors only matter because we will them to.
One further question - for the purposes of the oninputpoll event, what counts as an Atari input? Is it just controller inputs, or also system inputs (reset, difficulty select, etc)? Going through the code I see far more direct calls to just the button and the system inputs than there are polls occuring per frame.
To clarify, I don't think sub-frame is necessary for improving the current TAS, but may be necessary for true optimality later on. I believe Alyosha mentioned he could produce a 32.61, so that's at least an improvement. Sub-frame would be nice, but I understand the difficulty in making that happen from an emulator development perspective. At least, a better understanding of the system would make it possible to reason a theoretical limit, assuming sub-frame inputs were possible.
Isn't that what these forums are for? Although I'd agree that the workbench gets way more coverage. I can think of at least one game where an author was told in those forums not to do X, and he did it anyway, and then his run got rejected for precisely that reason...
I just don't want someone to work on something which they may feel is wasted effort. If they want to know if their particular case does not fall into the near-blanket-ban, they can ask, and explain why they feel like their particular case may be different before embarking on a potentially lengthy creation process.
The problem with SMB PAL is that neither superiority nor diversity can be formalized for it. "One time exceptions", as moozooh pointed out, should either be legalized or not happen at all. My goal is to make the PAL ruling fully transparent, with no surprises. If we have to make an exception every now and then, the ruling is sloppy.
In the scenario we're discussing (games which have technical differences but have a very similar look and feel) I think acceptance and obsoletion end up being the same. Since introducing another branch would create unwanted redundancies, the only way it gets accepted is by obsoleting the existing movie (if any). And as mentioned before, I only consider that specific branch, not the game in general (other branches may have different outcomes).
Mmh, right. Did you test the speed with a function pointer (or a variable tested in a switch) that is set when timer_control is changed?
@Alyosha It sounds best at 1 (NESHawks default Audio Level) So I was wrong about raising the audio level. I have a question, is it possible to force the NESHawk audio to play at a Higher Quality with a Sample rate of 44100 Hz like how the Sega Emulator Kega Fusion 3.64 does it? Thank You for your time.
It doesn't matter if they have the same bits set or not since we're testing for zero/nonzero.
(state & state_c) == 0Audience support alone doesn't prove anything, if it can't be formalized in some statement, that is then put as a reason to accept a PAL submission. And to come up with such statement, we impose factors we want to get evaluated. To me the new question is... How many people think we should not change the movie rules, nor clarify them?