You can make an input file that recreates your save file. That is called a verification movie and it basically provides a save file that can be verified by TASVideos. I'm sure the staff can help you with that.
Would I need it if I could just upload the memory card file? It is just a save downloaded from gamefaqs which had all the levels completed.
Yes, a verification movie is required for all submissions that start from a save file.
I think starting from a point that isn't power on also is enough to disqualify the movie file.
I wonder if that would count as performing/displaying a copyrighted work in public... In that case, I believe you would need permission from the copyright holder.
As in, lag related desyncs. Like I heard that the reason metroid prime gamecube desynced was because eventually the emulator created lag while playing back a movie.
If an emulator can desync due to timing differences, it can desync regardless of how fast your computer is. Having a faster computer doesn't really help with anything other than simply running games faster.
Does this happen with all versions of Dolphin or only with 5.0?
In general, the older the version is, the worse the sync will be. Some of the most important improvements include 4.0-3595 (it was basically worthless before this), 4.0-3872 (non-Windows only), and 4.0-8634 (Windows only). The improvements in 5.0-99 and 5.0-280 also help in some cases, but can technically be corrected for manually.
Please be careful with the version numbers – 5.0 is very different from 5.0-10167.
Dimon12321 wrote:
Also I found no dumping issues in 5.0-8715. Your 5.0-10167 movies should playback well on it.
No, they will very likely desync. Just looking a few weeks back into the changelog, 5.0-10039 alters the timing. There might be additional changes that affect the timing, I haven't checked.
Hello TasVideos friends, how are you? Finally I solved the previous problems and I made excellent encodings again. As I said, I bought a new computer (yes, a PC Gamer with excellent settings for current games) and for the first time I was able to play and record a movie with Dolphin-master-5.0-10167-x64. The movie synchronizes perfectly, but making the encode is extremely labor intensive, because when I select the Dump Frames and Dump Audio options the video comes out with the completely ugly and dirty image and looks that I put the best image settings possible to make the image come out perfect .
What should I do to make the video look perfect after it's dumped? Could someone explain me in an easy way? I await an answer. Thank you!
I'm not sure exactly what you mean by "completely ugly and dirty", but perhaps you are using a too low bitrate when dumping, since that is Dolphin's default settings. Either enable the lossless codec (this can be done in the GUI) or increase the dumping bitrate (this cannot be done in the GUI - the entry in GFX.ini is called BitrateKbps).
The YouTube embed on the site is too small, in particular for TASes of 3D games.
You can make it fullscreen.
Yes, but it isn't uncommon for me to switch tabs and do other things while I'm watching, and I find it more convenient to use the size that's on the YouTube page than having to go in and out of fullscreen every now and then.
YouTube, on the YouTube site. The YouTube embed on the site is too small, in particular for TASes of 3D games. I occasionally download MKVs if there's a TAS I think I'll want to look at again in the future, but I don't think I've ever watched a TAS in an emulator. It's just too inconvenient for me, since I don't have emulators for most systems set up and don't have copies all of the games that I want to watch TASes of, or have copies that are the wrong revision or region.
For the reference, the version cddb83f that is mentioned in the submission text is the same as 5.0-9279: https://dolphin-emu.org/download/dev/cddb83fd06cb5436e24ac5de9e578806fd7168a4/
It is unfortunate that the Ubuntu PPA builds are marked "dirty" in the version string. I'm not sure if they are applying some kind of patch to Dolphin when building, but either way, I wouldn't imagine they'd be adding any patches that break sync compatibility.
Dolphin did not start outputting the correct aspect ratio until 4.0-7138. The Zelda Edition fork that this TAS uses is based on 4.0-5371 (if the source code is https://github.com/dragonbane0/dolphin, that is – the submission does not seem to contain a link to it, so I'm not entirely sure if it matches the executable that was linked to in the submission). So it would not surprise me if the video files that this version of Dolphin outputs are using an aspect ratio that is slightly wrong. Resizing to exactly 4:3 might not necessarily be accurate either – the active area of the output of GC/Wii games is often slightly off from either 4:3 or 16:9.
Please note that talking about how many pixels wide the game's video output is can be a bit misleading if you don't specify what kind of pixels you're talking about. The game's internal rendering uses non-square pixels, like with many other GC/Wii games, so the internal resolution cannot be directly compared to the resolution of an image that has been stretched have a correct aspect ratio when using square pixels. Dolphin aims to output the latter in framedumps, at least if you're using 4.0-7138 or later.
TheCoreyBurton wrote:
Habreno wrote:
TP's resolution, after cropping out the overscan, is 612px by 448px
This is interesting and likely responsible for the discrepancy. The footage you see on the encodes hasn't been cropped or adjusted (beyond what I mentioned above). It was presented without overscan.
Dolphin automatically crops out parts of the image that are not configured by the game as being usable.
You will get desyncs in Dolphin if you trim disc images (i.e. move files around on the disc), and I think there might be a desync risk from editing the partition table of Wii games (which many WBFS writers do by default), but just blanking out unused data or using lossless compression shouldn't affect sync. CHD is lossless, right?
If the game doesn't use bounding box or some other GPU readback feature like EFB copies to RAM or EFB access from CPU (Super Mario Sunshine says hi), you can use whatever hardware, backend and enhancements you want without worrying about desyncs.
How can you tell if a game uses one of those features?
The Dolphin Wiki has the information about what games use what features, if any.
It actually doesn't have that information for the most part. All of the wiki's recommended settings assume that you already have the settings that are forced by the default game INIs that ship with Dolphin. So what you should do instead is to look for the default game INI for your game: https://github.com/dolphin-emu/dolphin/tree/master/Data/Sys/GameSettings
Bounding Box: Newer versions of Dolphin use hardware optimized implementations of bounding box, which produce different results at different resolutions and graphical settings, as well as being tied to specific hardware. To avoid this while using the latest versions, use the Direct3D backend with Microsoft Basic Renderer (as to be hardware agnostic), or use version 4.0-5124 or older to use the older software based bounding box solution.
It's been a couple years since the OP was made. Has there been any change in this front? Has anybody asked the Dolphin team to restore the software based bounding box solution? Reason that I ask is that my hardware is too slow to run Dolphin full speed with Microsoft Basic Renderer. Even using Intel graphics is a lot faster (my laptop uses i5-7300HQ and Nvidia Geforce 1050)
No, nothing has changed.
But keep in mind that only a very small number of games use bounding box:
Disney's Hide & Sneak
Disney's Magical Mirror starring Mickey Mouse
Disney's Mickey & Minnie Trick & Chase
Paper Mario: The Thousand-Year Door
Speed Challenge: Jacques Villeneuve's Racing Vision
Super Paper Mario
Ultimate Spider-Man
If the game doesn't use bounding box or some other GPU readback feature like EFB copies to RAM or EFB access from CPU (Super Mario Sunshine says hi), you can use whatever hardware, backend and enhancements you want without worrying about desyncs.
setting the RTC to be the same time on boot-up (On both Dolphin 5.0-266 and 5.0-424, the versions that I tried)
That shouldn't be needed. When you load a movie, Dolphin will automatically set the RTC to the value that was in use when the movie was created, even in versions of Dolphin that are older than when the "custom RTC" feature was introduced. But that you've been doing that shouldn't cause any desyncs.
DyllonStej wrote:
Despite having all of the TAS-unsafe settings off (Including Dual Core, Idle Skipping, and any Graphics hacks)
Turning off any of the following graphic hacks can actually increase your chance of getting desyncs (though such desyncs will usually only show up when you try to play back the movie on a computer with a different graphics card or when using different graphical enhancements):
Skip EFB Access from CPU
Store EFB Copies to Texture Only
Store XFB Copies to Texture Only (in older versions of Dolphin, turning this off is equivalent to setting XFB to Real)
Disable Bounding Box
Also, since you're using a version of Dolphin that's older than 5.0-1223, you need to keep this bug in mind (or preferably, update to a newer version of Dolphin): http://tasvideos.org/forum/viewtopic.php?p=436961#436961
I hope the information above will help, but chances are that the desyncs are caused by some unknown phenomenon that nobody knows what to do about...
1. Path settings: I found that some default paths is "/My Documents/Dolphin Emulator". Maybe it's convenient to the user who uses many version. But it is not for me if I want to use the same version to playback two different movies. How could I change the path? And which file should I modify?
There is an easy way to make Dolphin save its data in a local folder: Create a file named portable.txt in the same folder as Dolphin.exe.
Soig wrote:
2. .lua file: Is it possible to use .lua file in dolphin? It is interesting to add the input into video. Such as FCEUX.
It should be possible to fake a GBA in that way for FFCC too, but first someone would need to implement the required game-specific code. And keep in mind that I don't know if this kind of faked input is acceptable for TASVideos submissions, and that the code won't get merged into upstream Dolphin because it's a per-game hack.
I'm still seeing the original Photobucket images on that page, they haven't turned into the large "Please Upgrade" images for me. Should they be replaced anyway?
They look like "Please Upgrade" images for me. Maybe your browser has cached the old versions.
Should they ever reach a "cap" in size? Like, is there a point in a TAS where a .sav should stop getting bigger and/or slow down their size gains?
Yeah, after a certain point, they shouldn't grow much anymore. That's most likely the point where you get in-game, but there's no hard rule. The size depends on how compressible the data in the console's RAM is, so when the RAM is mostly empty because the game hasn't loaded much data yet, the savestates are smaller.
GameCube savestates should always stay below 50 MiB and Wii savestates should probably stay below 100 MiB, but they'll usually be significantly smaller than that because they're stored in a compressed format.
Sorry if I ask because this must have been asked before or somewhere else, but what does the code for debug mode on Dolphin look like on Windows? I can't find any useful stuff on the internet.
If you mean the debug mode you get by running Dolphin with a /d flag, most of the code is here: https://github.com/dolphin-emu/dolphin/tree/master/Source/Core/DolphinWX/Debugger
EDIT: Or are you asking how to launch the debug mode on Windows? If so, the answer is to write the following in cmd when the folder is set to the folder that Dolphin is in: Dolphin.exe /d
