I'm starting to see more and more submissions corrupting a save file by resetting the game while its writing. The primary problem with this is: how accurate is the emulator on resetting the game while its writing? On a real console, when you hit reset, does it happen right on a frame? Could you corrupt saves in between frames to get more optimal results? Do writes happen in batch, could a byte or int get partly written?
If we allow save corruption shouldn't we allow sub-frame resets?
Edit:
I'm asking if there would be any advantage to allowing input between frames. If a program checks the input register more than once per frame, couldn't you theoretically change your input part way though to trigger a logic failure?
I'm asking if there would be any advantage to allowing input between frames. If a program checks the input register more than once per frame, couldn't you theoretically change your input part way though to trigger a logic failure?
Input in between frames doesnt matter, the game wont pull or use it, the only case its usefull is for reset ... just check inichi works, from what i remember with debug version (allow reset in between frames) he could finish in 3 min or so, and probably, could finish directly the game after the intro if he had more precise control over it.
Unless you have a save glitch to exploit with reset, it is probably no use to have input in between frames.
I have a video Inichi made where he finished Chronotrigger in 3:24 by glitching to the "room" where the credits roll for the ending with the frog and Mu creatures, yeah.
It seems to me that any game that allows saving would be vulnerable to partial save corruption if we allowed resetting between frames. Currently only games that take at least two frames to save can be attacked this way and it's probably not useful for many of them because of the limited attack window.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Input in between frames doesnt matter, the game wont pull or use it
Do you mean that it's physically impossible for games to read controller input more than once per frame (eg. because the hardware updates the button flags only once per frame)? Or do you mean that there exist no console games which read controller input more often than once per frame (and behaves differently if it changes between frames)?
(Wouldn't this also depend on which console we are talking about?)
Looking at this document: http://www.romhacking.net/docs/%5B196%5Dregs.txt it seems like a program can read from the controllers whenever it wants, but that the usual way of doing it is to use the auto joypad read service, which polls the joypads once per frame (I think) when enabled.
So it seems like you could conceivably have games which would benefit from sub-frame input. We could ask byuu to be sure, I guess.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Right now the input files we use record input on video frames which is in fact wrong.
We should be recording input on input frames, which could be equal to video frames, less often, more often, or variable.
It's especially silly recording input every video frame when you realize that most games with unskippable cut scenes don't poll input at all during them.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
This raises the question of whether more could be achieved (in terms of speedrunning) in a real console than on an emulator because current emulators only sync input keys with video frames (while the real consoles might do it slightly differently).
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
This raises the question of whether more could be achieved (in terms of speedrunning) in a real console
Probably.
Warp wrote:
than on an emulator because current emulators only sync input keys with video frames (while the real consoles might do it slightly differently).
Several current emulators do poll for input on input frames. The one which is most notable is probably bsnes. Although in the case of bsnes, since it uses so much resources, it's not unlikely for the OS to skip some polls it requests since it's using too much as is on not so beefy machines.
Although that's a moot point if we had frame by frame advance for input frames, OS scheduling wouldn't come into play.
I think Nestopia works with input frames as well, which I'm still not sure why we're not using.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Nach wrote:
I think Nestopia works with input frames as well, which I'm still not sure why we're not using.
Because it doesn't have a reliable method of AVI dumping.
This is both from recollection and the fact that I just searched for an AVI dumping option inside of it.
I think Nestopia works with input frames as well, which I'm still not sure why we're not using.
At least on the NES this method won't provide maximum flexibility. Due to a hardware bug, many NES games that use the DPCM channel read the controller ports multiple times until the same value is returned twice.
If one could alternate input fast enough he could force the game's main thread to stall for as long as is desired, making the game lag when it should not, possibly causing weird glitches.
Also, I'd imagine you could pull off some already known NMI-related glitches more reliably this way, e.g. in Mega Man 2, although that game does not use DPCM and thus may not read the controller multiple times.
Sorry if I'm a little late on this topic, but I didn't see this mentioned anywhere else.
Dragon Warrior 1 reads player input in a small endless loop (86-87 times per frame) when paused on the map, and randomizes on each read, so midframe input would allow better luck manipulation.
I haven't noticed any such case (or even checked) in other games, but that's still one more use for it ...
Assuming input is polled for at a finite number of times, you could just have a list of inputs as per normal, only it would read a line from the file once per input polling not once per frame.
Assuming input is polled for at a finite number of times, you could just have a list of inputs as per normal, only it would read a line from the file once per input polling not once per frame.
It would probably conserve a lot of space if only input changes were stored in the movie file rather than the input for each individual poll. (In other words, "this key is pressed/released for the next x polls" instead of having the input x times repeated in the file).
FCM has been bashed repeatedly for that feature due to hardships it incurs in hex-editing. Though if this feature is to be used on per-game basis, we could have a variation of FCM with precise instruction id support as an output option for that purpose in particular.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
I would like to revive this thread because of recent progress in console verification.
Basically I see 2 types of input:
- Passive: the input is ignored unless it is done at the exact moment the hardware attempts to read it. Examples includes buttons on NES controllers and turned-on microphones.
- Active: the input causes an interrupt or changes the overall state of the hardware. Examples include hard resets, disc swapping and connecting/disconnecting a USB controller.
Thanks to console verification bots, it has been proven that even in cases of passive input, such input can be read multiple times per frame, preventing potentially useful scenarios to TASers. They are also easily detectable and can prevent desyncs. In my opinion, this is how all emulators used for TASing should read and record passive input as well.
Active input is a bit more complex since emulators aren't perfect simulators. On this regard, I believe input should be allowed at the precision the emulator guarantees proper emulation of a given set of operations. For these moments, emulators should be able in theory to allow inserting breakpoints in the emulation process (not just CPU-bound operations) and insert active input immediately after a break occurs.
By adding such features in emulators, it would then be possible for example to extend the left+right concept to even more varied directional inputs and corrupt save data through hard reset at the exact block required to perform a specific trick.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
SmashManiac wrote:
I would like to revive this thread because of recent progress in console verification.
Basically I see 2 types of input:
- Passive: the input is ignored unless it is done at the exact moment the hardware attempts to read it. Examples includes buttons on NES controllers and turned-on microphones.
- Active: the input causes an interrupt or changes the overall state of the hardware. Examples include hard resets, disc swapping and connecting/disconnecting a USB controller.
Thanks to console verification bots, it has been proven that even in cases of passive input, such input can be read multiple times per frame, preventing potentially useful scenarios to TASers. They are also easily detectable and can prevent desyncs. In my opinion, this is how all emulators used for TASing should read and record passive input as well.
Active input is a bit more complex since emulators aren't perfect simulators. On this regard, I believe input should be allowed at the precision the emulator guarantees proper emulation of a given set of operations. For these moments, emulators should be able in theory to allow inserting breakpoints in the emulation process (not just CPU-bound operations) and insert active input immediately after a break occurs.
By adding such features in emulators, it would then be possible for example to extend the left+right concept to even more varied directional inputs and corrupt save data through hard reset at the exact block required to perform a specific trick.
I've had this idea myself a few times but I had to dismiss it.
Polled input is rather simple, you ask for input every time the game asks for input.
Interrupt-driven input becomes unfeasible really really fast, basically you want to allow input between every CPU opcode execution, and hard resets at any time, even mid-opcode. I am quite sure there are games that use both methods of input depending on where in the execution it is.
When I tested the feasibility of this I copied Gambatte's CPU core and allowed for input before I entered an opcode execution, I did not set up sound or graphics. (For those who are unaware: Gambatte is a GameBoy emulator, it has a 4 MHz CPU, most opcodes take 4-8 cycles to execute). This means I let the emulator poll for input up to 1 million times per emulated second, when you step through the game to figure out when to enter input, this becomes really really slow and monotone, it could take hours to TAS a single frame even for the simplest of games. This is for the GameBoy, now consider if this was done on say the Nintendo64 which has a ~90 MHz CPU, of course most CPU instructions take a bit longer to execute than on the GameBoy, but in general you will most likely be polling for input 5-10 million times per emulated second (there are of course exceptions like Super Mario 64).
Can that not be solved by having separate hotkeys for different time resolutions?
Frame advance: everything as usual.
Instruction advance: lets the emulated CPU execute one instruction within a frame.
Poll advance: advances to the next moment where a controller is polled for input (lag frames and so on always skipped?).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
When I tested the feasibility of this I copied Gambatte's CPU core and allowed for input before I entered an opcode execution, I did not set up sound or graphics. (For those who are unaware: Gambatte is a GameBoy emulator, it has a 4 MHz CPU, most opcodes take 4-8 cycles to execute). This means I let the emulator poll for input up to 1 million times per emulated second, when you step through the game to figure out when to enter input, this becomes really really slow and monotone, it could take hours to TAS a single frame even for the simplest of games. This is for the GameBoy, now consider if this was done on say the Nintendo64 which has a ~90 MHz CPU, of course most CPU instructions take a bit longer to execute than on the GameBoy, but in general you will most likely be polling for input 5-10 million times per emulated second (there are of course exceptions like Super Mario 64).
I don't think SmashManiac wanted this to be done by opcode-stepping through whole frames. Rather, one would probably use frame-stepping normally, and when one needs higher resolution, one would set a breakpoint based on the position of the instruction counter or for reads/writes of an address, and then possibly do some opcode-stepping before providing the input. This is probably what was done for the subframe chrono trigger TAS, demonstrating that this is practical.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
amaurea wrote:
Warepire wrote:
When I tested the feasibility of this I copied Gambatte's CPU core and allowed for input before I entered an opcode execution, I did not set up sound or graphics. (For those who are unaware: Gambatte is a GameBoy emulator, it has a 4 MHz CPU, most opcodes take 4-8 cycles to execute). This means I let the emulator poll for input up to 1 million times per emulated second, when you step through the game to figure out when to enter input, this becomes really really slow and monotone, it could take hours to TAS a single frame even for the simplest of games. This is for the GameBoy, now consider if this was done on say the Nintendo64 which has a ~90 MHz CPU, of course most CPU instructions take a bit longer to execute than on the GameBoy, but in general you will most likely be polling for input 5-10 million times per emulated second (there are of course exceptions like Super Mario 64).
I don't think SmashManiac wanted this to be done by opcode-stepping through whole frames. Rather, one would probably use frame-stepping normally, and when one needs higher resolution, one would set a breakpoint based on the position of the instruction counter or for reads/writes of an address, and then possibly do some opcode-stepping before providing the input. This is probably what was done for the subframe chrono trigger TAS, demonstrating that this is practical.
That would make a lot more sense actually, I stand corrected.
I don't think SmashManiac wanted this to be done by opcode-stepping through whole frames. Rather, one would probably use frame-stepping normally, and when one needs higher resolution, one would set a breakpoint based on the position of the instruction counter or for reads/writes of an address, and then possibly do some opcode-stepping before providing the input.
There are multiple ways to actually feasibly implement subframe input. Which apply depends on the type of input:
* Allow multiple subframes per frame, each consequtive poll of the same button incrementing the subframe those are returned from (lsnes with controler input)
* For each frame, have list of poll results to return in order (Nothing I know does this).
* Have list of polls and forced VI limit (Mupen64-rr, Dolphin)
* Have number of CPU cycles to execute before triggering a reset (I planned lsnes mid-frame resets to work this way, but couldn't get the mid-frame resets to work).
* Have timestamps for each event and carry the events out on time indicated (JPC-RR, openMSX).
