This custom version of Dolphin is intended for better performance in crap PCs.
Sure, but that doesn't mean that a crap PC will go from unplayable to great. There may be differences, but don't expect anything gigantic.
Kurabupengin wrote:
I wonder though, how conpatible is it?
I think it's generally as good as regular Dolphin unless you use settings that don't fit a game. (Compared to Dolphin, Ishiiruka has a few more settings that can improve the performance in some games but ruin other games.) There can be exceptions, though.
Kurabupengin wrote:
Or, How good is it for TASing?
I don't think I have seen anyone test it for TASing... The TASing code should be the same as regular Dolphin, so maybe TASing works the exact same, or maybe there are additional bugs that nobody has noticed yet. Do note that Ishiiruka TASes aren't accepted on this site as far as I know (though I could be wrong), so you would need to test that an Ishiiruka TAS syncs on the equivalent regular Dolphin build. I'm not sure if Ishiiruka's changes can affect the sync.
Kurabupengin wrote:
Honestly I don't know since the 32bit version hasn't been updated for quite a while.
Yeah, the 32-bit version of Ishiiruka stopped being updated a while ago just like regular Dolphin. If you're looking for good performance on a 32-bit CPU, I think you'll have a hard time finding it.
Well... The thing is that we can't just continue writing to the same file if the resolution changes. Having an option for going back to the old behavior doesn't make sense, because then you would get completely broken video in the cases where you would get multiple files now. What you need to do if you want to write to only one file is to make the output resolution never change, which is essentially what Stretch to Window does. Do you want a way to output different resolutions with pillarboxing/letterboxing instead of stretching?
Sorry, I missed the posts about it on the previous page, including the explanation of what the problem actually was. I also misunderstood "Disable automatic window resizing and force crop" as disabling crop when it actually should be enabling crop. I suppose those settings would work. Another option is using Aspect Ratio: Stretch to Window instead of Crop, but make sure to make the game window an appropriate size before starting.
Where can I Disable automatic window resizing and force crop?
The video and sound are already shifted during rendering.
If I delete these "broken files" I should check all the video during video processing, as these files appears to be broken during loading time, for example.
These are just micro-seconds, but given the number of files, it creates a gap in different places.
I don't completely understand your post. You can disable the settings you mention at Graphics > General > Auto adjust Window Size and Graphics > Advanced > Crop, but I don't see how that would help.
Yeah, I saw the above notes and was hoping for more answers since this method that users are now stuck with is extremely inconvenient for multiple reasons that I would argue outweigh what was written.
That's understandable. Unfortunately I'm not that familiar with the details.
sonicpacker wrote:
Is there some way for devs to make Lagarith an option within the menu, similar to the current lossless codec?.
FFmpeg doesn't support encoding Lagarith, so I don't think it's especially simple.
sonicpacker wrote:
If you guys can't program said suggestion for whatever reason, can someone direct me to the last version of Dolphin where the codec is able to be chosen? Hopefully my 5.0 movie syncs, if need be.
I really wish we had a better description of the change than that one I wrote up here... Unfortunately the change never made it into a Dolphin progress report. Fog, do you have anything to add to what I said?
We are considering (though it is absolutely not final yet) accepting it regardless, mostly under the condition that Dolphin TASes are technically always done on interim builds anyway. This would be something the Judges and Admins would have to talk about further, but I would say that it shouldn't stop the submission in case we do come to the conclusion that we can accept Dolphin builds like these.
Us Dolphin developers do actually treat the development builds as official releases – they just aren't labeled stable. Both TASers and other users are encouraged to use them, and their binaries and source code will be kept available just like with the stable releases. I would argue that "interim builds" when it comes to Dolphin nowadays are PR builds. Those are preserved badly and can often have problems because they're still in development.
Regardless, one way to avoid the problem with the official release rule could be to accepting Dolphin Zelda Edition as a separate TASable emulator. It's a proper fork of Dolphin, not just something like a WIP build for a new feature. The run would then count as being done on an official version of that emulator.
My concerns aren't about the Dolphin build itself, but with the verifiability of the TAS. Normally, verifying that a TAS isn't using technical measures to cheat can be done by checking that it syncs in a standard emulator without using any ROM hacks, unverified save data or e.g. questionable emulator settings. That isn't the case with this run. If you want to verify that GBA commands aren't sent in a questionable way, you would essentially have to do it SDA-style, having someone who's knowledgeable about the game look through the run for any potential cheating. I suppose that could set a bad precedent and make accepting the run harder because of the extra verification work needed. It's up to the site staff to decide if that's an acceptable tradeoff, so I'm not going to say that this run should or shouldn't be rejected for the GBA implementation.
Weatherton wrote:
Here's something to consider. Since the game receives GBA commands via the controller port, it's actually not necessary for the player to use a GBA to send the commands. The player could provide these commands through the controller port through other means (e.g. TASLink). We allow this for Super Mario World total control TAS. The game being TASed here is Wind Waker on GameCube. The GBA hardware is not strictly required from my perspective. Perhaps strict GBA emulation could be a separate branch though if this assumption really breaks things.
That's an interesting point that I hadn't considered before. In my opinion, the GBA counts as part of the hardware that runs Wind Waker because the game uploads a part of its code to the GBA, but what you say makes sense too.
I've discovered a potential problem in Dolphin. Basically, if you're using 4.0-3430 or newer, entering movie recording or playback by loading a savestate leaves Dolphin in a mode that is more desync-prone than if you had entered movie recording or playback in any other way. This problem isn't triggered if you already are recording or playing a movie when loading the savestate, but if you aren't, don't load savestates if you don't want desyncs.
Technical details are available at https://bugs.dolphin-emu.org/issues/9681
Okay, i think i found the problem. Using the newer dolphin version definitely made a difference. I just did a playthrough of the first level with lots of savestates and frame advance and it synced up perfectly on both of my computers. I'm going to send the .dtm to some other people and see if it works for them as well.
The more recent Dolphin version really helped out. I made two .dtm's that synced up on 4.0-9540 but i made 5 that didn't sync up on 4.0-9440. I'm not sure what they could have changed between those versions but it doesn't really matter to me as long as it works.
There have been no changes between 4.0-9440 and 4.0-9450 that can affect this. The only changes are to the readme file (which isn't even shipped with development builds), the installer (which isn't shipped with development builds either), and the default INIs for a few games that aren't GoldenEye 007. The reason must be something else, or maybe you just got lucky.
The Donkey Kong Country Returns bug that was posted earlier is supposed to be fixed now. Use Dolphin 4.0-9406 or newer, and don't load savestates from versions that are older than 4.0-9406.
When running Mario Party 5 (J) with Bios, it gives me the messages:
"IPL with unknown hash 8bdabbd4"
"IPL found in JAP directory. The disc might not be recognized"
I don't know what to make of this but I wanted to let you know.
Are you sure that you have a correct BIOS dump? I've seen that hash before, but the conclusion back then was that it isn't a recognized valid dump.
MUGG wrote:
JosJuice wrote:
When you're starting a TAS, the date and time will be set to the date and time of your computer. If you want to change the starting date and time (...) hex edit the time in the DTM at 0x081 (a 64-bit integer).
Is this the memory location?
What would I need to enter to get
Jan 1st 2000 0:00
Jan 1st 2000 0:01
Jan 1st 2000 1:00
Jan 1st 2001 0:00
Jan 1st 2002 0:00?
What is the time and date if I enter 0?
I believe it's little-endian Unix time, counting the number of seconds since Jan 1st 1970. Assuming that's correct, the time you highlighted in your screenshot is May 27th 2016, which seems very reasonable. The times you listed would be:
# i can change the cd to make the FMVs very short and not get the please insert CD screen
I hope you weren't planning on submitting a movie file for a (and I'm not exaggerating it) modded game? Other people would have to edit the FMV data exactly the way you did... If you want to shorten the video as a whole (not the recorded time), I'd suggest you do it in post instead. They've done that with a TAS of The Legend of Zelda: Majora's Mask also.
I think "change the cd" means to for instance eject disc 1 and insert disc 2, not to edit the data on the CD.
Someone else has made a report in the Dolphin forums about a similar problem in DKCR. According to it, the problem started happening in Dolphin 4.0-9269. Could you test if 4.0-9267 works?
EDIT: More up-to-date information is available here: https://bugs.dolphin-emu.org/issues/9570
4.0-9269 does not seem to be the cause of the problem. Could you tell me whether you've been using savestates?
The issue I was having with frame advance isn't present in 4.0-8965 unless Wii TASing is different than Gamecube TASing. If the issue still happens for that game on the newer version then I may wait until it's fixed in a future version of Dolphin.
The bug that makes frame advance unpause emulation randomly is still not fixed, but there's a fix (in PR 3794) that's close to done. You might want to wait until that fix is released.
It's tricky to know what the problem is unless we know in what situation it happens (e.g. when inserting an SD card, or possibly something like having the broadband adapter enabled...) or unless you can find out what part of the code is triggering the error. If you remove all of Dolphin's configuration (it's a folder in Documents called Dolphin Emulator) so you get the default configuration, does it still happen? Also, just because I can't think of anything else to ask, was the .dtm file recorded in the same Dolphin version as you're using? (Different Dolphin versions are generally not sync compatible.)
What was the purpose of no longer allowing the user to select the codec?
FFmpeg doesn't allow the user to supply their own codecs the way VFW does. We switched to FFmpeg for various reasons, like avoiding the audio desync that could happen for instance during certain loading screens, having one cross-platform way to dump instead of maintaining a separate one for Windows, and avoiding the various limitations of the ancient VFW.
1) It's recommended to have either a memory card loaded at all times, or not loaded at all. I haven't encountered a scenario where removing/inserting a memory card during movie recording, so it's a bit of unknown territory for me.
I'm not aware of anything in Dolphin that handles removing or inserting memory cards when playing back a movie, so I don't think it would work (unless you want to do it manually and get desyncs).
"Started the recording after Wii had checked the memory system"? Is that supposed to mean that you started recording from a savestate instead of from power-on?
Unfortunately there are a few problems with this game. The biggest problem being that this is one of the very few multi-disk Gamecube games. I'm not aware if Dolphin supports a single .dtm file for a multi-disk game. Please let me know if it does.
It does. I haven't used this functionality much myself, but in theory, you might run into these issues if you don't keep them in mind:
If you change disc and then save or load savestates within 1.03 seconds of emulated time (should be 62 frames at 60 fps), weird things might happen. The disc might not get inserted, you might get errors, you might get memory leaks, you might get memory corruption...
The filename of the second disc is stored in the DTM, and anyone who plays the DTM must use the exact same name for the second disc unless they hex edit the name in the DTM. There is a character limit on this (30 characters?)
I don't think you're able to change back to the first disc, but I'm not sure. Hopefully the game doesn't require it.
Other than that, there shouldn't be any problems. Just change disc, and Dolphin will save the disc change to the DTM.
What would I need to enter to get