Yes, I know this has been brought up many times in your history, but it is possible to do your speed runs on real hardware.
The problem that you can't sync to the vertical blank can be solved, with a different approach.
On most old consoles, the controller knows when it is being queried. The NES and SNES, for example, have a pulse you send to the controllers over a particular hardware port. The next several reads will get that data. The controller is doing a 16-bit hardware transfer to the host when those pulses come.
Emulators' movie formats should be modified. Rather than store the input state at each frame, they should be storing the input state at each controller read. Whenever it reads from the controller port, record the button state. You can then easily make a microcontroller program to feed the input to the console, and it can use the console's signals as timing.
Data size becomes an issue with microcontrollers. You can solve that by using delta-time on the controller state, like MIDI. In other words, store messages like "on controller read #7, controller state changed to Up+A", "on controller read #10, controller state changed to Up". The intermediate states would be assumed to be the previous. This would probably help significantly in all games but Super Metroid (that has an advantage to alternating button presses while just walking, right?).
Melissa
On most old consoles, the controller knows when it is being queried. The NES and SNES, for example, have a pulse you send to the controllers over a particular hardware port. The next several reads will get that data. The controller is doing a 16-bit hardware transfer to the host when those pulses come.
Emulators' movie formats should be modified. Rather than store the input state at each frame, they should be storing the input state at each controller read. Whenever it reads from the controller port, record the button state.
That sounds like good idea, if that pulse or strobe is indeed always required to get the button status. (I should read up on that...)
Sorry if I don't completely understand what you mean, but from what I gathered:
First, I don't exactly see the point. It seems to me that the only reason you'd want to reproduce these videos on a console would be to trick people into thinking it was done normally (which is NOT good.)
Second, certain consoles--the NES in particular--seem to be rather random with their memory. When emulated, a game runs the same time every time, but on occasion strange things happen on the actual console. I've noticed times on SMB where a goomba just doesn't appear where it's supposed to, and having a run where Mario jumps on a goomba that doesn't actually exist, would very quickly desync. Maybe it's a problem with reading the cartridge... I don't know.
I believe the main trouble you'd come across would be timing problems. Psudo-random number generators that base them selves around time would more than likely fail to return the same results.
I do agree with you that the file formats should work on a per input read basis and not on a vblank. I felt for different reasons, though. I made a topic on it a while ago.
I think Mupen64 does something like this already (it ignores lag frames).
But I agree that it is not a good idea to try to reproduce a TAS on a console. We have already put in so much effort to distinguish a TAS from a real-time speedrun. Let's respect SDA.
half of the levels in a TAS can be performed by a person. maybe you could do those parts yourself.
TAS' use rerecord many times am I right? If I made a run of smb1 using just a few rerecords I wonder how close my time would be to a TAS.
Super Mario Bros. console speedrunner
- Andrew Gardikis
I've noticed times on SMB where a goomba just doesn't appear where it's supposed to, and having a run where Mario jumps on a goomba that doesn't actually exist, would very quickly desync. Maybe it's a problem with reading the cartridge... I don't know.
It's a matter of which how many frames you let the game run after power-on before pressing start to start the game.
The random seed is iterated also on title screen frames.
If you press reset and immediately start the game, you are better off preserving the randomness, but the thing is that reset does not reset the RAM. It only resets the CPU. Meaning, that it's possible that some data from the game is preserved, such as randomness, leading into that each reset is unique.
Reproducing speedruns on the hardware would be silly, ie. fun. :) Probably not possible though.
Regarding the emulator stuff:
An SNES emulator would just have to provide the controller data when registers $4016 or $4017 are read, not every frame.
This would of course make creating TASes a bit more complicated - you could record frame-by-frame and wouldn't be able to get the results of real-time recording. The emulator would have to pause at each register read, not each frame.
I guess I should write up a new file format specification for movie files. It's about time there exist a standard. It should work for anything except systems where controller input causes an interrupt (like DOS games, unfortunately =/ ).
As for not resetting memory when doing a reset, yes, that is a problem, but it's not so bad if you understand it more. On a cold boot in which the system has been off for a short time or more, RAM will effectively consist of entirely FF bytes due to how RAM chips work (at least the ordinary kinds). With a reset, RAM does not change at all. In fact, on SNES (not sure about NES), the startup vector is hard-coded whereas the reset vector is specified by the ROM and can be different.
NES games are usually programmed to be aware of the fact that RAM may not be empty on startup. Mario 1 writes A5 to a particular byte at startup. If it starts up and that byte is not there, it assumes that it's a cold boot, and zeros RAM, then sets that byte to A5. (There are other games that use A5 at the same address, like Tennis, that can be used to do weird things if you change cartridges while holding reset.) As long as that byte is not A5 in a cold start, which is quite unlikely, RAM will get reset to 00's and have the same random seed.
I find it quite unlikely that this technique would be used to trick people into thinking that any of these are "human" players. The only people who would try to build these crazy fake controllers are the enthusiasts here. There is also the issue that people can already claim a TAS as legitimate. Hook up a NES with the cartridge and turn it on. Record yourself "playing" these in front of the system. Little does the audience know that the TV is actually playing the composite output from a video card on a PC running an emulator.
To get around that, you require that a person's hands be shown in the video. That works against both input misdirection and people making fake controllers with recorded movements.
I have a feeling that timing things based on controller read pulses should be highly deterministic, such that even different emulators get it correct.
Melissa
As for not resetting memory when doing a reset, yes, that is a problem, but it's not so bad if you understand it more. On a cold boot in which the system has been off for a short time or more, RAM will effectively consist of entirely FF bytes due to how RAM chips work (at least the ordinary kinds).
Recently byuu (the author of bsnes) has changed the initial value to 55h, to "fix" a game that relies on this value. There's some posts about it in the last few pages of his thread on the ZSNES board (see the "Emulation" subforum).
One of the suggested solutions was to include the startup value into the movie file.
what time are you guys aiming to get when doing this? a 5:00 run?
I was experimenting a little just a while ago, and realized I could probably get a 5:03 if i made individual level runs and then put them all together.
Super Mario Bros. console speedrunner
- Andrew Gardikis
I still dont understand how you would go about making a TAS on a console. I think it's kind of a weird thing to be doing, since you cna already make one easily.
Super Mario Bros. console speedrunner
- Andrew Gardikis
I still dont understand how you would go about making a TAS on a console. I think it's kind of a weird thing to be doing, since you cna already make one easily.
