Emulator

Yay, removing fast mips. :D

Issue 5190 has been merged into this issue.

"+1"

Disable lighting and disable fog can go too?

In my opinion "EFB copy to RAM cache" has to stay, because it often gives a speed up and for example in Zelda TP Wii if you don't enable the cache, you loose a lot of image definition.

Furthermore, if I don't remember wrong, "disable fog" is needed by a TMNT game (to avoid the screen to be completely green) and the "per pixel depht" option is needed by Zelda Wind Waker

The lose of image definition in ZTP when you disable cache is, afaik, just a regression from texcache-cleanup which I'm trying to fix at some point. Apart from that I never noticed any speedup from it (nor did SS and NaturalViolence). Are you sure it still speeds up stuff?

With removing the per pixel depth option, I was referring to forcing it to be enabled (like needed by ZWW).

Fwiw, http://code.google.com/r/neobrainx-dolphin/source/list?name=features-minus-minus shows a list of options which I removed in a branch. However, delroth already suggested that "Disable texturing" is important enough to be kept..

EFB copy to RAM with cache is faster than without cache for at least "Harvest Moon: Animal Parade" (GameIDs: RBIP99=PAL and RBIEE9=NTSCU) Speed drops from ~100% to ~72% when cache is disabled. (Tested on 1xIR, No AA for reference)

AFAIK, without cache the picture has always looked like 1x IR, even before the texcache-cleanup. Though I can't be really sure, because I hardly ever use it without cache.

• "Disable fog" is needed still since fog is not emulated 100% yet and does cause a level or two in TMNT to be unplayable.

• EFB>Ram cache should remain. It does provide a noticable speed up for me in NSMB when trying to get that stupid question box animation emulated. :)

Two other suggestions:

• "Enable Progressive Scan" in the ISO properties (of only Wii games) does nothing. Might as well remove this I guess.

• Steroscopic 3D (in DX9 only) - What does this do exactly?? I've been 3D gaming for a long time and like to think I know everything there is to know (from an end-user perspective). But I can't figure out what this does? It does force 3D on but it also leaves the mouse on screen, prevents dynamic 3D effect toggling via the video card software's hotkey and causes stability issues in-game and attempting to leave fullscreen.

Whereas DX11 allows you to toggle 3D at any time (using this Nvidia hotkey), renders the exact same way as DX9 with that 3D option on, but with none of the aforementioned side effects. Why doesn't the DX9 backend work like this? Using the Nvidia hotkey does nothing in DX9 in Dolphin. Why is that? Every pc dx game can have 3D toggled on/off at any time with this hotkey, DX9 should work that same.

So ideally, you get DX9 working like DX11, you kill the option in UI and if user wants steroscopic 3D in either backend, they use the video card software hotkey as normal. Only PC game that I ever saw that had an actual adjustable setting for this is Batman AA, though I think you can still override the setting with the hotkey, so it's kinda pointless. Batman AC shows this in the settings, but it's not adjustable - just shows you that you have the a capable system. Anyway, what do you think?

Also, I just remembered why I leave "Fast mipmaps" on. Without it, there's some texture issues with Mario Golf.

Fast mipmaps ON (correct immage):
http://imageshack.us/photo/my-images/705/fastmipmapson.png/

Fast mipmaps OFF (texture corruption):
http://imageshack.us/photo/my-images/641/fastmipmapsoff.png/

So given this, the option must stick around. Mario Golf is pretty playable currently, please don't add any more gfx issues to this great game by removing this option.

Who knows if this is the only error it causes also? Maybe when there's no known issues with normal mipmaps, then this can be removed. That unforunately is not currently the case though. Speed differences may be one thing, but accurate emulation is another.

You could change this to "Alternate mipmaps" if you don't think this gfx issue will be fixed anytime soon and you want to get rid of the "speed improving" designation.

EFB to RAM Cache Off needed for New Super Mario Bros Wii for coins to spin, but if cache is on game is much more faster

Agreed with fast mipmaps

With DX9, and max STC, you CAN use "cache" to get coins/box animation, which is faster than no "cache" and STC lower (while still preventing the 4-3 hang). Either way,I LOVE getting rid of barely useful options, but this one still serves a purpose and should be left for now.

You agree with me or OP about fast mipmaps. Hopefully you mean me. :) I think I proved well enough that one absolutely needs to stick around.

I retract my +1 for removing OpenCL, I have a few things I want to do with it coming up within a few months.

+1, isn't per pixel depth required for zww though?
or is it required to be off? I forget :)

per pixel depth needs to be enabled, yeah.. but that's what I was suggesting to use by default when the option is removed :P

Per Pixel Depth required for ZWW sea wave, and for Zelda Skyward Sword, some little flickering textures on far distances

+1 for removing OpenCL - absolutely useless. Everything else still needed to run some or many games. What will be best is to move them to game properties menu.

You should remove what you want but still allow them to be input in the game ini cause these are still very effective options on old cpu's

I don't know about that...what's the point? The UI isn't really that bad and there's a tooltips for everything. Why "hide" something that can fix bugs?

My list to safely remove:

• OpenCL (pending what Sonicadvance wants to try to do.)
• Disable Lighting
• Disable per-pixel depth
• Enable Progressive Scan (if it's functionality is never going to be restored on a per rom basis)
• Steroscopic 3D (I've commented a lot about this and haven't heard any counter arguments. It seems pointless since you can enable via vid card hotkey with better results. I could be wrong, but on my 3D setup, all this option does is cause problems.)

Questionable:

• Per-pixel lighting? Any reason this should remain?
• Skip Dest. Alpha Pass? Never seen a need ever to enable this.

As stated in the thread, the rest have a positive impact on titles and thus have to remain.

Specifically:

• Cache EFB copies
• Disable Fog
• Fast mipmaps (maybe change name)

Hey, what's wrong with the OpenCL stuff Neobrain? "It's broken for some texture formats"

I optimised it for ATI Radeon 5xxx series using the latest available OpenCL specs. The reason I haven't touched it in over a year is because it worked for all texture formats and I declared it to be perfect and moved on.
Profiler says it performs faster on my GPU than using SSE2 CPU (even taking latency in to account). Future GPUs can only decrease GPU<->CPU latency further.
I have the GPU decoding some texture formats 4x faster than the CPU. Some are slower, true. Though, it depends heavily on which GPU you use.

I will take another look over the OpenCL to see if I can make further improvements.

Perhaps more importantly, OpenCL will also be very significant on mobile devices.

Skip Destination Alpha pass brings a speed-up in some games like for example Metroid other M or Zelda SS

I meant "Enable Progressive scan" in the game config options (not the global one) above. Again, ideally you can just make this work on an individual basis, but I think Skid said there would be a problem with that.

Seems like OpenCL has some merit to stick around from what it sounds like. And I saw a report that per pixel depth needs to be disabled for 007 EoN or else the game is unplayable in some parts. So those should stay.

I strongly feel only options that provide nothing more than a miniscule speed-up should be removed. If they actually fix things, they should stay in the main ui.

Updated list to safely remove:

• Disable Lighting
• Enable Progressive Scan in the game config properties (if it's functionality is never going to be restored on a per rom basis)
• Steroscopic 3D (I've commented a lot about this and haven't heard any counter arguments. It seems pointless since you can enable via vid card hotkey with better results. I could be wrong, but on my 3D setup, all this option does is cause problems.)

Questionable:

• Per-pixel lighting? Any reason this should remain?
• Skip Dest. Alpha Pass? @haturumo, is the speed-up significant?

In Metroid Other M yes, in Zelda SS not so much...

NeobrainX: Now that we've had the discussion, it's time for those options to go. :p

From the "discussion", I still only think these should be removed:
-Disable Lighting
-Enable Prog. Scan in game config
-Steroscopic 3D
-Per-pixel lighting.

Just be careful please. I LOVE having options removed, just not ones that provide better emulation in some cases or significant speed boosts.

Why "Per-pixel lighting" ????

I've been asking about it in this thread and no one has said anything, I don't see any active issus with it at all, and I've never turned it off since it's been implemented (nor notice any gfx issues with it).

So it seemed safe to remove. But you guys know better than me. Just trying to help keep track of all this to help out.

Per pixel lighting is an enhancement which is meant to improve gfx quality (and it actually does that fairly well last time I checked)...

I'll remove some features soonish; one of them definitely will be fast mipmaps. I'm hearing about that issue with mario golf for the first time now, that would've been reported ages ago if we didn't have that setting in the first place. Same with disable fog.

OpenCL will stay for now.

Per-pixel depth will go. Disable lighting will go. Disable textures will go (that one doesn't even work on anything but ogl).

That's about it, I guess.

Prog. Scan and Steroscopic 3D have their use, they'll stay. (not going into details here)

They wanted to get rid of the option for progressive scan in the game config, since it is (apparently) ignored anyway. The option in the graphics config obviously should remain.

And to clarify, are you planning to remove disable fog? Because i would very much rather that option stay.

Yes I am. "Because I would very much rather that option stay" doesn't really sound convincing.. :p

So are you removing the options from the gfx config or their functionality all together, i..e can I still use them via the ini? Or do I have to have a broken TMNT (fog enabled)and major gfx issues in Mario Golf (Fast mipmap off), etc., etc. until proper fixes are in place (maybe never). That would be really disappointing if so...

Create two issues for that stuff (if we really don't have any for those, yet!) and I might take a look at them. Make sure to include a link to a fifo log showing the issue.

Uhm, and yeah: I was going to remove the settings altogether.

Issue 4922 for tmnt and I'll open on for Mario Golf with the info needed.

I still don't understand the logic to removing options (entirely) that fix things. Disabling per-pixel depth allow 007 to be playable. I don't get why you can't just remove the UI stuff, work on the issues and then remove their functionality later when the bugs are fixed. Again, these are things that may never get fixed as you "might" look at them at some point in the future. You're forcing uses to use old revs to play through their games. Does the whole Dolphin team agree with this? Why does a greyed out, non-functional option in the game config for Prog. scan stick around while other bug-fixing ones disappear. Just doesn't seem right.

Well i'd rather have it for the purpose of getting rid of fog. I didn't include an argument because i can only assume you don't consider that valid, otherwise you wouldn't be planning to remove it.

@wespipes69: The other devs agree with removing options in general and I yet haven't heard any objections from them concerning my policy in removing options.

@rdragoon: Sorry, but I indeed don't consider that a valid issue. Having an option for disabling fog effects is similar to this patch at http://forums.dolphin-emulator.com/showthread.php?tid=21093 which I wrote to kill off the heat effect in Sunshine.

The thing is, we have to set a limit somewhere about what options/features we want to have and which we don't want to have. There's no way to please everyone with that, unfortunately.

I think a general rule of thumb would be that when a user wouldn't see a need for an option if it wasn't already available, that option should be dropped. That applies to most of the options I mentioned above; other stuff is just debugging things which have no real use anymore.

Um these are hacks, they are not "fixes". :|

"removing options (entirely) that fix things"

We are removing red herrings! So it fixes fog on tmnt? It doesn't fix it, it removes it. And by adding the option in, it looks like the game is working correctly, when it is not.

We would rather it worked correctly.

@parlane
I understand all that. I guess the word "fix" is debatable. I'd rather it work correctly too, but I also want Alissa Milano to confess her ever-dying love for me....doesn't mean it's going to EVER happen.

I've been in the emu scene since the late 90's and I get it. You guys don't like hacks. Ok, fine. Proper fix or not, it allows a game to be playable. That alone should warrant it's being left. I'm not asking for NEW hacks/workarounds to fix things, just those that are already in place, to not lose functionality.

It should be motivation to resolve errors properly so you can THEN remove the former hack - not remove them all of a sudden to make things prettier or simplier for noobs and worry about the bugs whenever. Seriously though, these options may "resolve" bugs that a real fix never gets coded to replace. It's very concerning and I question the benefit vs the loss.

I know your focus is coding an accurate emulator but our focus is playing our games with said emulator. That's where we are coming from in all this. We just don't want to see things lost with zero benefit to us. And that's what this is. We're losing functionality, period. Dolphin is not perfect and never will, and some of these options are the only way to play our games properly now and maybe for years to come and that should count for something.

I know the discussion is pretty much moot at this point but it's still the principal and I'm hoping you'll still reconsider what options, and to what extent, are removed.

The motivation only exists when the bug is present.

Can you create a dff for tmnt? And add it to that issue. It's probably something simple.

Also, I would note that I got a ton of crap about disabling stfs in jit. When it was causing a game to be unplayable.

It met your " but our focus is playing our games with said emulator" expectation, yet I still got flamed. The actual bug was later found thanks to delroth.

Why not just move Disable Lighting / Disable Fog to the Dev section. It fits it with Wireframe. Some people actually want to disable these things occasionally I suppose.
Personally I just disable them to get a speed boost.

Not sure why the goal is to have a perfectly accurate Wii-replica with no options. Wouldn't the goal be to exceed the Wii but have the option of being identical?

There are hacks and then there are features... Disable fog is a hack, to fix broken code.

@parlane it is also useful for those that just don't want to see the fog.

Use action replay hacks for that. Or just the simple memory hacks.

I haven't yet understood if it is the "disable per pixel depth" option that will be eliminated or the per pixel depth setting

I agree with Comment #40 its seems really shitty to force others to suffer just cuz this and that and cant just make a separate dolphin like Dolphin HD = high end cpu's and Dolphin = low end cpu's not everyone has money to get a super computer like the rest of most people

shatteredlites, I have refunded the purchase price of Dolphin back into your account. Thanks for playing.

@shatteredlites accurate emulation should always be preferred over inaccurate, but fast emulation. You may not think so now, but 5, 10 years from now when a dirt cheap computer can run dolphin at more than full speed, you'll be glad there are much fewer bugs.

@rdrag..
That's not the point and this IS the last comment I'll make on this thread. We already have accurate emulation right now with mipmaps....for the most part. But we ALSO already have in place a hack to "fix" certain things. What's wrong with leaving the hack in for now so we can play certain games until the emulation IS actually accurate?

I just don't get the harm with having the choice to use inaccuarate emulation or not...if it's already there. Removing this hack does not equate to more accurate emulation. Maybe on area of inaccurate code is gone, but games are going to function no differently then when these hacks were still around.

Ok, I've spoken my peace and I only hope the devs will maybe put a little more focus on the issues that these deleted settings fixed previously. It does look like they are interested in doing just that, so I'm still appreciative of these dude's efforts. I'll shut up now. :)

I wouldnt say 10 years maybe 50 cuz the sega saturn cant even run all that well lol but the progress with this is faster but every new revision seems to go slower and slower but more accurate but I wonder if its cause of the wii coding that the gamecube runs slow idk im just missing the fast paced gamecube ever since the wii got coded its been down hill with speed

Hey NeoBrain,

As an old time Dolphin user (since like 07 I think) I am really against you removing PerPixelDepth.

I have made my own thread and confirmed ages ago that without PerPixelDepth turned on Zelda Wind Waker (and possibly others) experience strange texture flickering issues. This option must remain, or at least be made to be ALWAYS ON without the option to disable. I do not know if it causes issues in other games when the option is ON, but I beg of you to not remove the code for it entirely. As someone who enjoys playing Zelda WW on Dolphin over the console, I really would appreciate you not removing this particular option. At least not altogether.

I'm totally for you making the option always ON and removing the ability to disable, but please don't remove it 100% entirely from the code.

Thanks,
A huge fan of this project

... "or at least be made to be ALWAYS ON without the option to disable" that was the plan all along.

In that case I'm all for removing the option to disable. Assuming of course it doesn't break other games. I don't have many others ripped on my PC to know if they break or not.

remove "Force Texture Filtering" too, its Glitches many games

Umm, do not remove "force texture filtering" - i have it on for the majority of my games with very nice results and less pixelated 2d stuff in general. It only messes up text and movies in some games, in some situation. DOES NOT need to be removed.

I'd like to see comparison screenshots for Force Texture Filtering and Per-Pixel Lighting in cases where they actually make something look better. And I'd like to hear cases where lowering the texcache accuracy actually measurably speeds up a game, 'cause I've never seen that myself.

On a less related note, I'd also love to know if Real XFB looking worse than an actual console's output at the same resolution is a bug, and whether it's reparable or not, because I really can't see that being the intended behavior.

Weaker systems can benefit from the fastest texture cache over the slowest. Higher-end rigs will see no difference and just power though the game regardless of where that settings is.

Ah, didn't see your comment before I posted mine, wespipe. Which games does it have a noticeable effect on, and where?

(Oh, hey, that happened again.) tommyhl2, mine's not really a higher-end system, having an Intel GPU and a 1.7 GHz i5, but I still see little performance difference. What does texcache rely on most, video RAM? Or is it just CPU/GPU like most everything else?

None of "Force texture filtering", "Per-pixel lighting" or "Texture Cache Accuracy" will be removed.

Ah, I know. I just wanted to see examples of where those are actually useful.

Now that I think about it, that's a better question for the forum, isn't it? Sorry.

Killed so far:

• Fast mipmaps
• Disable Lighting
• Disable Textures

Next up on schedule:

• Disable fog: Gotta look into that stupid TMNT game, maybe it's an easy fix.
• EFB copy cache: The recent awesome-texcache-cleanups-and-fixes branch merge fixed a performance regression in the (non-cached) EFB copy to RAM code path, i.e. the reported speedup from the cache might just have been a workaround for that issue. Does anyone still observe notable speedups from enabling EFB copy caching?
• Disable dest alpha pass: There's really no reason to remove it these days... for D3D11 emulation of dest alpha pass is bscly free (no dual pass needed); same for OGL, but I'm not sure if we're enabling that code path by default, yet; D3D9 is a problem here.. it needs a dual-pass approach which a) has a performance penalty b) isn't actually accurate emulation. I.e. I don't see a reason to keep the option just for having a bit more speed in D3D9.
• Disable per-pixel-depth: Still pending the graphics-fixes revert.

Opinions? :D

Just for reference, marking related bugs as blockers to this issue.

Blocking? What's... oh, right, right, they're like dependencies? Those have to be fixed first? Hm.

EFB copy cache provides me, at most, two or three more fps post-awesome-blahblahblah. It's already gone in Hashless, though, so it might be better to wait until that's merged in.

Skip Destination Alpha Pass provides a good speedup for the map in Metroid Prime, at least on OpenGL.

From what I remember of my tests, at least on my system (e8400 - hd4850 - winXP), checking the option of skipping destination alpha pass in both OpenGL and Dx9 gave me a good speed up in Metroid other M and a small speed up in Metroid Prime and Zelda Skyward Sword.
In the next days I have to check again with last master and hashless revisions.

Skip Destination Alpha Pass give me + 10 FPS in RE4, in Metroid Prime give me + 15 until 20 FPS, in Eternal Darkness give me + 15 until 22 FPS.

It's a nice option that give you good speed up and it also let you use more filters.

I confirm that skipping destination alpha pass I get a good speed-up in Metroid Other M (5-10 fps) and a small one in Zelda SS (2-3 fps).

You guys, your reports are pretty useless if you don't say which video backends you used and how the different backends compare. Like I said, D3D9 is likely to get a performance improvement while D3D11 is likely not to.

I get those speed ups with both Dx9 and OpenGL (I cannot test DX11 because I use WinXP), while in Metroid Prime seems to me that's more noticeable with Dx9.

Me too OpenGL and DX9 only, in DX11, no performance improvement

after all that and asking for opinions and everything else
all you did was tell ppl their opinions are wrong. i dont get it.

He never really wanted opinions. He was looking for hard facts that demonstrate a valid reason to keep these options. Skip Destination Alpha Pass is the only one that has even possibly shown a potential reason to keep it.

I'm pretty sure Fast Mipmaps has a better reason than SDAP - it actually prevents gfx issues. :) Anyway, let's not get into this. We've argured about this in several different threads. NOTHING will be accomplished by continuing this. Enough.

Issue 4922 (TMNT) is about to get fixed soonish. Any further reason to keep "Disable Fog"?

The only reason I see to keeping "Disable Fog" is to be able to see things in games that would otherwise be obscured by fog. This is usually just for fun, but sometimes it can affect gameplay, like the dense fog event in Kirby Airride's city trial. Basically the only reason I've seen to keep it is is to "cheat" in Kirby Airride.

shouldn't we keep the openCL tex decoder?
It's the way to go on mobile devices and it should be faster if using shadered buffer and propper sync.
of curse, in the current state, it is garbage

I've proposed dropping the OpenCL decoder multiple times since sometime mid 2011 now and every time someone different showed up and said "yo, don't drop it, I'll make it more efficient by using ". However, no one actually showed up with those improvements to this date, keeping the OpenCL decoder in a state where it doesn't provide any major advantage over the CPU decoders.

At the moment there's nothing wrong with keeping it, but as soon as some changes to the TextureDecoder interface are needed I see no further reason to maintain and keep it. People who are willing to modernize the OpenCL decoder can revive it from history then since fixing the interfaces should be less effort compared to the actual task of optimizing the OpenCL decoder.

Please keep the issue title as "Feature Removals", as this is not about removing specific features but discussion about features which can and/or should be removed.

As a complete outsider perspective here, I just want to say that I think removing the "red herrings" would be pretty helpful. With all the possible combinations of settings & no real knowledge as to the back-end (tool-tips aren't always so helpful for a noobie), it can sometimes take hours to find the proper combination that works. Taking out ones which wouldn't help in the first place would make this process MUCH quicker. Thanks!

~ Ignore edits, I spoke too soon. Looks like Pictobox is freezing regardless of copy to RAM/Texture (still in 3.5 release), takes about 20 seconds to complete. I thought the brokenness was just specific to copy to RAM but looks like both are broken. ~

Just a quick update + summary of options that have been "removal candidates":

• Fast Mipmaps: Removed, issues with native mipmaps have been fixed now.
• Per pixel depth: Removed, kills performance pretty badly on some GPUs though. degasus is working on reintroducing a similar but less ugly hack (.. or not, situation seems a bit messy right now)
• Disable Lighting: Removed
• Disable Textures: Removed

Options that will stay for now:

• OpenCL: Sonicadvance1 says he'll work on it... We kinda agreed that it's too slow for what it's doing though and should be modernized at some point, either by using OpenCL 2.0 features or by screwing it entirely and going with HLSL/GLSL shaders instead.
• EFB copies to RAM cache: Might be deprecated in the Hashless branch. Should be replaced with a proper "hybrid EFB copies" option, anyway... But that's beyond the scope of simple "feature removals"
• Disable Fog: Stays by RachelB's request but will be moved to either the "Enhancement" or "Advanced" tab with an updated description (it really does anything but improve performance).
• Skip dst alpha pass: Stays for now, but will be dropped eventually. Both D3D9 and OGL (GLSL only) support dual source blending which is both the more efficient and accurate way to emulate dst alpha.

Disable Fog is required to get rid of the blue Box in Mario Kart Wii DX9, DX11 and OGL, Issue 2063.

Per pixel depth:
Created again as "Fast Depth Calculation". ppd slows down all gpus extremly (20-50%, but mostly isn't the bottleneck) but all other depth method has some issues. ppd is now the some as before, the fast one differs a bit with z-textures on ogl/dx11. Sorry for the delay :-)

It seems per pixel depth is needed to remove the annoying nvidia driver crash when using dolphin. haven't had a chance to test it as the option was already gone.

I don't think I've asked about this one yet:

Is there any reason to keep the "disabled" mode for EFB copies? There have been reports about EFB copy emulation breaking things in the past, but AFAIK those are fixed now.

I've never experienced any issues with that and I don't remember ever seeing complaints about problems there. Probably safe to kill.