Use the Super Gameboy or Gameboy Player, and connect to the snes/gamecube controller ports. Checkmark Ilari! :P
But seriously, is there is some reference pin on the gameboys to use as the polling rate? And the other two concerns I have are:
1. Would using a GBA/Gameboy player to verify a GB or GBC game be viable, or would clock speeds and different architecture mess up timing? I know the SGB plays games 2% faster than the handheld, but I do know some games on the site use the SGB.
2. Does the appearance of the Gameboy and Advance logos begin effecting the RNG at startup? I don't think the emulators use the startup logos. And correct me if I'm wrong, but doesn't gba use 'battery life' as a seed for the RNG?
Is there any possibility of something like this being made for gamecube?
It would only work with games that don't poll while loading (including any hardware-based polling).
Because if game polls controllers while loading from optical drive, botting it becomes pretty much impossible.
Would this method of loading GCN/WII games ok for verification?
SoulCal wrote:
Is accuracy of Dolphin anywhere near close to be ready for console verification? (Although we all doubted it could be done with a movie done on mupen, and we got surprised!
Is accuracy of Dolphin anywhere near close to be ready for console verification?
Depends on if game polls even on lag/loading frames and what kind of RNG it uses.
If it polls on lag/load frames, forget about it (load frames are even worse, as those are just plain impossible to emulate correctly).
If it doesn't, but RNG is badly behaved (CPU cycle counts, etc...) then it won't sync.
But otherwise it might actually sync.
Doesn't the gamecube use the internal clock as a RNG seed? IIRC, some events in Thousand Year Door are dependent upon the system's date and time. That would make verifications nearly impossible.
Doesn't the gamecube use the internal clock as a RNG seed? IIRC, some events in Thousand Year Door are dependent upon the system's date and time. That would make verifications nearly impossible.
I suppose setting the clock could be appended to the beginning of the TAS.
I still doubt it would be accurate enough to sync, though.
You know, Since the current any% of M64 is verified, I've been wondering how far back through the previous movies until it desyncs. Or heck, would all of them actually manage to sync. :P
I've been trying to redesign my N64 machine to play back Mischief Makers. What my microcontroller does is read in 4 bytes (32bits) from an SD card with the m64 on it. 32bits is the size of each frame of commands for the N64; 16bits used for the buttons, and 16bits for the x and y joystick position.
By examining Mupen, Mischief Makers polls at 60Hz, but it uses the same input twice in a row for 2 poll periods. So basically pressing A&B every other input cycle looks like this in the m64 file: AA BB AA BB AA BB
However, during load times and on power on of the system, Mupen treats these input times as having it's own unique input in the m64 file. So If I were to view this in a hex editor, it would look like: AA BB AB BA AB
Where the 2nd time A is pressed has a 1/60th poll period with all following buttons being pressed 2 poll periods.
Sorry if this difficult to explain. I have a video showing the desync.
Also, does anyone know if there are different versions of Mischief Makers? If you look at my video and the TAS from Mupen, although my gameplay synced to Spike Land (sometimes it goes 1 more level), all the character tiles during load screens are different comparing the two videos. I may be running the incorrect version of the game, or it may just be possible this game is emulated terribly.
If there is a way to make the m64 file have each poll period only lasting 1 period instead of 2, or some other work around to this, I'd appreciate any ideas.
Ignore some of my commentary. I mean sometimes the game polls twice per frame, and sometimes only once per frame.
Link to video
EDIT: I can consistently get the character tiles to match up on the first load screen now, but it involves me plugging in my processor first, then plugging in the controller. I'm not sure why this would affect anything..it's a mystery to me. This however does desync all of my frame adding so far so it desyncs immediately after the first load screen.
In case you guys don't know, my method involves using the circuit board of an actual N64 controller with wires soldered to each button, and then connected to pins on my micro. How have bots others have made function? I found it rather impractical to generate the pulse codes to emulate a controller since each game generates different sets of pulses.
MORE EDIT: I think I found an additional problem with my bot. Mario64 can sync just fine because there is no input on the 1st frame of the m64. What I just realized my bot is actually doing is sending controller command 2 from the m64 on poll 1, but since my bot can't calculate all the commands within the that poll period, it creates the commands after the poll has passed and then just waits for the next poll for them to be played. However, if a game (Mischief Makers) has a command on the first poll, my bot doesn't even read it since no interrupt has occurred. With this design, the first possible button presses can only occur on poll 2. I'll have to do something like manually trigger an interrupt before the console even starts, or just have the buttons be held on power on.
I'll be showing off N64 console TASs at the Austin Maker Faire on May 3rd, if anyone in the area is interested. Probably just Mario64 unless I can get Smash Bros and Mischief Makers running. I'll do what I can to promote and provide information about TASVideos while I'm there.
http://austinmakerfaire.com/
In case you guys don't know, my method involves using the circuit board of an actual N64 controller with wires soldered to each button, and then connected to pins on my micro. How have bots others have made function? I found it rather impractical to generate the pulse codes to emulate a controller since each game generates different sets of pulses.
The protocol is still the same. Other implementations (micro500, mine in progress) do send the pulses directly. Mine will do so for all 4 controllers.
SoulCal wrote:
frame stuff
Does Mupen only export frame data, and not data about each query? There are 2 possible solutions:
1. Work with query data on each query
2. Set up a frame window in which you repeat any redundant queries
But maybe I am misunderstanding what is going on.
In case you guys don't know, my method involves using the circuit board of an actual N64 controller with wires soldered to each button, and then connected to pins on my micro. How have bots others have made function? I found it rather impractical to generate the pulse codes to emulate a controller since each game generates different sets of pulses.
The protocol is still the same. Other implementations (micro500, mine in progress) do send the pulses directly. Mine will do so for all 4 controllers.
The problem I came across is that games using controller or rumble paks add extra pulses at the end of the button and joystick pulses. I had no idea how to simulate those so I just went the hardware route.
True wrote:
SoulCal wrote:
frame stuff
Does Mupen only export frame data, and not data about each query? There are 2 possible solutions:
1. Work with query data on each query
2. Set up a frame window in which you repeat any redundant queries
But maybe I am misunderstanding what is going on.
If you analyze Mischief Makers in Mupen, sometimes (mostly during screen transitions and loading) the game for 1 frame will switch to only allowing 1 input per frame instead of 2. I've gotten up to level 6 in the game, but it is mostly just me arbitrarily adding/deleting inputs from the m64 until it syncs. I tried doing a m64 check on each new input to see if it is a duplicate or not, but that doesn't work. I'm bad at explaining things, but if anyone has skype i'd be willing to screenshare and show you what I mean in Mupen.
skype: soulcalumbreon
It is quite possible this game is just poorly emulated and won't sync though.
I'll be showing off N64 console TASs at the Austin Maker Faire on May 3rd, if anyone in the area is interested. Probably just Mario64 unless I can get Smash Bros and Mischief Makers running. I'll do what I can to promote and provide information about TASVideos while I'm there.
http://austinmakerfaire.com/
:0 Seems interesting. What time of the day?
Projects:
Interested in TASing N64 Mario Golf.
GBA Mario Tennis: Power Tour is on hold.
I'll be showing off N64 console TASs at the Austin Maker Faire on May 3rd, if anyone in the area is interested. Probably just Mario64 unless I can get Smash Bros and Mischief Makers running. I'll do what I can to promote and provide information about TASVideos while I'm there.
http://austinmakerfaire.com/