SoulCal I would recommend you to get a SNES TAS working on an actual console. There is BSNES, which claims to be extremely accurate. Another good thing is that it doesn't use any high level emulation... Well, you would need to add rerecording features for the emulator first, but I think your chances to succeed are much higher. The emulator also has a very readable source code, so this should be relatively easy for a skilled programmer. And most of the reverse-engineering for the controllers is already done...
I wish you good luck for whatever you're going to try. I would try to get some game working which doesn't have any SRAM, as this eliminates one source for errors in sync. I don't know if such an N64 game exists.
What we need now is a console slowdown method, to play it if not frame by frame, then at least at 1% speed. And even if it'd be possible, the real pain would be hacking the console to allow savestates (which I doubt is possible).
have you not read my post? there is an MKW TASer that TASes on the Wii, savestates and all, I don’t know how though
I have, but we have other consoles that may not allow that. Wee need to ask this guy some questions about his methods.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
What we need now is a console slowdown method, to play it if not frame by frame, then at least at 1% speed. And even if it'd be possible, the real pain would be hacking the console to allow savestates (which I doubt is possible).
have you not read my post? there is an MKW TASer that TASes on the Wii, savestates and all, I don’t know how though
Some games have built-in rerecording. (I know that Battle for Wesnoth, for the PC, has its normal save feature work as savestates that store everything but RNG (for probably obvious reasons), and rerecords everything that happens, meaning that even unassisted runs of that game have effectively TAS-like power. Timing doesn't matter there as it's a turn-based game.) I've heard that there's a cheat code for Super Smash Bros. Brawl that opens a debug menu that allows for frame advance (and possibly other TAS-like controls); it wouldn't surprise me if MKW had one too.
Beginning my lab project this semester, I have begun to find a few conflicts with the N64. So the N64 requests inputs at 60 times per second, which makes sense with the 360i (60fps interlaced) video the N64 produces. The SuperMario64 TAS is ~18,200 frames for the 5 minutes, which calculated out comes to 60fps. Using the TASeditV1 tool here http://www.bluetoaster.net/emu/tools.htm , I convert the m64 file into a txt file, so I can load it onto a microcontroller. However, the created txt file is only ~9100 lines of frame data. This 9100 is 1/2 of the 18,200 frames TASvideos says the video is. Is this a problem with the TASedit tool, or does the txt file contain all the frame data, but the N64 only updates once per 2 frames instead of once per frame? I confirmed that the actual console does poll inputs once per frame (at 60fps interlaced).
SM64 doesn't run at 60FPS (I think it's 30 or 20FPS instead), even if the console is polling for input that often. I'm not familiar with the systems involved, but it's not inconceivable that the movie format would include a specifier for target framerate, so that it wouldn't have to include input for frames the game doesn't care about. If so, you should be able to stretch the input file to cover more time.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I recall some games having variable FPS though... I think I recall Banjo Kazooie running at 60 FPS at the opening N64 logo, but the rest of the game is slower. Glover may have had something like that too. I don't remember for sure though.
<ccfreak2k> There is no 'ctrl' button on DeHackEd's computer. DeHackEd is always in control.
SM64 doesn't run at 60FPS (I think it's 30 or 20FPS instead), even if the console is polling for input that often. I'm not familiar with the systems involved, but it's not inconceivable that the movie format would include a specifier for target framerate, so that it wouldn't have to include input for frames the game doesn't care about. If so, you should be able to stretch the input file to cover more time.
Here is the m64 I converted to a txt: http://www.2shared.com/document/OHmMOXZz/Mario64inputsTAS.html
It does have an indicator for FPS, but it has "FPS|i1=1" which I don't know what it means. You are probably right that the game doesn't run at 60fps, but rather 'true' 30fps, but remember it is probably interlaced video which is at 60fps (but contains essentially the same data as a 30fps non-interlaced video). And stretching the input file sounds sketchy...
Beginning my lab project this semester, I have begun to find a few conflicts with the N64. So the N64 requests inputs at 60 times per second, which makes sense with the 360i (60fps interlaced) video the N64 produces. The SuperMario64 TAS is ~18,200 frames for the 5 minutes, which calculated out comes to 60fps. Using the TASeditV1 tool here http://www.bluetoaster.net/emu/tools.htm , I convert the m64 file into a txt file, so I can load it onto a microcontroller. However, the created txt file is only ~9100 lines of frame data. This 9100 is 1/2 of the 18,200 frames TASvideos says the video is. Is this a problem with the TASedit tool, or does the txt file contain all the frame data, but the N64 only updates once per 2 frames instead of once per frame? I confirmed that the actual console does poll inputs once per frame (at 60fps interlaced).
Wow, this could be huge - this means that there technically could be more frame savings locked in Mario 64, if you had true 60 Hz polling, as opposed to the 30Hz polling that Mupen does.
The problem with Mupen (and PCSX-rr, for that matter) is that they frame advance on the GPU update, as opposed to the V-sync. Now, for games like Grand Theft Auto 2, that is fine - it only polls once per 2 v-syncs. However, for games like Final Fantasy 8, and possibly Mario 64, this provides less possible input than the console is actually allowing for. I had fixed PCSX when we switched over to PSXjin, and now it accurately frame advances on the V-sync, even though the GPU only updates once per 2 frames. This, of course, is a pain in the ass to Motharayas, who is attempting to do GTA2, and has too many vsyncs.
Very interesting. Perhaps Mario 64 could be sub-5 minutes with true-vsync-polling.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
I asked him how he does it, he uses 2 codes:
“i use a slowdown code (about 15-20fps) and live replay with button activators which takes very long time for lap 3 because i have to watch the whole run to change anything”
basically slowdown, and a code that copies the input of your saved record’s ghost, button activators means he can stop the code from following the ghost so he can adjust things
I can’t believe he made such quality TASes with such horrible tools…
Wow, this could be huge - this means that there technically could be more frame savings locked in Mario 64, if you had true 60 Hz polling, as opposed to the 30Hz polling that Mupen does.
Do you think the creators of Mupen would have made such a drastic mistake? It seems the case with my testing, but...really?!
DarkKobold wrote:
The problem with Mupen (and PCSX-rr, for that matter) is that they frame advance on the GPU update, as opposed to the V-sync. Now, for games like Grand Theft Auto 2, that is fine - it only polls once per 2 v-syncs. However, for games like Final Fantasy 8, and possibly Mario 64, this provides less possible input than the console is actually allowing for. I had fixed PCSX when we switched over to PSXjin, and now it accurately frame advances on the V-sync, even though the GPU only updates once per 2 frames. This, of course, is a pain in the ass to Motharayas, who is attempting to do GTA2, and has too many vsyncs.
So for some games V-sync matters. Although if we could get 2 inputs per frame on emulator it would be hard to see if those would actually count. Let's say I press START every other V-sync on console for SuperMario64. Since the game updates the screen every 30 frames (or less) we won't even see the pauses occur, or will we? If we had access to double pausing, we could do pauseBLJ twice as fast. So basically that means we can unpause AND pause every frame, instead of every other frame; somehow I doubt this is possible. This brings up the final question of: why is the Mario64TAS labeled as 18,000 frames long if it only has 9000 input frames?
I think the simplest explanation is also the most likely here: SM64 not only displays at 30FPS; it also only receives input at 30FPS. The extra polling the console does is ignored.
Of course this should be tested, but it just strikes me as extremely unlikely that this hasn't already been considered.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I think the simplest explanation is also the most likely here: SM64 not only displays at 30FPS; it also only receives input at 30FPS. The extra polling the console does is ignored. Of course this should be tested, but it just strikes me as extremely unlikely that this hasn't already been considered.
I considered that it doesn't use the extra polls, but why would they design the console like this? (maybe some game support 60Hz and others support 30Hz) I may need to see if I can deliver inputs on the odd or even numbered V-syncs to determine which one, or both, is used. And can anyone explain why the Mario64TAS is ~18,000 frames long when only ~9000 frames of input are provided in the m64 file? If the console actually does have 60Hz polling, this will cause issues when having the m64 play on console, as not enough inputs will be provided.
Also I will need to find out if lag causes not only the framerate to fall, but the polled inputs as well. If anyone cares, I can post my powerpoints on the forums. Then you all can see the readings and such I get from the controller/console/etc.
I think the simplest explanation is also the most likely here: SM64 not only displays at 30FPS; it also only receives input at 30FPS. The extra polling the console does is ignored.
Of course this should be tested, but it just strikes me as extremely unlikely that this hasn't already been considered.
This is highly unlikely - remember, the console doesn't poll the controller without the game asking it to - otherwise, we'd never have lag frames. Thus, it most likely has interrupt handling code that reads the joystick, deals with timing, and etc. It would actually take more coding to deal with throwing away every other input, than to just deal with each input in a stereotyped fashion.
SoulCal wrote:
Do you think the creators of Mupen would have made such a drastic mistake? It seems the case with my testing, but...really?!
AFAIK, Mupen-rr is separate from Mupen, the main program. Frame advance was probably added by nitsuja, who created Mupen-rr. Thus, he wasn't an expert on the N64 platform, just an expert on adding re-recording.
Also, I've spoken with adelikat about this before - it would be far better for TASing if games did input advance instead of frame advance - i.e. allowed each poll to be different.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Alright, messing with Mupen-rr some I noticed that there are two numbers of interest (which all you N64TASers know). One is what I can safely assume is the Vertical Interrupts, or when the system polls the controller. Now it makes sense why TASvideos uses this instead of input count to determine length of videos, since this increments in a constant real-time measurement. The second number indicates how many inputs have been given. Here is a sample image of what I'm talking about:[URL=http://imageshack.us/photo/my-images/824/mario64tas.jpg/][/URL]
The FPS is 30.5 and the VI is 60.9 (about a 2:1 ratio, as expected). These numbers fluctuate by a few decimal places here and there but generally they are the 30/60. The VI will drastically change during load times; sometimes as much as 20-40 when the input counter only changes by 1. I suppose this is a GOOD thing because I noticed that the N64 console will actually stop polling when there are load screens. So what the emulator may be doing is skipping the time where the polled inputs are not even provided (it did this to me when TASing on Dolphin also). In fact, the controller line goes to zero volts when the load times occur, and picks back up when loading is done. Next thing to find out is if Mario64 or other games absolutely need to have inputs on both polls in order to function on console.
That information about the controller line is pretty interesting, as it means you could measure lag with a multimeter or modified controller (NESbot-style). Thus, you might not even have to get the emulator to calculate lag for you, if you can measure it from the console itself.
That information about the controller line is pretty interesting, as it means you could measure lag with a multimeter or modified controller (NESbot-style). Thus, you might not even have to get the emulator to calculate lag for you, if you can measure it from the console itself.
How would I measure lag with a multimeter? I have an oscilloscope set up to see the pulses and voltages send to and from the controller, which is essentially a multimeter but displays things as a function of time. And why would I need to calculate lag?
That information about the controller line is pretty interesting, as it means you could measure lag with a multimeter or modified controller (NESbot-style). Thus, you might not even have to get the emulator to calculate lag for you, if you can measure it from the console itself.
Uh, yeah, you could technically check for lag using the NESbot. It would be interesting to record the 'time' between pulses, which could tell you exactly when PCM errors occur, and the like. But it really isn't necessary at this point in time.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Again, why do I need to check for lag? I was thinking that the # of polled inputs per second would slow down as the game lags, but I could be (and probably am) wrong.
Also a recap about what I said about the controller lines:
1. The controller line actually goes to 3.2 Volts when a game is at a load screen. (sorry)
2. For whatever reason, this does not occur for games that support a rumble or controller pack. The polled inputs are constant. This may cause problems if the console loads slower/faster than emulator.
The first image is pretty self explanatory. The 2nd image is what you see when you zoom out on the first image; at the 0.00s mark is basically what you would see in image 1. The second pulse, which occurs 1.8ms later is the controller and rumble pack data. If a game doesn't support either of those, the 2nd pulse (or rather set of pulses if you zoom really far in) doesn't exist. You can see that the pulses between inputs are ~16.6ms apart (1/60sec). So these pulses will disappear for about 1 second and just go to 3.2Volts if a game doesn't support those peripherals. If a game does support them, these pulses stay constant during load times. I confirmed this with the games Mario64, OoT, Majora's Mask, Bomberman Hero, Mischief Makers, and DK64.
SoulCal, the only reason to check for lag frames would be to improve emulator accuracy. Some games may sync perfectly, even with an extra lag frame here or there.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Yes. In fact, obtaining a cart with rewritable ROM chips would make the verification process go a lot faster, due to being able to use the precise same ROM used as was done with the TAS (preventing version difference issues).
I have a friend that can do this for the Mega Drive, but it requires a PC with a Parallel port. I'll inquire about NES games.
Wow, this could be huge - this means that there technically could be more frame savings locked in Mario 64, if you had true 60 Hz polling, as opposed to the 30Hz polling that Mupen does.
Some interesting N64 facts:
1. Games can poll at 30Hz or 60Hz on console.
2. Mario64 polls at 30Hz, so we are about as optimized as we can be!!!
3. All games that support rumble or controller pack poll at 60Hz.
4. Whoever programmed re-recording in Mupen has a great implementation. Games like OoT and Majora's Mask poll at 60Hz on console, and MupenRR allows for 60Hz input for those games. I confirmed that Mupen skips polls in Mario64; this is simply because Mupen has a default of 60Hz polling, but with 30Hz games it just skips every other poll.
Good things to know. I should have some sort of TAS-on-Console action within a few weeks...hopefully.
I got a question. Is it possible to verify runs using a reproduction cartridge? Especially somegames that may be too rare/expensive to get hold of.
why anyone would TAS stadium events is beyond me. It is nearly the exact same game as World class track meet.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
[/URL]
The FPS is 30.5 and the VI is 60.9 (about a 2:1 ratio, as expected). These numbers fluctuate by a few decimal places here and there but generally they are the 30/60. The VI will drastically change during load times; sometimes as much as 20-40 when the input counter only changes by 1. I suppose this is a GOOD thing because I noticed that the N64 console will actually stop polling when there are load screens. So what the emulator may be doing is skipping the time where the polled inputs are not even provided (it did this to me when TASing on Dolphin also). In fact, the controller line goes to zero volts when the load times occur, and picks back up when loading is done. Next thing to find out is if Mario64 or other games absolutely need to have inputs on both polls in order to function on console.
The first image is pretty self explanatory. The 2nd image is what you see when you zoom out on the first image; at the 0.00s mark is basically what you would see in image 1. The second pulse, which occurs 1.8ms later is the controller and rumble pack data. If a game doesn't support either of those, the 2nd pulse (or rather set of pulses if you zoom really far in) doesn't exist. You can see that the pulses between inputs are ~16.6ms apart (1/60sec). So these pulses will disappear for about 1 second and just go to 3.2Volts if a game doesn't support those peripherals. If a game does support them, these pulses stay constant during load times. I confirmed this with the games Mario64, OoT, Majora's Mask, Bomberman Hero, Mischief Makers, and DK64.
