Since the Dolphin team puts playability above accuracy, the emulator can keep moving the goalposts towards perfect emulation, while still remembering that an unplayable emulator does nothing to preserve the source material.
Compare this to the MAME situation, where most early 3d arcade games are completely unplayable, and will remain like this for the foreseeable future, because the way computers are going, there is no way in hell we'll be able to emulate those old, custom graphics cards with full accuracy and full speed using only general purpose CPUs.
Last time I messed around with MAME pretty much everything which was playable ran at full speed, even stuff like STV, Namco System 22, and Seattle based games. This was on my 2600K running at 4GHz, which isn't exactly the latest and greatest.
From what I understand the most demanding thing to emulate isn't the 3D hardware anyways, it's the high clock rate CPUs. Most of the latest 3D hardware supported by MAME is implemented with ASICs which have a relatively high level interface. This allows the emulation to be pretty highly optimized since the low-level details aren't visible to the game software anyways. CPUs are a whole different story though. There you are stuck emulating individual instructions which gets pretty hairy when the CPU you're emulating can do 200+ MIPS.
It's interesting that this has ramifications for the emulated console(s) within the console. On one hand, it's an amazing technological achievement to emulate a system well-enough that it can emulate another. On the other hand, however, it's staggeringly inefficient. Emulating a system is inefficient, but it makes sense because it prevents the need to keep all kinds of hardware 0n hand. Emulating a system that emulates a system compounds the inefficiency and is unnecessary, but is a really cool achievement.
Fun fact: Dolphin emulates some N64 games better than current PC N64 emulators do. For example, Mario Tennis (N64) is considered very difficult to emulate, but the official Nintendo emulator running in Dolphin has almost no problem with it!
It's also really lucky that the Gamecube GPU, released well over 10 years ago, matches extremely well to the modern GPU pipeline.
Compare this with the PS2, which has a bunch of crazy programmable coprocessors to build an extremely flexible but hard-to-emulate system.
It's probably no coincidence, given that it was developed by ex-SGI engineers who founded their own company, ArtX, who got bought out by ATI to develop the R300, one of the first modern programmable GPUs.
I bloody love all content on this blog, the hex math fail, the mobile drivers, always the content is great. Off to bed to read this on my tablet. Thanks for the link
As a matter of fact, AMD GPUs are using the floating point ALUs to perform integer math (note: this might have changed with their GCN architecture). However, given that the mantissa of IEEE floats is just 24 bits long, the ALU also can just handle 24 bits, which is not sufficient for full 32 bit math. Hence, for "true" integer arithmetic, the ALUs need to be double-pumped or emulated via floats (i.e. the dirty tricks which we avoided need to be done in the driver instead - but at this stage it can actually be done reliably, even if it's still ugly).
I assume the situation is similar for Nvidia GPUs. Either way both vendors said their GPUs aren't designed for optimal integer performance - so that's why we expect the performance drawbacks of integer usage to become less and less of an issue in the future.
Hah! I hadn't played Twilight Princess for many years before playing playing it on Dolphin, so I actually thought Midna was supposed to have those lava-arms!
Being on a mac, I'm tied to OpenGL so I'm hoping this doesn't hurt me too much.
In the first equation (it admits it's wrong), I plug in 1 and get 0.00390625.
In the second equation, I plug in 1 and get -0.992188.
I think the answer is supposed to still be 1, because there should be no overflow until it is 256.
I thought maybe I was misunderstanding and the equation isn't just to handle overflows but is supposed to add 1 then handle overflows. So I plugged in 0 into the equations and they both outputted 0. So they aren't trying to add 1.
Wouldn't the correct equation be frac(value / 256.0) * 256.0 ?
That was actually a mistake in the article. I had exchanged 255 and 256 accidently. It's fixed now (and should hopefully make sense), thanks for the finding :)
EDIT: So uh, as a quick example of where things go REALLY wrong with the first equation - try value=-0.0000001 ;)
The value is encoded as a fraction out of 256. So 1 is 1/256, up to 255 being 255/256.
It's still not completely correct, some values passed through that function come back as +/- 1e-16 and 255/256 becomes 0. Showing us again how floats are bloody hard to work with for the average programmer.
Edit: saw neobrain's comment, please disregard my post. Still, shouldn't there be a round in there too?
Very cool. I have to wonder if they've ever been contacted by Nintendo over this though - many recent-ish games have been in a playable state for several years now and you'd think functional Wii emulation attract negative attention.
On a related note, the branch browser feature of the Download Page [1] is completely broken, displaying only "Branch list" in place of what I assume should be an actual branch list.
Yeah, we recently moved away from Google Code to GitHub and updating the website hasn't been in my priorities. We moved from a "branches in the main repository" model to a more classic, GitHub style, "everyone has his fork" model, so tracking branches it not really even possible anymore.
I'll probably just remove this link from the downloads page.
[+] [-] hibikir|12 years ago|reply
Compare this to the MAME situation, where most early 3d arcade games are completely unplayable, and will remain like this for the foreseeable future, because the way computers are going, there is no way in hell we'll be able to emulate those old, custom graphics cards with full accuracy and full speed using only general purpose CPUs.
[+] [-] magila|12 years ago|reply
From what I understand the most demanding thing to emulate isn't the 3D hardware anyways, it's the high clock rate CPUs. Most of the latest 3D hardware supported by MAME is implemented with ASICs which have a relatively high level interface. This allows the emulation to be pretty highly optimized since the low-level details aren't visible to the game software anyways. CPUs are a whole different story though. There you are stuck emulating individual instructions which gets pretty hairy when the CPU you're emulating can do 200+ MIPS.
[+] [-] sadfnjksdf|12 years ago|reply
I see your logic there. Claim there is no way in hell it will happen and it will significantly increase the probability that it will happen.
[+] [-] heydenberk|12 years ago|reply
[+] [-] delroth|12 years ago|reply
[+] [-] Jasper_|12 years ago|reply
Compare this with the PS2, which has a bunch of crazy programmable coprocessors to build an extremely flexible but hard-to-emulate system.
It's probably no coincidence, given that it was developed by ex-SGI engineers who founded their own company, ArtX, who got bought out by ATI to develop the R300, one of the first modern programmable GPUs.
[+] [-] Sarkie|12 years ago|reply
[+] [-] joevandyk|12 years ago|reply
[+] [-] neobrain|12 years ago|reply
As a matter of fact, AMD GPUs are using the floating point ALUs to perform integer math (note: this might have changed with their GCN architecture). However, given that the mantissa of IEEE floats is just 24 bits long, the ALU also can just handle 24 bits, which is not sufficient for full 32 bit math. Hence, for "true" integer arithmetic, the ALUs need to be double-pumped or emulated via floats (i.e. the dirty tricks which we avoided need to be done in the driver instead - but at this stage it can actually be done reliably, even if it's still ugly).
I assume the situation is similar for Nvidia GPUs. Either way both vendors said their GPUs aren't designed for optimal integer performance - so that's why we expect the performance drawbacks of integer usage to become less and less of an issue in the future.
[+] [-] Retric|12 years ago|reply
http://www.nvidia.com/object/quadro.html
Granted, most games don't use double precision or integer math so it's a reasonable choice for market segmentation.
[+] [-] kevingadd|12 years ago|reply
[+] [-] MaxGabriel|12 years ago|reply
Being on a mac, I'm tied to OpenGL so I'm hoping this doesn't hurt me too much.
[+] [-] archagon|12 years ago|reply
[+] [-] thefreeman|12 years ago|reply
[+] [-] Buge|12 years ago|reply
In the first equation (it admits it's wrong), I plug in 1 and get 0.00390625.
In the second equation, I plug in 1 and get -0.992188.
I think the answer is supposed to still be 1, because there should be no overflow until it is 256.
I thought maybe I was misunderstanding and the equation isn't just to handle overflows but is supposed to add 1 then handle overflows. So I plugged in 0 into the equations and they both outputted 0. So they aren't trying to add 1.
Wouldn't the correct equation be frac(value / 256.0) * 256.0 ?
[+] [-] neobrain|12 years ago|reply
EDIT: So uh, as a quick example of where things go REALLY wrong with the first equation - try value=-0.0000001 ;)
[+] [-] anon4|12 years ago|reply
It's still not completely correct, some values passed through that function come back as +/- 1e-16 and 255/256 becomes 0. Showing us again how floats are bloody hard to work with for the average programmer.
Edit: saw neobrain's comment, please disregard my post. Still, shouldn't there be a round in there too?
[+] [-] pauldacheez|12 years ago|reply
At least I have an excuse to buy a GTX 780 now.
[+] [-] ginko|12 years ago|reply
[+] [-] anonymousab|12 years ago|reply
[+] [-] neobrain|12 years ago|reply
EDIT: Fixed incorrect double-negative
[+] [-] mintplant|12 years ago|reply
[1] https://dolphin-emu.org/download/branches/
[+] [-] delroth|12 years ago|reply
I'll probably just remove this link from the downloads page.
[+] [-] TempleOSV2|12 years ago|reply
[deleted]