Dolphin, the GameCube and Wii emulator - Forums

Full Version: "EFB to Texture" or "EFB to Ram"
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
So you imply D3D+Windows (my settings) is not slow?
(11-16-2014, 11:09 PM)Dogway Wrote: [ -> ]So you imply D3D+Windows (my settings) is not slow?

Yes, make it plus your hardware since you have one of the latest intel cpus. I am pretty sure if you try with the same settings opengl with NSMB and efb to ram performance will not be as good.

Edit: Made a test for you, in world 2-1 i am getting using the same settings 92 fps in D3D vs 55 fps in opengl which makes the game unplayable (efb to ram is enabled of course).
yes, but what's the point of OpenGL (in windows)?
Also is EFB to RAM plus "cache enabled" accuracy worse than EFB to texture alone?
(11-16-2014, 11:34 PM)Dogway Wrote: [ -> ]yes, but what's the point of OpenGL (in windows)?
Also is EFB to RAM plus "cache enabled" accuracy worse than EFB to texture alone?

OpenGL has it's benefits, for example it is usually faster when efb to texture is used and a bit more accurate. "Cache enabled" was used in the past to help speed up efb to ram a bit in cases where safe texture cache could be disabled, now that safe texture cache can't be disabled it is pretty much useless. Even in those edge cases in the past it provided a 10% speedup at best and it was more susceptible to issues, for example NSMB coins need it disabled. There are talks to remove it altogether as an option.
I have just been testing, and OpenGL gives a bunch of more headaches, to start it doesn't render HUD graphics, it needs a projection hack line in the settings. Also upscaled raster graphics (including video) is not filtered as in D3D (it seems to use plain nearest neighbour).
In the newest dev builds, OGL and D3D both don't display the HUD in some games because they were made to work more like each other. The HUD issue is being worked on though.
I see so they are indeed the exact same issue. Which is odd, because in build 3746 where D3D still hasn't this issue OpenGL has it. Was this an approach then to make D3D behave more like GL?

What about the pixelation thing?

Thanks for the answer, I'm still heavily pondering what backend and build to use. Was about to stick to 3746 and D3D before this thread.
AFAIK, at least the part about the projection in D3D was changed to match OGL because OGL was more correct (but still broken Tongue)

Not sure on pixelization. Do you have per-pixel lighting turned on?

Seeing as how you have an Nvidia GPU, OGL would be faster, and you can just add in the projection hacks if needed.
Yes, I guess that's what I can do, do you know of a place with a list of affected games or I should go to each wiki?

The pixelation is I think a lack of scaling filtering (uses plain nearest). I saw this on Sonic Colours but probably all games are affected. On my end everything is unchecked except "Scaled EFB Copy", "External Frame Buffer; Disabled" and "Fast Depth Calculation", texture cache on fast, I recall changing it to safe without improvements. This also happens on recent builds.
In that case try turning on per-pixel, as it can help with the grainyness
Pages: 1 2 3 4