(05-08-2018, 07:39 PM)Renazor Wrote: [ -> ]I was having Metroid Prime 3 in mind with Ubershader Skip Drawing yes, it doesn't look accurate but there's no obvious gameplay changes or emulation stability issues afaik.
1. You've lost me there... Don't exactly know what you mean by that.
2. You cannot make your colour decisions on a single game because: as was said before what setting has what impact differs per game.
3. The Shader Compilation settings are just a different way to put the graphics onto the screen by the PC GPU
Synchronous: The shaders get compiled when asked for, big shaders take time to compile, sometimes multiple frames, the compiling pauses emulation until it's done. This causes microstuttering. The created shaders are very optimized for the PC's GPU. The next time the shader is used it will just load them from disk and doesn't have to compile them again: the microstutters are gone.
Synchronous (Ubershaders): The complete Gamecube/Wii GPU gets emulated into shaders, these shaders are very generic and not "optimized" and thus very taxing on your GPU but there will never be any microstutters.
Asynchronous (Ubershaders): Is a combination of both Synchronous modes, if the shader is not created yet it will use the "unoptimized" shaders while in the background the "optimized" shaders get compiled, the next time the shader is used it will load the "optimized" shader, this makes it the best of both worlds.
Asynchronous (Skip Drawing): This is the same as the Synchronous shaders except if the "optimized" shader doesn't exist yet, it just doesn't show it on the screen. Meaning: the microstutter is gone but you will miss "graphics" on the screen until the shader has compiled. Once that is done the "graphics" pop up on the screen. The next time the shader is used it will just load the existing "optimized" shader. It doesn't really have anything to do with "accuracy" but everything with how a PC GPU works compared to the consoles GPU.
This is a gross oversimplification of course because there is more things going on in the background. @Devs if I made some mistake with my explanation, don't hestitate to correct me
Round 3 I guess:
Does the damage of missiles get changed when using Skip Drawing? (I thought it wa part of ubershaders I guess not)
Does Samus get correct number of missiles from ammo pickups when using Skip Drawing?
Does MP3 experience random errors or crashes and shows signs of loss of stability during Skip Drawing?
If all the answers are no and the game shows no difference compared to when it's running at the most safe options then the option Skip Drawing would be able to be considered "purely graphical inaccuracy" which is a much lesser category IMO.
That's technical opinion, but the users could be different, the question is then how much do people care about such things, whether it's really important to them, would a user treat something that has purely graphical inaccuracy as hard as a gamplay inaccuracy or stuttering or crash even?
If the users have strong opinions then there's no choice but to treat these as if they were serious gameplay inaccuracies, but I hope otherwise. I do understand it's tricky because it's per-game, and some games have on thing where a graphical thing is required for gameplay as you mentioned, which means that it's just not possible to do it widely, this categorization would have to be done per-game.
The GUI can't have so much text to explain things per-game, that's when this comes in.
Not saying this is an important thing, it's just a side idea, but it would be like this, each game (realistically only select popular ones) would have a table in the the wiki with all the relevant GUI editable options listed, along with the category they fall into, INI overriden, comment, etc, along with a semaphore indicator, kinda green, blue, yellow, orange, red ... most definitely the red ones are also going be marked as INI overriden.
Ofcourse in the beginning most of the table would be undefined, because something like this takes quite a load of time to populate and a maintainer too to keep it updated.
This goes hand-in-hand with the default ini overrides, testing done for this would actually help find potential options which weren't overriden in game INIs before but should be if the evidence supports that.
EDIT: Then you or me aren't using the term accuracy right, so dolphin officially doesn't put graphical stuff into the "accuracy" category or what?
"at the cost of introducing visual glitches and broken effects. Not recommended"
You can't say we didn't warn you!
And no, we won't catalog the bugs it causes. It causes bugs, if you don't want bugs, don't use the feature.
(05-09-2018, 09:53 AM)MayImilae Wrote: [ -> ]"at the cost of introducing visual glitches and broken effects. Not recommended"
You can't say we didn't warn you!
And no, we won't catalog the bugs it causes. It causes bugs, if you don't want bugs, don't use the feature.
That's A okay, but do you have at least one kind of example of a non-visual bug it causes? Just so I know what to look for, I might do some my own testing for curiosity, maybe something comes out of it in future.
(05-09-2018, 09:26 AM)Renazor Wrote: [ -> ]Round 3 I guess:
Does the damage of missiles get changed when using Skip Drawing? (I thought it wa part of ubershaders I guess not)
Does Samus get correct number of missiles from ammo pickups when using Skip Drawing?
Does MP3 experience random errors or crashes and shows signs of loss of stability during Skip Drawing?
If all the answers are no and the game shows no difference compared to when it's running at the most safe options then the option Skip Drawing would be able to be considered "purely graphical inaccuracy" which is a much lesser category IMO.
That's technical opinion, but the users could be different, the question is then how much do people care about such things, whether it's really important to them, would a user treat something that has purely graphical inaccuracy as hard as a gamplay inaccuracy or stuttering or crash even?
If the users have strong opinions then there's no choice but to treat these as if they were serious gameplay inaccuracies, but I hope otherwise. I do understand it's tricky because it's per-game, and some games have on thing where a graphical thing is required for gameplay as you mentioned, which means that it's just not possible to do it widely, this categorization would have to be done per-game.
The GUI can't have so much text to explain things per-game, that's when this comes in.
Not saying this is an important thing, it's just a side idea, but it would be like this, each game (realistically only select popular ones) would have a table in the the wiki with all the relevant GUI editable options listed, along with the category they fall into, INI overriden, comment, etc, along with a semaphore indicator, kinda green, blue, yellow, orange, red ... most definitely the red ones are also going be marked as INI overriden.
Ofcourse in the beginning most of the table would be undefined, because something like this takes quite a load of time to populate and a maintainer too to keep it updated.
This goes hand-in-hand with the default ini overrides, testing done for this would actually help find potential options which weren't overriden in game INIs before but should be if the evidence supports that.
EDIT: Then you or me aren't using the term accuracy right, so dolphin officially doesn't put graphical stuff into the "accuracy" category or what?
Is Samus able to look through objects/walls until the shader is compiled? YES! Can she shoot or walk through these objects that she cannot see yet? NO!
Does this directly have to do with accuracy? NO... It has to do with how a PC GPU works in emulation.
FIRST OF ALL:
*Remember you are emulating the console not the game*
This means that your PC's GPU has to pretend to be the console's GPU and the emulator has to translate the instructions given to the consoles GPU by the game to something a PC GPU can understand. The problem lies here: The instructions can only be interpreted by the emulator and given to the PC's GPU when the console's GPU receives them from given game(the emulator can not look into the future). So your PC's GPU can only start compiling shaders once they've appeared on the screen.
Native PC games can compile all shaders before they are even used once since the game can let the GPU know "Hey in the future I am going to use the following shaders so please have them ready when I ask for them" so the PC's GPU can compile ALL shaders while the game is loading.
@mstreurman
what ubershader option id preferable on android?
(05-09-2018, 06:04 PM)sirdaniel Wrote: [ -> ]@mstreurman
what ubershader option id preferable on android?
Please create your own thread in the Android subforum. This has nothing to do with either the thread nor Development.
Continuing.
Custom Textures could be moved to Enhancements Tab preferrably, but maybe spacing issue, then General is the only other place that make sense, with existing numbers of tabs, unless default sizes for the graphics window are adjusted.
Log Render Time To File feels more like it fits into the Utility groupbox in the Advanced tab
Also, borderless fulscreen is a standalone thing right, not something used ontop of "Use Fullscreen" ?
Also if (now by default) Custom Fullscreen Resolution is set to AUTO and Use Fullscreen is enabled, than it is upscaling/downscaling whatever IR is set to and the "Auto Adjust Window Size" has no effect. That right?
I was trying 3xNative without fullscreen and with auto-adjust and it looked almost the same as 4x, which was a few pixels larger, I have 1440p and 3x (1920x...) definitely shouldn't take 95% of the screen. (Vulkan, Qt)
Metroid Prime Trilogy: 2x Native (1280x..)
Actual with EURGB60: Width 1604x..
Actual without EURGB60: Width 1924x..
Same thing with Wx and D3D11
(05-09-2018, 10:21 AM)mstreurman Wrote: [ -> ]Is Samus able to look through objects/walls until the shader is compiled? YES! Can she shoot or walk through these objects that she cannot see yet? NO!
Does this directly have to do with accuracy? NO... It has to do with how a PC GPU works in emulation.
FIRST OF ALL: *Remember you are emulating the console not the game*
This means that your PC's GPU has to pretend to be the console's GPU and the emulator has to translate the instructions given to the consoles GPU by the game to something a PC GPU can understand. The problem lies here: The instructions can only be interpreted by the emulator and given to the PC's GPU when the console's GPU receives them from given game(the emulator can not look into the future). So your PC's GPU can only start compiling shaders once they've appeared on the screen.
Native PC games can compile all shaders before they are even used once since the game can let the GPU know "Hey in the future I am going to use the following shaders so please have them ready when I ask for them" so the PC's GPU can compile ALL shaders while the game is loading.
Understood, I wish there is something we could do about that, you think ubershaders have room for improvement at all?
(05-10-2018, 11:15 AM)Renazor Wrote: [ -> ]Continuing.
Custom Textures could be moved to Enhancements Tab preferrably
JMC brought up that idea and I like it.
[
Quote:Also, borderless fulscreen is a standalone thing right, not something used ontop of "Use Fullscreen" ?
It's a modification to fullscreen. It should be next to fullscreen IMO. Or combined into a combo box.
Quote:Also if (now by default) Custom Fullscreen Resolution is set to AUTO and Use Fullscreen is enabled, than it is upscaling/downscaling whatever IR is set to and the "Auto Adjust Window Size" has no effect. That right?
Almost, but not quite. Dolphin will always render at your native resolution in fullscreen if you don't set that custom resolution INI. The IR set will be scaled up/down to fit. If you have a 1080p display and you set the IR to 6x, it will downscale to fit (But this is not particularly effective supersampling, our filter sucks.).
If you have IR set to 1x and you fullscreen on a 1080p display, it will scale up to fit.
You're still going to be rendering at whatever IR set. Your GPU will just do a trivial scale on the outputed image.
Quote:Understood, I wish there is something we could do about that, you think ubershaders have room for improvement at all?
I hate the new Ubershaders UI as well. One of these days I may do something about it but I have different hobbies these days so I can only be bothered to review
Helios Wrote:It's a modification to fullscreen. It should be next to fullscreen IMO. Or combined into a combo box.
Borderless Fullscreen is in advanced because there isn't any real reason to change as for general play it is just better (especially now since Windows 10 has much better exclusive fullscreen) and since it's a pretty advanced option that only enthusiasts will know whether they should turn it or not.
Helios Wrote:I hate the new Ubershaders UI as well.
That was DIFFICULT; we worked really long and hard on making that. And it's a LOT better than the old buzzwords-based setup!