Posts for JMC47

1 2 3 4 5
Posted: 9/2/2014 7:00 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
I don't know how much console loads differ between consoles actually. I to know on Wind Waker the difference between a white wii and a red wii amounted to a sizeable difference after just a few loads (less than a dozen) but because Metroid Prime is constantly streaming data, I assumed it would be much more. Only have a white Wii and an old GameCube to test, and the load times vary even on the same console loading the same thing, so finding an exact amount would be annoyingly difficult. Dolphin's timings were based off of several games being played on a white wii, and I believed Metroid Prime to be one of those games (it was one that was tested after the changes, as I have mentioned.) Red Wii has far faster disc loading times (in Wind Waker, as I mentioned) and I believe differences in GC models/age of laser can affect load times as well. No idea how close it is to any particular console; but of course the Prime series with streaming data would be one of the most difficult to time. It gets even more complicated technically, we don't simulate the read speed based on where the data is on the disc without magic. (at least, I don't think we possibly could... someone please correct me if I'm wrong.)
Posted: 9/1/2014 11:23 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
I guess I should clarify that one of the primary goals of the disc-transfer rate branch (at least from my part testing/relaying information) was to make sure Metroid Prime acted as if it were on console. I did time Metroid Prime compared to console, and a Taser did verify that early icebeam worked on emulator, so we did deem it "fixed." There's not really much more that can be done to get globally perfect disc times. The sad fact is that the Wii and GameCube would load as fast as Dolphin with no load times if they weren't limited by media; which is one of the reasons why devs once said there was no point to accurately implement loading times. This is a pretty fair compromise right now. Games should load similar to console, the glitches in Metroid Prime should work on Dolphin (I'd hope) and it should be a relatively similar experience to viewers, tasers, and speedrunners viewing the game regardless of emulator or console. Maybe someday it will get better; for years everyone said loading times would never get implemented at all! I remain hopeful that it'll be up to the standards that everyone expects.
Posted: 9/1/2014 3:54 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Understandable. I don't think anyone really claimed they were perfect, only that they were now emulated rather than instantly loading everything. Better, but not fixed enough is unfortunate, as I don't have enough technical knowhow to try and make them any better myself. And, there's the case of other games being affected adversely.
Posted: 9/1/2014 1:55 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
This is easily explainable. You didn't say what revision of Dolphin you were using, but I'm going to assume the latest as of when that video was posted, so, yeah. Perfect load times are impossible because different consoles/drives have different read speeds. It's never going to be identical to console. Every revision of the GameCube/Wii and even sometimes between revisions have different enough parts to affect load times. What we did for verifying Metroid Prime as working properly with load times was try and make sure two things were happening. 1: Instant load times weren't happening 2: And we had a trick that wasn't possible on Dolphin verified as working. (Early IceBeam, if I remember correctly) We can fairly easily slowdown Dolphin's loading even more (assuming it works the way I think it does) but no matter what we do, different games will trigger different things. By accurate load times, we say that realistically, some revision of the console should get load times like this in most games. Depending on how games load though, it's never going to be exactly like every revision of the console. I hope that explains things to a reasonable degree.
Posted: 8/24/2014 7:18 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
As of 4.0-2729 Dolphin now had accurate fmuls/fmadd emulation in the JIT and Interpreter. What does that mean? It more or less means that collision detection (Super Mario Galaxy 2, getting stuck on some corners for example) and physics issues (Mario Kart Wii/Double Dash with landing/turning) should be accurate to console, rather than having their own set of issues for Dolphin. This should affect a ton of games in a very, very positive way. Clipping tricks that didn't work on Dolphin should work, physics should be more accurate, and of course, games with replay functionality will sync up with console. We've verified replays in Donkey Kong Country Returns (Superplay functionality), along with Mario Kart Wii, Double Dash!!, Super Smash Bros Brawl and F-Zero GX (Replay functionality in each game) with replays recorded on console played on emulator successfully, and then a replay recorded on emulator verified on console. Less exciting for TASers is that this also means that dolphin in theory should will sync up in lockstep games with Console, such as Wifi mode in Super Smash Bros. Brawl, and BBA titles such as Kirby Air Ride and Mario Kart Double Dash!!
Posted: 8/19/2014 6:07 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Pull Request 834 was updated. I recorded a replay on my GameCube a few weeks ago, and it just synced in that pull request. When Dolphin gets that merged, physics between console and emulator will be identical! https://github.com/dolphin-emu/dolphin/pull/834 Everyone should be happy with this! So, actually to have some fun, I did more testing. In 4.0, loading an F-Zero GX replay recorded on console the screen immediately whited out and returned to the menu upon loading said replay. in 4.0-2012, half of the first lap worked before my car flew off the track. In this build now, the replay syncs all the way through!
Posted: 8/19/2014 5:02 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Namely, this instruction right here +u64 MultiplySinglePrecision(u64 double_a, u64 double_b) +{ +#ifdef VERY_ACCURATE_FP + u64 early_result; + if (PreprocessInput(double_a, double_b, early_result, PreprocessMultiplication)) + return RoundSpecialToSingle(early_result); + + FPTemp a = DecomposeDouble(double_a); + FPTemp b = DecomposeDouble(double_b); + FPTemp result = MulFPTemp(a, b, /*single*/true); + u64 result_double = RoundFPTempToSingle(result); + + return result_double; +#else + SetFI(0); + FPSCR.FR = 0; + return DoubleToU64(ForceSingle(U64ToDouble(double_a) * U64ToDouble(double_b))); +#endif https://github.com/magumagu/dolphin/compare/softfp#diff-a0d60abeb990e854a60c0d1e0d417f0eR737 Master will be getting the main physics fixes though very soon. It'll make physics hardware accurate in Super Smash Bros. Brawl, Mario Kart: Double Dash, Mario Kart Wii, Donkey Kong Country and others games. https://github.com/dolphin-emu/dolphin/pull/834 Hopefully now that we narrowed down F-Zero GX to one instruction, it won't be long before we have hardware accurate physics in master for it as well!
Posted: 7/30/2014 10:00 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
hegyak: I recommend just making a modified build, and reverting the Sonic Unleashed Hack removal. There's no sign of it being fixed any time soon unfortunately. Because it's only a visual change, it would sync up with normal versions of Dolphin afaik; but you should test it with and without the hack in before anything else.
Posted: 7/29/2014 10:01 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
The softFP branch (when you disable certain JIT functions) by magumagu makes it so anything I record in Dolphin (timetrial/replay/ghost, etc.) will load up and play back correctly on the Nintendo GameCube. This should mean that you could record the most badass timetrial TAS, and then load it on the GameCube and it won't desync. Currently, physics are not correct, and desync on console.
Posted: 7/27/2014 6:57 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
phire chased down the bug with the collision. It appears to be a bug in the non-SSE4.1 codepath. It will be fixed as soon as the code is reviewed. Thanks for the report!
Posted: 7/26/2014 7:07 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
It's not my program, but I can post the test.dol for people to try on their Wiis with various memory cards. https://dl.dropboxusercontent.com/u/484730/MemCardDemo%283%29.dol This is configured for Wiis, and won't work with Transmit-Mii, you have to manually boot it from the homebrew channel. I've tested my memory cards, but I'd gladly add more to the data if we could get it. The average is broken on the test program, you have to kind of calculate the average yourself. Getting it to run on Dolphin is pretty tough; so I'd recommend people mostly test it on hardware for right now until it's cleaned up.
Posted: 7/25/2014 10:59 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Write speeds are very, very close to accurate. Read speeds are really slow currently. No idea what's wrong yet.
Posted: 7/25/2014 4:51 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Totalnerd provided me with some homebrew, and I ran the tests for him. https://docs.google.com/spreadsheets/d/1W2BfG27hU7kKPvPIhiHNREb6z7GT2d2zZeKK53ph6lE/edit#gid=0 Something is incredibly broken in how Dolphin handles things, meaning that instant complete (old memcard methods) were hiding some serious problems in Dolphin. Because of this I don't know how long until we can get the read/write speeds to be much closer. It is troubling, especially when we thought things were getting better. To be fair, the new timings are more accurate...
Posted: 7/21/2014 2:37 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Actually, we were aware that certain third party cards can break saving in WW-J; the ultimate goal is to figure out how the GameCube detects memory cards so that, say, if you have a memory card that identifies itself as one of the faster ones, Dolphin will do that. The thing is that Dolphin was instantly completing Reads/Writes, which means that it WAS NOT handling like real GameCube memory cards, regardless of how it looked. It's possible that beyond a certain point the game stops working. I'd honestly like to find out how to do that. Right now, Dolphin's read speeds seem a little slow, so there will likely be a second merge to do the same thing to fix read speeds further. And then the plan would be, assuming we can get enough hardware testing, figure out how the GameCube polls memory card speed in the games that support it. According to the information we had, only late GameCube games supported the fast-read with Samsung hardware memory cards. The fact WW-J can support it is news to me. Do you know which memory card Cosmo is using? Has he ever mentioned it? It may be worth investigating. edit: I figured out through hardware testing that the stupidly fast memory card is a Max Drive Pro (64mbit.) I just happened to have one lying around from my younger days. It was totally used for memcard transfers to PC, nothing else. Really. But anyway, I decided to format it for NTSC-J, load up my Wind Waker -J on my Wii and see what happened. Yup, I reproduced the WW-J hang. Thank you for pointing it out to me. We're now going to accurately implement both average memcard read/write speeds, and likely an option to make the memcards the fastest known memcards recorded. If something stupid can happen on console, I don't see why it shouldn't happen on emulator! But seriously, this probably opens the door for a lot more testing, and if people here would like to use faster memcards and we have data supporting that console would do it, there's nothing stopping it. Before this, we were going off of in game timings and now it will be measured and tested.
Posted: 7/19/2014 10:31 PM
Post subject: As of 4.0-2227, Dolphin better emulates GC Memcard speeds
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
As of 4.0-2227 (https://dolphin-emu.org/download/dev/963e1a698cbeaa976a7f8e8020880a50267ecd69/) GameCube games will display much more accurate behavior when reading/writing memory cards. This will result in memory card timings to be a lot different than before the merge. Here's an example: MVP 2004 Dynasty mode Console: 32.4-32.8 seconds Old Memcard Timings: 4.2 - 4.38 seconds New Memcard Timings: 32.8 - 33 seconds This also fixes a few longstanding issues that were afflicting games, including The Legend of Zelda: The Wind Waker (NTSC-J) softlocking on saving. That will no longer happen. As well, Gauntlet: Dark Legacy sometimes did not save as well during TAS/Netplay/SingleCore situations, and that should be remedied.
Posted: 7/9/2014 4:37 PM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
The hang I'm referring to is that every time you save in the Japanese version, the game hangs. It means stuff like saving/quitting to warp (as used in OoT, for instance) couldn't be used. I do know speedrunners have requested this fixed, but I didn't know if it affected the TAS directly. The thing about using savestates and then using in game save was fixed a little while ago. That should no longer have issues.
Posted: 7/9/2014 4:59 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
I don't know how much interest there is in using the japanese version of Wind Waker for TASing (or if it was used previously) but there is a game breaking glitch with saving in Dolphin There's a pull request with mostly guessed data/timings on memory card saving that makes memory card writes much more accurate to console. It fixes the hang when saving in Wind Waker (J) which should make it viable for TASing if its preferred. Pull Request: https://github.com/dolphin-emu/dolphin/pull/581 Buildbot build: https://dl.dolphin-emu.org/prs/pr-581-dolphin-latest-x64.7z
Posted: 7/4/2014 10:12 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Yeah, it's risky and saves a bit of time. Perfect for a TAS :) It didn't work in Dolphin until very recently.
Posted: 7/3/2014 10:43 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Oh, I've seen it mostly in the J speedruns, but the trick is possible in U.S. at least the wall clip part, and the cutscene triggers from the same spot. I don't think it's done in single segment due to being risky.
Posted: 7/3/2014 1:52 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Scrubbing Serena Beach has been accurate in Dolphin since 4.0. 4.0-1706 fixed the cutscene skip. You do the cutscene skip by killing yourself as you get in range of the cutscene. In Dolphin when clipping out of bounds to perform it, there used to be an invisible wall. I got it on my first try after this build was released. For more information, it was featured in the May progress report and the build can be found here - https://dolphin-emu.org/download/dev/cffa848b9960bcf3dd7a5f3dfd8cdbe417b6ec55/
Posted: 7/2/2014 2:56 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
Scrubbing Serena Beach works properly in Dolphin now, and has for quite a while. Bad video card settings (forcing anti-aliasing, for instance) can cause problems, and certain video cards/drivers can't up the IR without the goop glitching out. The cutscene skip used in speedruns involving killing yourself by fazing through one of the roofs on Delfino plaza should work now as well. I'd use very, very recent versions of Dolphin, though, as it was fixed within the last 300 revisions.
Posted: 5/18/2014 6:46 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
It was the hardware that the dev who worked on it had a White Wii for testing, as did everyone else. Adding loading times was already a hard sell; adding options, and making it more confusing would have made it even harder to sell to users and developers alike. Because magumagu made it simple, it helped get it into the emulator. If later on people make more options, it's plausible that it could be made faster/slower. We're talking about very, small differences though.
Posted: 5/18/2014 4:39 AM
Post subject: Dolphin now emulates loading times more accurately
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
As of revision 4.0-1592 Dolphin will properly emulate load times in games. Because hardware varies, the disc read has been geared to work about the speed of a white Nintendo Wii. I tested this in about 25 GameCube games compared to my White Wii, and while there were slight variations (even on second runs, the console loads would vary) the emulator performed admirably This should greatly affect TASes of the Metroid Prime games, as well as make game times much more accurate to that of console on every other game.
Posted: 5/9/2014 4:28 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
I merely do a lot of testing, I'm not really a programmer and I can't pretend to understand the GameCube/Wii as most of the people who work on Dolphin, but I'll do my best. From what I can tell, there's no exact correct answer on what load times should be. Instead of doing that, I believe magumagu just emulates a disc drive and all the main components of it, and used a Wii for comparisons. I'm sure he got actual numbers and stuff from having great knowledge of the console, but, I can't be certain of that. What was tripping Dolphin up before was seek times, the disc drive's cache, etc; it made it so no matter how slow we made the disc loading speeds, it was faster due to not having other components of loading! As for the SMG/SMG2 cutscenes via SD card, it's probably just not loading fast enough and slowing down. Dolphin doesn't have that problem (I'd assume, I haven't tested every game. We did have problems with Gauntlet: Dark Legacy in an earlier revision of this branch) because it's designed to read as fast as a white Wii as of this merge. I hope this answers your questions, if you absolutely want more correct or detailed answers, feel free to join the #dolphin-emu IRC on freenode sometime.
Posted: 5/9/2014 3:22 AM
Quote
JMC47
Experienced Forum User
Joined: 5/8/2014
Posts: 125
This branch affects every game, I tested most of my gamecube library between Dolphin and a white Wii (and sometimes my Launch Day GameCube too), and they averaged out to be about the same. Considering some Wiis/GCs have different disc drives, Dolphin may be a bit slower than the fastest of the console variants. As demonstrated before in Wind Waker, different Wiis/GCs will produce different loadtimes, this branch, when it is merged, should put Dolphin right around where the white Wii is on most load times. Edit: I feel I should mention that Dolphin has been removing most single game hacks and been moving heavily in an accuracy based direction. Instead of fixing games, they've been focusing on finding things the emulator does wrong (whether it be through hardware tests, crash logs, etc.) and fixing it based on heavy testing. The AX-HLE merger, tev_fixes_new, and pretty much any other modern big change won't get merged if it's a game specific hack.
1 2 3 4 5