Dolphin, the GameCube and Wii emulator - Forums

Jeremymd Wrote:That's accurate. Of course the phrase UNLESS THE GAME WANTS IT TO (E.G. LOADING) deserves to be underlined. How many times do you think Dolphin reads a 4gb DVD image file while you're playing it? I can confidently say LOTS. Whether or not Dolphin uses prefetching/caching(which it most likely does), it STILL needs to read the image file so a part of it can be placed in the cache. Makes sense, right? So your own statement proves you wrong.

You have proved nothing. Your theories are meaningless until you can substantiate them with evidence. You clearly have no idea how dolphins code works yet you have the nerve to tell us these things without even bothering to test it yourself. I have tried using RAMDisks to store both GC/Wii games as well as dolphins shader cache. It has never made any difference in performance for me. And I am not the only person on this forum who has tried to use ramdisks to improve performance. None of the other people who have ever tried it have noted any difference in performance at all. If you had used the forums search function to look this up before posting you would have already known that. But according to you we should ignore this evidence because your ideas make sense to you, even though you have no evidence to support your claims. So until you try it yourself and can show us that it actually improved your performance I must accept the conclusion that the current evidence actually supports.

Jeremymd Wrote:You were pressuring me for evidence to my "ridiculous claims". You are mistaken here. The pressure is on YOU. My ridiculous claims are actual performance theories which I know every intermediate computer enthusiast would agree to. And the only way for this to be wrong is for YOU to bring out YOUR evidence about Dolphin limiting image read speed to the actual Wii DVD read speed to prevent errors.

I cannot believe what I just read.

1. "Performance theories" are not evidence. Your hypothesis is not based on any statistical evidence or understanding of dolphins code.
2. The developers have stated that RAMdisks don't improve performance.
3. Every piece of evidence that has ever been conducted on this subject shows that RAMdisks do not improve performance.
4. "Intermediate computer enthusiasts" as you call them have no idea how emulation works and usually have done little or no actual programming.
5. There is an option called "Speed up Disk Transfer Rate" in the game properties for every game, which is disabled by default. You can look at it yourself if you don't believe me.
6. The developers write commits, comments, and blogs about this stuff. I'm not pulling this out of my ass.
7. The source code is also freely available for you to look at since this is an open source project. If you had actually bothered to look at the source code you would have already known that your hypothesis was wrong. The code for the asynchronous DVD drive access branch can be found on the projects googlecode page here: http://code.google.com/p/dolphin-emu/source/list?name=async-dvd

The next time that you get one of these ideas:
1. Test it yourself first
2. Use the forums search function to look up other posts about it
3. Look up the source code on googlecode. If you can't read the code because you're not a programmer then don't pretend that you know how it works.
4. Go on our IRC channel and ask the developers yourself.

I can promise you that if you had done any one of those 4 things you would not have made that post.

Jeremymd Wrote:Lastly, whether your article is true or not, I want you to know... It's a win/win for me. It's either I'm right or I learn something new.

This is not an article. This is a post.

Jeremymd Wrote:But for you, it's either you win or you're just a plain offensive moron.

Sometimes I wonder why I bother correcting peoples mistakes. Some people just don't want to be told that they are wrong, please don't be one of those people.

Also please learn to use the quote tags when quoting someone.

+1 NaturalViolence.

To be fair, running games from a ramdisk or an SSD drive should help a bit with stuttering and performance drops as long as async-dvd is not used. Most likely no impact at all on performance could be seen - most of the reads are linear reads anyway (because GC uses optical discs, which perform well only with linear reads) and these are made almost free by the caching subsystem of your OS.

It is commonly accepted that using a RAMDisk MAY reduce stuttering but will not improve performance. Yet despite the fact that this is commonly accepted nobody that has actually tried it has noted any difference in stuttering at all, perceivable or measurable (including myself). I have a number of areas in several games that exhibit small, moderate, or even severe stuttering and using a RAMDisk has not made one bit of difference for me in any of them. Back when lots of forum users were complaining about stuttering (maybe they still are I haven't visited the support forum in over a year) we used to tell them to use a RAMDisk, it was very common advice. Yet not one of them reported any improvement from trying it. This is why I am skeptical that it reduces stuttering at all even though it should in theory.

Speaking of which how is the work you're doing on the async-dvd branch coming along?

hm whats about option #2? theres only a picture..?

i dont understand #1..first you kill explorer.exe and then you start it again?

so the .bat file shuts down explorer.exe and sidebar.exe when dolphin is started and restarts em when dolphin is shut down, yeah?..hm

maybe you should add that this guide is for notebooks..intel mobile core 2 duo..

(08-16-2012, 02:57 PM)NaturalViolence Wrote: [ -> ]Speaking of which how is the work you're doing on the async-dvd branch coming along?

Need to make it an option as it makes DVD reading time unpredictable (TAS runners would not like it ). I'd like to merge it to master before 4.0 with the option disabled by default, but I don't really have much time in between work, webdev and server administration for the new Dolphin website.

doing option #1, nothing happened, except that explorer.exe shut down, and my desktop was blank.. -_-

restarting explorer.exe, the icons on the desktop returned, but the task bar keeps vanished..u know how much that sucks?

how about a description to restore it..?

is that a joke?

i mean, explorer.exe contains the desktop icons AND the task bar, but task bar doesnt appear anymore ffs.

(yeah i can navigate without the task bar but it sucks..)

(08-16-2012, 02:18 AM)dannzen Wrote: [ -> ]could someone close this fucking thread now?
100% sneaky oil

Reducing stuttering IS a performance improvement, isn't it?

And like I said, I know enough to suppose that if ever there was a performance improvement, it would be most likely negligible.

And if you're gonna correct someone, you can just state the facts and not have to bash the idea like it's the most ridiculous idea you've ever heard. That's just plain rude. You know who you are.

Anyway, I'm over that. I just wanted to share what little I knew to help out.

Speaking of help, I spent a whole day trying to find the fastest working Dolphin build for Monster Hunter Tri. When I've almost given up, Eureka!

r5474

I don't know if what I downloaded was the actual r5474 in the Dolphin archives, but I do know is that there is a TREMENDOUS difference.

I get an average of 19-24 fps wherever in the map using the Dolphin 3 build(Dolphin-win-x64-v3.0-735). With what I found, I get to play at full speed 85-95% of the time. I'm talking 27-30 fps, only slowing down with a lot of monsters.

Of course, I figure the latest builds are sacrificing performance for stability, and that makes sense. But wouldn't it be great if the devs here made optimal custom builds for each game and posted them here. I know that'd be a lot of work. Just wishful thinking, I guess.

Quote:Reducing stuttering IS a performance improvement, isn't it?

This depends on how you look at it.

From a technical standpoint stuttering refers to variations in response times. Inconsistent performance would be considered stuttering (even if the average was high) while consistent performance would not (even if that consistent performance was low). So technically it's possible to reduce stuttering without improving performance if the maximum performance goes down as a result (therefore the delta remains the same).

In our situation though, yes. Reducing stuttering in this context would mean that you have improved the minimum performance without changing the maximum performance, which means the average should be higher.

However while technically incorrect it is commonly accepted that when someone says that something improved their performance that it improved their performance in a observable or measurable way. I mean if you can't actually prove that something improved your performance how do you even know that it did? And why would you even bother telling someone that it did?

To use an example. If I went around telling people that a certain algorithm improved performance with FXAA then posted results that showed no improvement people would laugh at me. They would then ask me how I knew that it improved performance if I could not gather any measurements to demonstrate it now matter how accurate my measurements were. If I then responded with "well it should in theory" they would then laugh even harder. This subject is called computer science for a reason. We need to approach these things in a scientific manner if we expect anything we say to be reliable or meaningful.

Quote:And like I said, I know enough to suppose that if ever there was a performance improvement, it would be most likely negligible.

Not just negligible, unmeasurable. As in even if it did improve performance you wouldn't be able to prove it even though you can measure performance down to 1/6000th (or 1/60th of a percent, nearly 0.001%).

Quote:And if you're gonna correct someone, you can just state the facts and not have to bash the idea like it's the most ridiculous idea you've ever heard. That's just plain rude. You know who you are.

I did state them. And I continue to stand by the statements I made. Some of that stuff you chose to post was absolutely ridiculous on a level that left me baffled. You really should not attempt to come up with theories about things that you clearly don't understand without doing any research or collecting any data. That's just common sense.

Quote:Of course, I figure the latest builds are sacrificing performance for accuracy, and that makes sense.

Fixed that for you.

Quote:But wouldn't it be great if the devs here made optimal custom builds for each game and posted them here. I know that'd be a lot of work. Just wishful thinking, I guess.

No. This idea has been discussed to death. I would recommend that you use the forum search function to look this up.

The short answer: Making a custom build for each game would basically defeat the entire point of having an emulator (why emulate the hardware when we have hacks?). It would be horribly complicated and turn the code into a hack filled mess that would be nearly impossible to maintain, change, or improve in any way. It would result in a piece of software with many different versions that could only run a small number of games well. The point of an emulator is to accurately mimic the behavior of the hardware so that any piece of software designed for that hardware will run and produce the intended results.

I think we've come to the end of the road here.

Closed.