Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
CoolKirby wrote:
Also, nitsuja said that trying to load a savestate from another movie will give you an error message stating that the savestate you are attempting to load is not from the movie you are currently editing. This should help make sure you don't load another dtm's savestate into your current movie.
Yeah, I see that message now. How can I make it so I don't have to rewatch my TAS everytime I want to add something? I want to be able to just loadstate at a part of the game, and then it continues the playback from there. Is that not possible yet Nitsuja? I have done read-only mode on older revisions, but I have to create a savestate during playback of a dtm so it can continue playing from that point when I do loadstate, but that defeats the purpose since I have to watch my run anyway.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
rog wrote:
It's at 0xd, and is backwards. So, looking at one of my .dtms, i have AF 28 01 00. This would be 000125af, or 75183 frames. The entire format is explained at http://code.google.com/p/dolphin-emu/wiki/TAS_Tasks
Good to know. I am still kinda frustrated about read-only mode though. With the latest revisions of Dolphin (currently using 3.0-232), it seems as though when you load-state from a state that was created during the playback of a different dtm file, it it loads the dtm associated with that specific load-state, even if you were playing back a different dtm file before the load-state (confusing, I know).
Example: I playback a file "A.dtm" and during that playback I savestate1. I then add onto "A.dtm" some additional TASing. I save the new file as "B.dtm". If I playback "B.dtm" with read-only mode check-marked, and then loadstate1, it seems to stop playing back "B.dtm", loads "A.dtm" from loadstate1 and plays it until the end of the file. Although A & B contains the same frame data at loadstate1, it still does this. If we could disassociate the dtm from the savestates, this would make read-only mode work (maybe?).
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Wak017 wrote:
I believe the dtm files for dolphin act quite different from the other movie files; they are hexadecimal files, instead of .txt
Anyway, with dedication I am now able to edit .dtm files efficiently. But I have to say that it's still hard, because I have to work with numbers from 00 00 00 00 00 00 00 00 to FF FF FF FF FF FF FF FF as input, and the frame number also is an hexadecimal number that doesn't seem to represent the in-game number of frames.
Also, if I am to edit a DTM file, I can't make a file any longer just by editing it with HxD. I have to go in-game and wait for the .dtm to get longer by itself, THEN I can add, let's say, 10 seconds of copy pasted input.
I did some editing in HxD and it is really useful! I was able to redo ch1-2 in resident evil 4, and copy-paste ch1-3 into it for some of the parts. I did bump into that issue that you talked about Wak017 with modifying the dtm length. I'm searching to see if there are hex bytes somewhere that tell us how long the playback is (there should be). If I can modify those bytes directly, then editing it becomes 100x easier.
Also, any suggestions to programming a hex editor for dtms? I have access to Microsoft Visual Studios, but idk what would be best to create an executable, if I decide to program this.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Comicalflop wrote:
TheCape motivated me to start working again on the Gold Gem TAS, and I just completed World 1. So there's still progress going on with this project.
Think you can give me your .m64 for your WIPs? I'd like to test to see if it can be console verified with the Droid64. The current run desyncs in Spike Land.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
To be honest, I believe the BEST method to control the N64 is to actually use a N64 controller like I did. This way, for games that use the memory card, rumble pak (unnecessary for TASes), or GameBoy adaptor we won't have to emulate those either with software.
EDIT: And megaFoetzli, this would be useful, but Parallel Port aren't supported in Windows7 (I think) and I bet a lot of people here use that OS.
And also, Majora's Mask and OoT will not play back. Period. I had to add ~150 blank frames just for it to create the save file in MM. Load times between emulator and console are just too different for these game. Please stop asking me to do it. :,( Mario64 is a completely different case, since it only polls during gameplay, thus load times don't exist according to my Droid64. Load times stop the controller for any game that does not support controller peripherals; only these TASes I can see working on console.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
I tried running Mischief Makers. I couldn't get past the title screen. I added a 1 frame delay at the beginning and it synced until level 1-4 (Spike Land). I will try adding/deleting frames to see what happens, but I fear that in later stages it will affect boss AI and puzzle solutions.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Mitjitsu wrote:
SoulCal, would it be possible to test other N64 games?
The only games I have are Ocarina of Time (v1.2), Majora's Mask (v1.00), Mischief Makers, and Smash Bros.
I can probably get Mischief Makers and Smash Bros to sync right, but Majora's Mask is causing me problems. MM does odd stuff with the controller, which screws up my code as to when to send new controller commands. MM makes the controller poll 2x during gameplay, but 6x during load and pause screens. I can tell that the 2nd poll is actually just rumble pak stuff. As for what the other pulses are... O_o
[URL=http://imageshack.us/photo/my-images/84/smaskd.png/][/URL]
All other games I've seen either poll once per frame, or two per frame if rumble pak or memory card is supported.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
DarkKobold wrote:
Hmm, I can't seem to see any advantages of the MSP over say the Atmega (arduino) platform. Likewise, the overhead on getting the MSP going appears to be much higher. I'm assuming that your capstone lab already had all of these items available, which is why you went with that platform. This may be doable on the cheap by sticking with the arduino platform.
As a side note, the capstone that I took, and later TA'd for, used the PIC microprocessor. Thus, most of my early projects used PICs. Now, I stick to arduino, since the startup cost is low for every project.
The arduino should be perfectly fine; I even thought of using one for this project since the NESbot used it, but at TTU, the engineers say it is bad practice to use them. As long as it can clock over 8MHz and has the ability to load large files onto it; the txt file for the Mario120star run is 5MBs. I can provide you my code in a zip: http://www.2shared.com/file/1BVi7BR-/MSP430SDcard2.html Good luck converting it!
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Noob Irdoh wrote:
I assume I shouldn't even bother trying doing this on my German (PAL) Nintendo 64, right? Even if I use a SCART connector I guess it still runs at 50Hz.
In theory any N64 should work with how I programmed the MSP. If you can verify that the controller polls at 50Hz, then there shouldn't be a problem, but I could be wrong.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
DarkKobold wrote:
So, there is an MSP protoboard on sparkfun - http://www.sparkfun.com/products/584
I already have MATLAB. You obviously just soldered to an N64 controller... what else is needed?
I was given a license to a program called "Code Composer v4" by Texas Tech, which is what is used to program the MSP. The license can be expensive if you get the full version ($795), but maybe this will help. http://students.byu.edu/~cs124ta/references/downloads/CCS/ccstudio.htm
Another program called "IAR workbench" can also be used to program the MSP, but the free version of that has limits on how large your code can be (I think 4kB, which my code is larger than). Of course, with this being TASvideos, I will not mention the "other methods" to obtain the software, wink wink.
You also need a debug module (USB to JTAG) to even put code on the MSP. Some can be about $100. http://www.ruiva-fastproto.com/msp430-usb-debugging-interface-mspfet430uif-p-53.html
I would HIGHLY recommend getting this MSP, since it is the one I used, and it already has an SD card mounted on it. (Mounting one yourself will be a pain) http://www.olimex.com/dev/msp-169lcd.html This way you wouldn't have to change my code at all as to which connections I'm reading the SD card from. It is only $15 more.
For the smaller things: an SD card (a few $), a set of hex screwdrivers to open the N64 up ($7 eBay), and a N64 controller or two to break ($?).
I'm creating a project on Instructables.com of my process. I'll provide code and all that when I get around to it. I'm very bad at explaining things in a technical manner so bare with me.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Master of Puppets wrote:
If that is the case, then that's even better. But he did say "However I did have to modify the HELL out of the m64 to play it back right, but all frame and button data is the exact same (just some formatting)." So to me it somewhat sounds like he had to insert a bunch of blank frame here and there, but I am most likely wrong, and like your answer much better!
Like I said, just ask how I did things. I'd be glad to answer. Here is my process for modifying the m64 file:
1. I used this TASedit v1 tool to convert the m64 to a txt file. http://www.bluetoaster.net/emu/tools.htm
2. The txt file created has some data at the beginning of it (it says what game is being played, author name, frame count, etc). I just delete this stuff from the beginning of the file, leaving only the frame number and controller data.
3. I use a program called MATLAB to edit the file into 16byte chunks; every other 16byte chunk is button & joystick data.
The reason for doing this is because of the processor I am using, the MSP430F169; it only has 2kB of memory, and has no way to have a file system (i.e., I can't read .m64 or .txt files directly). It has an SD card on it (the txt file is put on the card), but you can only read in raw byte data. Making the MSP read the SD card data is a lot simpler my organizing it so every occurrence of the A,B,Z,etc buttons occur at every 16th,16th+1,16th+2,etc memory addresses of the SD card.
Here are examples of my modification process
1. m64->txt http://www.2shared.com/document/NBNMC6YM/fMario.html
2. txt->txt via MATLAB http://www.2shared.com/document/K81Uf-eH/MarioTest.html
And that's it; I didn't have to add or delete frames to get it to sync, it is straight up the same button and joystick data and frame numbers.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Warp wrote:
I would have never believed that a tasbot could be built for such a modern console as the N64. It's awesome.
Of course the little skeptic in me always makes be slightly cautious. After all, believing in the veracity of the video is a question of trusting the person who made it. Basically the only way to make absolutely sure that the video is legit is for an admin or a trusted contributor/member of the site to either go there in person and verify it, or build the device himself and test it.
If my project is a shame, I should get an award for "biggest trollolol ever!" But seriously, I actually did this as my graduation project at Texas Tech University. I will try and set up a blog or something of the sort and reveal all my research materials, since I was required to keep a notebook of everything to begin with as per the class expectations.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
sgrunt wrote:
Brandon wrote:
If you'd like to have your videos used as verifications on site[...]
I feel compelled to dispel the notion that we have formal standards on what should and shouldn't be in a verification video - we don't. (I think we can at least agree that the console actually needs to be shown in the video and that the run needs to be completed, though.)
I feel compelled to show the console and walk around the TV to show nothing else is connected. I also like to talk a little about it and explain what it is (some of my YouTube subscribers thought I programmed an AI to play, or it was actually me.) I'm currently recording the 120star TAS btw.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
ais523 wrote:
My guesses as the answers to these questions: it's possible to detect if the console is lagging by monitoring the voltage input to the controller (so the N64bot can automatically adjust for Mupen being wrong about what the lag actually is), and that the RNG is reset to a constant value at power-on (with the problems matching up the RNG only happening when hexing during a run, because obviously TASes don't battery-save and reset the console). I don't know for certain, though.
You could just ask how I did it. :). It is actually 10x simpler than that; I don't even have a lag counter, in fact it never crossed my mind why I would need one. I'm just sending a new frame of commands every time the n64 asks for it. The only connection between my processor and the n64 is a wire that sends a pulse saying 'I'm ready for new controller stuff.' However I did have to modify the hell out of the m64 to play it back right, but all frame and button data is the exact same (just some formatting). And N64bot sounds a little bland. My suggestion is the Droid64.
And boom goes the TNT.
Link to video
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Brandon wrote:
If you'd like to have your videos used as verifications on site, please start recording right before you turn on the console (Avoid talking please), and record until the credits finish running. If you have a tripod, this could help a lot. If you do this for all of the SM64 runs, obsolete and current, you will be my hero.
I was talking to show it was legit and show my design. I'll eventually get around to recording a good quality video, too. Any why would I verify obsolete SM64 TASes? That's rather unnecessary. Besides, I got the (relatively old) 120star run to sync just fine; I am 100% certain the other old TASes will also.
Btw, my design is so strange and twisted, no one will ever be able to understand or reverse engineer what I did. If there is a free blog or something I can sign up for, I can put my code and design materials online for everyone to see. Just know if you want to try to verify things yourself, you'll need about $350 worth of software and hardware.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Ace wrote:
Any progress? =)
I'd be working on it if I could. It is also frustrating that we don't have a read-only mode that works correctly for Dolphin yet. I have to watch about 30 minutes of 7fps video before I can continue with actual TASing. Besides, with newer revisions, there is always a chance for desyncs to occur with files created with older revisions (currently using r7695). If anybody wants to give it a shot, here is my .dtm file up until my latest WIP: http://www.2shared.com/file/4WAu5UoU/chapter1-32_-_Copy.html Edit, modify, do whatever you want, and see if anyone can make some progress or even improvements.
I won't be able to do any WIPs until mid December, if that. College sucks.
EDIT: I will pick this back up, at least until the end of chapter 1. I want to TAS the Del Lago fight so bad! I am now running Dolphin 3.0-204.7, which is able to sync my run up. I haven't tested if this version has read-only mode working yet or not.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
I would prefer as accurate of an emulation as possible, regardless of what is being emulated (load times included). Of course we will never have Dolphin be like the GC, but 95% is good enough. The same goes for PSX, PS2, etc. Besides, with increased performance of emulators over consoles, it causes different TAS possibilities and routes. May I reference MegaManX2? There is a time saving glitch in Crystal Snail's stage that can't be done on emulator because it requires lag frames (which only console produces in that area).
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
Slowking wrote:
I think trying to match GC load times is stupid anyay. We are TASvideos. We play on emulators. Everyone knows it and if not they should.
Why would we prolong loadtimes? They don't show gameplay. TASes can't be compared to console runs anyway.
Call me a purist I guess. I would prefer as accurate of an emulation as possible, regardless of what is being emulated (load times included). Of course we will never have Dolphin be like the GC, but 95% is good enough. Besides, with increased performance of emulators, it causes different TAS possibilities and routes. May I reference MegaManX2? There is a time saving glitch in Crystal Snail's stage that can't be done on emulator because it requires lag frames (which only console produces in that area).
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
AngerFist wrote:
About the waiting periods, are you guys aware that you can turn off the speed disc option? If not, please give it a try and see if Dolphin then properly emulates the waiting periods. If so, we have one less thing to worry about.
What is the 'speed disc' option? Are you saying that it may give more accurate emulation for the load times? I wouldn't doubt Metroid Prime could be sub 0:53 if we had faster load times, but that's more of an emulation advantage rather than actually being faster. Seriously, taking off just 2 seconds per waiting period would reduce the run by at least a minute.
EDIT: I just looked it up; it is called "Speed Up Disc Transfer Rate" and you access it by right-clicking a game and going to properties. Sadly though, it is disabled by default, so regardless we have faster load times than the GC. When you checkmark the box, it makes load times almost go away. I played my RE4 .dtm file, and after the first load screen, I had about 3 seconds of idle time before any controller input was finally provided. A 3 second advantage within the first 20 seconds of a video...not a fan of that, considering I am already a few additional seconds ahead because of load times with default Dolphin settings.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
DarkKobold wrote:
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.
Experienced Forum User, Published Author, Active player
(333)
Joined: 1/19/2010
Posts: 383
Location: Texas
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.
[/URL]
All other games I've seen either poll once per frame, or two per frame if rumble pak or memory card is supported.
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.