Dolphin, the GameCube and Wii emulator - Forums

Full Version: Share my personal build for android
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Like this?

PHP Code:
//            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
//                    Version 2, December 2004

// Copyright (C) 2013 mudlord

// Everyone is permitted to copy and distribute verbatim or modified
// copies of this license document, and changing it is allowed as long
// as the name is changed.

//            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
//    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

// 0. You just DO WHAT THE FUCK YOU WANT TO.

#define FXAA_REDUCE_MIN        (1.0/ 128.0)
#define FXAA_REDUCE_MUL        (1.0 / 8.0)
#define FXAA_SPAN_MAX        8.0

float4 applyFXAA(float2 fragCoord)
{
    
float4 color;
    
float2 inverseVP GetInvResolution();
    
float3 rgbNW SampleLocation((fragCoord float2(-1.0, -1.0)) * inverseVP).xyz;
    
float3 rgbNE SampleLocation((fragCoord float2(1.0, -1.0)) * inverseVP).xyz;
    
float3 rgbSW SampleLocation((fragCoord float2(-1.01.0)) * inverseVP).xyz;
    
float3 rgbSE SampleLocation((fragCoord float2(1.01.0)) * inverseVP).xyz;
    
float3 rgbM  SampleLocation(fragCoord  inverseVP).xyz;
    
float3 luma float3(0.2990.5870.114);
    
float lumaNW dot(rgbNWluma);
    
float lumaNE dot(rgbNEluma);
    
float lumaSW dot(rgbSWluma);
    
float lumaSE dot(rgbSEluma);
    
float lumaM  dot(rgbM,  luma);
    
float lumaMin min(lumaMmin(min(lumaNWlumaNE), min(lumaSWlumaSE)));
    
float lumaMax max(lumaMmax(max(lumaNWlumaNE), max(lumaSWlumaSE)));

    
float2 dir;
    
dir.= -((lumaNW lumaNE) - (lumaSW lumaSE));
    
dir.=  ((lumaNW lumaSW) - (lumaNE lumaSE));

    
float dirReduce max((lumaNW lumaNE lumaSW lumaSE) *
                        (
0.25 FXAA_REDUCE_MUL), FXAA_REDUCE_MIN);

    
float rcpDirMin 1.0 / (min(abs(dir.x), abs(dir.y)) + dirReduce);
    
dir min(float2(FXAA_SPAN_MAXFXAA_SPAN_MAX),
            
max(float2(-FXAA_SPAN_MAX, -FXAA_SPAN_MAX),
            
dir rcpDirMin)) * inverseVP;

    
float3 rgbA 0.5 * (
        
SampleLocation(fragCoord inverseVP dir * (1.0 3.0 0.5)).xyz +
        
SampleLocation(fragCoord inverseVP dir * (2.0 3.0 0.5)).xyz);
    
float3 rgbB rgbA 0.5 0.25 * (
        
SampleLocation(fragCoord inverseVP dir * -0.5).xyz +
        
SampleLocation(fragCoord inverseVP dir 0.5).xyz);

    
float lumaB dot(rgbBluma);
    if ((
lumaB lumaMin) || (lumaB lumaMax))
        
color float4(rgbA1.0);
    else
        
color float4(rgbB1.0);
    return 
color;
}

void main()
{
    
SetOutput(applyFXAA(GetCoordinates() * GetResolution()));

Why did you copy the FXAA shader into here? I'm not sure what I'm supposed to be seeing.
(12-03-2018, 09:29 AM)JMC47 Wrote: [ -> ]Also, the way you said "facts" is really funny to me, because there are more facts about this branch I could bring up, too. I wasn't trying to disrespect what it does. The creator behind the branch has submitted changes to master too, so it's not like someone just leeching with no intention to give back. Some of these changes aren't suitable for master, we know that, that's fine. There is a place for various hacks in branches and that's fine, it helps make the games more playable right now and makes people happy. But branches also see less testing, tend to have more bugs, and aren't for everyone. The users only supporting a branch like this are doing more harm than good to Android, as this branch is 99.99% Dolphin and .01% branch. It's in everyone's best interest to implement the reasonable changes from this into master and let the branch keep the hacks we find untenable. In that way, everyone wins. Master benefits through the experimentation and ideas of the branch, and users get to test more features right now.

Shareable, even the authors of the other branches / fork, are a work on the master branch. (Android and Windows)

Quote:But I take exception when everyone is trash talking master in this thread. And since this is the Dolphin forums, I feel like a certain level of respect toward the emulator that makes branches like this possible should be held.

You're wrong, nobody's talking about trash.
You do realize that I have access to the post edit history right? People editing their posts doesn't change what was said.

It's a real low blow for someone to try and prove their point by editing what they said after someone else responded to it.
(12-03-2018, 09:36 AM)stizzo Wrote: [ -> ]Like this?


...Snipped FXAA shader...

I too don't understand the point of posting an example FXAA shader. Are you trying to put in a feature request to add postprocessing effects like that to the master android build?

There's plenty of FXAA-like shader implementations floating around with various licenses already - there's not some magic secret sauce the devs can't find.

It's more the questionable benefit (IE most mobile GPUs are bandwidth limited anyway, so MSAA would often be a better choice as it probably won't be the performance bottleneck and give an objectively superior result to a FXAA-like pass) so not really a priority.

Add in the fact that all these postprocessing effects will have to be done on the final render, so will likely give a worse result than when implemented into a game directly (as the processing can be done on specific render passes - so they can skip stuff it doesn't make sense on like the UI layer, and add extra info to make it better with metadata like the depth buffers, or other improvements). None of which are (realistically) possible in a general way in an emulator.
I'm going to clarify something, I'm all for branches that do interesting things. This branch is someone's personal build that they distributed because they thought it would help people enjoy games now. Since then, they've submitted some changes to Dolphin Master and have been a great member of the community. They don't make any grand promises about what the branch does or anything else. It has some INI changes, some old hacks that we removed brought back, and some shader math changes.

But, when users are claiming that this is the holy fucking grail of builds, it gets my attention and I start looking at the branch and am like, "what am I missing?"

The balls in your court. If there are some great optimizations that speed up games that aren't just INI changes, I'd love to see it.
(12-03-2018, 09:56 AM)JonnyH Wrote: [ -> ]I too don't understand the point of posting an example FXAA shader. Are you trying to put in a feature request to add postprocessing effects like that to the master android build?

There's plenty of FXAA-like shader implementations floating around with various licenses already - there's not some magic secret sauce the devs can't find.

It's more the questionable benefit (IE most mobile GPUs are bandwidth limited anyway, so MSAA would often be a better choice as it probably won't be the performance bottleneck and give an objectively superior result to a FXAA-like pass) so not really a priority.

Add in the fact that all these postprocessing effects will have to be done on the final render, so will likely give a worse result than when implemented into a game directly (as the processing can be done on specific render passes - so they can skip stuff it doesn't make sense on like the UI layer, and add extra info to make it better with metadata like the depth buffers, or other improvements). None of which are (realistically) possible in a general way in an emulator.

Why not try with the TAA instead of MSAA?

Use 50% less hardware resources for the same performance.

The FXAA, is higly customizable shader and offer a good compromise for better performance and image quality, without sacrificing hardware resources.

On mobile, they are excellent solutions.

The TAA and FXAA, at the moment, are the lightest and most efficient and are also great for 5.5 "/ 6" screens.

The modern gpu, I do not think they have problems with bandwidth.

More than anything, I think it's just a matter of cpu.

An example is the SDM636, Cortex A73 - Adreno 509 - 256kb cached graphic memory and at the same speed as the gpu.

[Image: Screenshot-20181203-035236.png]

For comparison:

[Image: Screenshot-20181203-034109.png]

And my spec:

[Image: Screenshot-20181203-035334.png]
The more complex postprocessing options (like the temporal stuff you mentioned) is exactly what requires the extra integration into the engine to access buffers (like depth or velocity buffers) which is hard to add post-fact in an emulator

And MSAA doesn't increase the requirements that much - just the rasterisation and depth passes (which on a tiler adds near zero cost). Perhaps you are thinking of SSAA, which does run the pixel shader multiple times per pixel? That does add significant performance penalties. But even MSAA is superior to the postprocessing effects in nearly every situation.

And I can assure you that memory bandwidth is a *big* bottleneck on mobile devices. They likely have less than 10% of the bandwidth of a desktop GPU, and itsy shared with the CPU. That's why tilers are so common for mobile GPUs (*All* current mobile GPUs are tilers in some fashion) - the main advantage over forward rasterisation is in memory bandwidth use.

So this does mean that the performance trade offs can be pretty different in mobile GPUs to desktop ones, so things aren't always directly transferrable.

But you're right in saying that for many games, the CPU is a hard limiting factor for running dolphin well right now. But I mostly work with GPUs, so leave that to other people that know better Smile
don't mind me, cleaning up posts that aren't even coherent.

I'm going to just lay this out here, I'm getting rather tired of dealing with android users and my patience is getting thin

EDIT: If you're just going to keep trying to start shit, I'll just keep deleting your posts. Keep the discussion on this fork.
(12-03-2018, 05:36 PM)Helios Wrote: [ -> ]EDIT: If you're just going to keep trying to start shit, I'll just keep deleting your posts. Keep the discussion on this fork.

Known with pleasure, great maturity and composure with the themes in general of emulation and above all of criticism.

But I'm not petty, as someone can think.

In exchange: https://www92.zippyshare.com/v/0sZ3VgOm/file.html

The starting point is the source of the MMJ 9006, with my personal modifications. (60/60/100 in real, the downgrade fps, in some situations, is due to the video-audio recording service)

Good vision.