Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
I'm halfway done with my tas now. 72k frames, and 3.2k rerecords, and i've had 4 desyncs so far. It's still not perfect, but it's pretty close. For reference, the last time i tried to tas this game, i ended at 22k frames, and probably 50 desyncs. It's a huge improvement. With any luck we'll get the remaining issues sorted out and get it merged into master within a week, and it'll be ready for people to really start tasing wiimote games!
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
It seems to fix the need to restart dolphin every time you playback a movie too.
I'm gonna take a shot at tasing a simple game with it, and see how it goes, but so far i like how it's looking.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
Looks like the same code i already tested, which still desynced.
edit: Yeah, it does still desync. No idea if it's less often than before or not.
edit2: It does allow recording gc controller and wiimote at the same time though.
edit3: on second thought, it's possible i had dual core on before. I can't seem to get it to desync at all anymore...
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
Patashu wrote:
If the game uses wiimotes (and it sounds like it will) it won't be TASable in dolphin yet.
Tasing with wiimote is far from impossible. It's probably about on par with mupen. That is to say, it's usually a huge pain in the ass, but can be done, with some games being easier than others.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
misc memory addresses:
Pointer to character data: 0x3dce54
character data:
0x00 float: x/y position
0x04 float: Z position
0x08 float: x/y position (who knows which is which)
0x16 1 byte: facing direction
0x5c float: speed
0x289B 1 byte: hp (1 = 1/4 heart)
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
Pheenoh wrote:
because Link is too high while the game is transitioning to the swinging animation. Evidence of this is the master sword being in two places at once in the picture.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
Warepire wrote:
RachelB wrote:
I cannot say I am too keen on accepting altering the memory card's state through the movie. As others have said it will become a very big hassle to verify the validity of the run, also in my opinion it is making things really fuzzy regarding what should be considered input to the game. When input is starting to depend on hypothetical secondary consoles it doesn't really feel like valid input anymore to me.
Why?
It's not input to the game, but neither is swapping discs, or inserting/removing memory cards, or hard resets.
Ok, I probably expressed myself a bit fuzzy and I am sorry for that, but my main point is in my last sentence, when "input" (as in commands / actions the console will accept) becomes dependent on theoretical secondary hardware like a second GameCube used to copy the data around on the memory cards as the first one is playing a game, this is where I think it goes a little too far in the lengths of how input shall be produced.
What exactly is the destinction between this, and say, using a GBA to connect to a gamecube (for tingle tuner in zelda ww, etc)? Surely we would allow that?
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
I cannot say I am too keen on accepting altering the memory card's state through the movie. As others have said it will become a very big hassle to verify the validity of the run, also in my opinion it is making things really fuzzy regarding what should be considered input to the game. When input is starting to depend on hypothetical secondary consoles it doesn't really feel like valid input anymore to me.
Why?
It's not input to the game, but neither is swapping discs, or inserting/removing memory cards, or hard resets.
As others have said it will become a very big hassle to verify the validity of the run
All it will take to verify is looking over a <50 line patch, compiling it, and checking sync. It would be easy to see any potential for cheating in the source code. If no one is willing to do that, then anyone with commit rights for an emulator could easily get away all kinds of cheating, so i don't see how it's unreasonable to expect source code (especially such a small amount) be checked over.
jlun2, not quite. The new memory card i would switch to will not be empty. It will contain a save file which was created at the start of the movie.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
The first one is for the viewers, and replaying the movie. Submitting a TAS that uses that kind of technique needs extra instructions to be able to watch it: "do this and that with the memory card at that time, and here too, etc...", unless of course if it's part of the movie file and the emulator code.
I will code support for it into dolphin if it's allowed. Everything would be automatic.
You could potentially see comments on the run that look like this: "there is no way to remove a memory card and copy the save (or do anything specific with the memory cards) on another console that fast. Real hardware can't do that (as quickly)."
I think that people would end up using it without thinking about the "real" minimum time it takes to do some memory card management with another console.
It only takes a few seconds on real hardware, and i believe all of the save warps i intend to do are 10+ minutes apart.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
Minda normally tells you to go back and get the sword and shield there. We can't do that since because of BiT, so we need the bublin to do a long jump attack over the trigger for minda telling us to go back.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
Warepire wrote:
If the system allows hot-swapping memory cards, perhaps it should be allowed, but it should be considered a memory card swap and not a "clear memory card" operation.
Which means you would need enough empty memory card files for each swap to be possible.
Example:
Let game save to Memory Card A, before another save occurs where you will be asked to overwrite etc, swap to Memory Card B, let the game save... and so on.
If the system needs to be powered off to remove the memory card or has an internal hard drive which it stores saves on, this must not be possible, as it would violate the representation of the actual system.
The system in question is gamecube. The memory cards can be removed at any time. The process to do this on a real console would look something like:
1) start the game with an unformatted memory card
2) format the memory card and create save data
2) remove the memory card
3) put the memory card into another console, and copy the (blank) save file to another memory card
4) continue playing, save, reset, and reload
5) remove the memory card, and put it back into the other console.
6) delete the save file, and copy back the blank save.
7) put the memory card back into the original console.
8) repeat step 4-7 as necessary
Altering the SD card in between frames is impossible on a real console (no matter what kind of robot you use to pull and reinsert the cards), and I don't think the state of the SD card is clearly defined if it's pulled while written to.
Well, it could be removed in the middle of a frame on a real console. What i wish to do would not allow that. I believe there is a ~2 second delay between inserting the memory card the game recognizing it anyway, so this would be impossible.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
So you want to
a) load a savegame
b) remove the memory card from the console
c) restore the memory card to a previous version (with no save file)
d) reinsert the memory card
?
Yes, that's right.
What happens to the real console when you remove the SD card while a game is running?
Nothing, other than being impossible to save or load without one.
How is this going to affect recording and replaying? When loading a savestate, the emulator has to ensure that not only the SD card contents are in the correct state, but also that any backups are present and in the correct state as well. Can this be done in a safe and robust way without noticeably slowing down quicksaves/quickloads? And without introducing incompatibilities between emulator versions for savestate- or movie files?
Well it will obviously require a change to the movie file format, but otherwise settings the flags to copy/restore a memory card should be the only thing that needs to be done.
How is this going to affect movie verification? Allowing arbitrary writing of SD contents in a movie file is obviously a no-go, since you could just manipulate your savegames without anyone noticing. But even a simple API that only allows you to "save SD", "restore SD" or "format SD" is going to be problematic if someone calls them during saving or loading.
I don't see why it would. I don't plan to save the memory card to the movie file, just set a flag to copy it, and have the emulator handle the rest. Source code will of course be available, so it would be easy to prove it doesn't do anything more than that.
Are there technical ways to prevent invalid movies from being submitted?
No, but that's already the case. If someone doesn't bother to make sure their movie actually syncs, there's nothing we can do about that.
All in all, if it's just about skipping a confirmation dialog, I very much doubt that it's worth all the trouble.
Well it will add up to about 4 seconds in my case. I have spent more time than this would take to code to save far less time than that.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
Would this be allowed?
The benefit is that when overwriting a save file the game gives an extra prompt asking if you want to overwrite it. Coping the memory card right after formatting it, and then copying it back after each save would avoid this. This is useful where save warps are used, and once a file is loaded it's never needed again. Since memory cards can be removed and files can be copied using freely available methods, this could even easily be done during a real time speedrun.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
NES is much simpler. Everything is done with low level emulation running simple 2d games. Mupen uses HLE for some things (which can introduce error in certain things while similar functions work just fine), and the games are doing much more complex things.
Dolphin has had some similar kinds of problems before too.
Experienced Forum User, Published Author, Player
(128)
Joined: 12/3/2011
Posts: 1579
So I found out that hex editing out 1 subframe before every pause will make the pauses 1 frame shorter, and I did this for the whole video here. However, the emulator itself is incapable of produce the necessary button presses for this to happen, so should this even be allowed? If I did this for the entire run, it would save 1 second for every 30 pauses or when using key items.
Enabling real xfb emulation should make it advance half a frame at a time.
