Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
sonicpacker wrote:
Input display is already built in, and bzb implemented rapidfire with the TAS input yesterday. He just hasn't released it to the public.
I am curious why he isn't part of team Dolphin. Instead of working by himself, he should officially join them.
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
Input display is already built in, and bzb implemented rapidfire with the TAS input yesterday. He just hasn't released it to the public.
I am curious why he isn't part of team Dolphin. Instead of working by himself, he should officially join them.
Yes, he should get on Dolphin's IRC channel and show his patches so far and ask for commit access. At least when I joined, there were fairly lenient on giving people commit privileges.
Hum... When I record a movie, everytime I get this error :
.
You can solve it by deleting the save files (I think those are the ones at /Dolphin Folder/User/Wii/title/ ), but now I'm thinking about it... This is not normal...
What am I doing wrong ?
fwiw, movies seem to sync fine now with dsp HLE, dual core, and idle skipping. I'm not sure exactly what idle skipping does, so not sure if it's acceptable to use in a run, but the others should be fine.
I'm not sure exactly what idle skipping does, so not sure if it's acceptable to use in a run
Some time ago, it seemed that idle skipping messed with dumping in MAJOR way.
And also with multicore, it isn't just about sync on one computer, it is sync across computers. I have seen numerious cases where what syncs on one computer doesn't sync on another.
I'm not sure exactly what idle skipping does, so not sure if it's acceptable to use in a run
Some time ago, it seemed that idle skipping messed with dumping in MAJOR way.
Well, a lot has changed recently. A few weeks ago idle skipping caused very frequent desyncs, but that doesn't seem to be the case anymore.
And also with multicore, it isn't just about sync on one computer, it is sync across computers. I have seen numerious cases where what syncs on one computer doesn't sync on another.
Interesting.
Certainly we shouldn't all start using these settings right away, but it's definitely worth investigating further. Being able to playback at 2-3x faster would make things significantly easier.
Well, a lot has changed recently. A few weeks ago idle skipping caused very frequent desyncs, but that doesn't seem to be the case anymore.
IIRC, the problem with dumping was that loading times and similar things were greately shortened on dumped video.
Such nonlinear desyncs are almost impossible to compensate for.
And testing that multicore stuff would need multiple computers (but then, sync check requests aren't exactly new thing).
Just tried dumping with idle skipping and dual core. Did not work at all. Got a black screen until the game started, at which point the entire UI was missing. It was caused by dual core though, not idle skipping. Everything appears to be working fine so far dumping with idle skipping on and dual core off, including syncing.
Joined: 9/21/2009
Posts: 1047
Location: California
From my testing with dual core, it seems that when I record with it turned on, it plays back correctly for me with it on OR off. When sent to other computers, it still syncs, but only with dual off. I have not tried dumping audio or video with it on.
Input display is already built in, and bzb implemented rapidfire with the TAS input yesterday. He just hasn't released it to the public.
I am curious why he isn't part of team Dolphin. Instead of working by himself, he should officially join them.
Yes, he should get on Dolphin's IRC channel and show his patches so far and ask for commit access. At least when I joined, there were fairly lenient on giving people commit privileges.
Can you please explain to me how to make a patch on git? Because for me "create serial patch" does nothing.
antd wrote:
Can you please explain to me how to make a patch on git? Because for me "create serial patch" does nothing.
Commit the changes (this is local-only operation) and then use git format-patch.
bzb95 wrote:
Ilari wrote:
I have no idea what Dolphin calls "Frame".
A frame is every time the controller is polled. Which for dolphin is 60 times a second for any NTSC game. Even if it is a 30 fps game.
Well, I guessed that it would be something like that (especially considering that the breakthrough in rerecording was allowing multiple polls per actual frame).
can you please try these new revs and post the code again if it still crashes?
It still crashes for me on the first time I try to open it, but after that it works fine (I only tried x64).
(Google is doing the translation).
Environment can not be my 32bit PC to launch the x84. Crashes every time.
I can not experience the improvement of state saving and TAS input.
私の32bit PCの環境ではx86を起動させることができません.毎回クラッシュします.
私はTAS inputやステートセーブの改善を体験することができません.
Operation related to TAS of N64/GC/Wii/PS2 emulator is often investigated.
Loading a savestate in pikmin (wii) disables all controls, and causes olimar to run off randomly until the wiimote is disconnected and then reconnected. Any chance for a fix?
It's caused by ignore format changes, disregard this.
Excuse me, but how do I dump frames into an avi file without causing desyncs? To be exact, the input doesn't desync, but instead the randomness is non-deterministic. I'm TASing Kirby's Air Ride, with every setting at default except I used LLE, since other audio options causes non-deterministic playback.
Excuse me, but how do I dump frames into an avi file without causing desyncs? To be exact, the input doesn't desync, but instead the randomness is non-deterministic. I'm TASing Kirby's Air Ride, with every setting at default except I used LLE, since other audio options causes non-deterministic playback.
Did you also record with dual-core off and idle skipping off? Those settings can also cause desyncs.
Did you also record with dual-core off and idle skipping off? Those settings can also cause desyncs.
I just checked, and it seems they're both on. I'll try turning them off.
Edit: It seems to sync now. Thanks!
Yeah, you got a little lucky there. Those two options can make some recordings unsyncable unless under perfect circumstances. I highly recommend only recording with both options off.
Joined: 9/21/2009
Posts: 1047
Location: California
So I dumped video for the SA2B WIP and it worked well. I dumped audio at the same time, but there are huge delays during the games loading times. Am I stuck syncing the audio to the video by myself, or is there a known fix? I'm using LLE of course.
I think you're stuck syncing the audio and video by yourself. The audio dump is the length of your TAS, but the video dump doesn't render all of the loading times, so it's shorter than the audio. What I did for the WIP encode of my TAS is add a third of a second of black screen to my video track for most loading screens (some were longer or shorter), which synced the video with the audio.
That's all you can do for now, as a fix does not exist. Publishers and encoders will also have to hand-sync everything.
.
You can solve it by deleting the save files (I think those are the ones at /Dolphin Folder/User/Wii/title/ ), but now I'm thinking about it... This is not normal...
What am I doing wrong ?
