Welcome!
Final Burn Neo => FBN Development => Topic started by: pmc2 on January 05, 2012, 02:33:14 PM
-
A chance to see what filter in fba?
http://board.byuu.org/viewtopic.php?f=10&t=2248
(v3.3b / v3.5a Cg shader)
(http://img838.imageshack.us/img838/8779/303781.jpg)
Better than 2xsai/hqnx/EPX !!
(http://img600.imageshack.us/img600/4941/filtercompare.png)
-
Would love to see support for GPU accelerated filters in FBA - sadly I know next to nothing about DirectX or graphics programming in general, and I don't have much time to learn. If anybody else wanted to add support to the DX9 blitter(s) for Kega compatible (or BSNES XML, not sure what standards there are exactly!) plugins though, that would be cool. :)
-
ive incorporated shaders in FBANext (xbox360 port) and scrapped software filters
https://github.com/lantus/FBANext/tree/master/src/interface/xbox
it should carry over to Win32 fairly easily. Captain-CPX could probably port this over in his sleep :)
-
I posted some of my sources in this forum, but it seems no one was interested: http://neo-source.com/index.php?topic=1835.msg13204#msg13204
And, that Dolphin image isn't from this filter. It's from a Microsoft Reasearch paper.
Hi, Lantus.
That xBR shader you're using on FBA360 is really old. You need to get 3.5a soon. Convert these to fx, please: http://www.multiupload.com/M2SUIU3J6H
They're the latest. Those with CRT are specially good with arcade games!
-
thanks Hyllian, much appreciated!
edit: not to hi-jack this thread but do you have .fx/hlsl variants of those shaders? I could port them myself but if you already have them that would be even better
double-edit: apparently i cant read. I will port them over to .fx :)
thanks!
-
thanks Hyllian, much appreciated!
edit: not to hi-jack this thread but do you have .fx/hlsl variants of those shaders? I could port them myself but if you already have them that would be even better
double-edit: apparently i cant read. I will port them over to .fx :)
thanks!
Ok. I don't know much about glsl format, so I think you can do this task. :biggrin:
BTW, here some screenshots I'm getting with this filter:
Original.........................2x..................................4x
(http://bildr.no/thumb/1070942.jpeg) (http://bildr.no/view/1070942) (http://bildr.no/thumb/1070946.jpeg) (http://bildr.no/view/1070946) (http://bildr.no/thumb/1070947.jpeg) (http://bildr.no/view/1070947)
Original.........................2x..................................4x
(http://bildr.no/thumb/1070944.jpeg) (http://bildr.no/view/1070944) (http://bildr.no/thumb/1070948.jpeg) (http://bildr.no/view/1070948) (http://bildr.no/thumb/1070949.jpeg) (http://bildr.no/view/1070949)
-
demul would need this filter also (.slv /.slf)......
-
SSNES has quite sophisticated shader support (arbitrary multi-pass), and xBR runs just fine in OpenGL/D3D9 using Cg :) Soon, SSNES can run FBA core when it's properly merged.
-
I sure hope this Filter can be implemented sometime in the near future.
It is such a fantastic Filter, in Kega Fusion it gives it almost a HD quality, very top notch and blows away the HQ filters.
-
SSNES has quite sophisticated shader support (arbitrary multi-pass), and xBR runs just fine in OpenGL/D3D9 using Cg :) Soon, SSNES can run FBA core when it's properly merged.
I made an attempt at porting over the SSNES video renderer to the core of FBA at the weekend. It kind of worked and now I have a proof on conecpt ill try and hook it up properly without ruining half the source files in the process.
-
I made an attempt at porting over the SSNES video renderer to the core of FBA at the weekend. It kind of worked and now I have a proof on conecpt ill try and hook it up properly without ruining half the source files in the process.
Very nice kev.
I've added a keep up with the Jones' feature to SVN, 7zip support for rom loading/scanning. :)
-
I made an attempt at porting over the SSNES video renderer to the core of FBA at the weekend. It kind of worked and now I have a proof on conecpt ill try and hook it up properly without ruining half the source files in the process.
That's cool :D Which driver(s)? OpenGL or D3D (external plug)?
-
Opengl but the d3d one should be just as easy to get working.
-
Very nice kev.
I've added a keep up with the Jones' feature to SVN, 7zip support for rom loading/scanning. :)
I made an attempt at porting over the SSNES video renderer to the core of FBA at the weekend. It kind of worked and now I have a proof on conecpt ill try and hook it up properly without ruining half the source files in the process.
Some very sexy changes. :D
-
Opengl but the d3d one should be just as easy to get working.
How good is openGL on Windows now? I thought it got pretty bad lately?
-
GL is fine. One issue I'm getting on Windows 7 is that in windowed mode, VSync doesn't work as smoothly as you'd expect. It is however great in fullscreen. I can create OpenGL 4.2 contexts just fine as well, so drivers are progressing at least.
-
It is my dream to one day see the xBR-v3.3 filters implemented somehow into FB Alpha. It is my favourite render for Kega Fusion. Until then...thanks for the hard work on such a great emulator.
-
I've taken some screenshots of FBA running on PS3 using 5xBR-v3.7+CRT shader:
(http://i.imgur.com/NYJcO.png)
(http://i.imgur.com/vhVMU.png)
(http://i.imgur.com/m61X1.png)
(http://i.imgur.com/XlN5z.png)
Complete album here:
http://imgur.com/a/ZZiiH (http://imgur.com/a/ZZiiH)
-
Hyllian
where can i get the 3.7 shaders ? . I have 3.5a ported to .fx now
-
Hyllian
where can i get the 3.7 shaders ? . I have 3.5a ported to .fx now
Hi Lantus,
Get these 3.7 attached below:
There are three variants: "a", "b" and "c". They differ about how corners are rounded. "a" is rounded; "b" is semi-rounded and "c" is squared.
-
thanks
i've ported them across to HLSL but hmm im not sure why but they are not displaying anything like expected. I've attached them here if someome wants to look closer.
where is what it looks like to me
(http://i.imgur.com/s3FXRl.jpg) (http://imgur.com/s3FXR)
and just the regular 5xBR_V3.7c
(http://i.imgur.com/CB1HEl.jpg) (http://imgur.com/CB1HE)
any ideas??
-
Hi Lantus.
It seems there's a problem related to resolution.
Can you rename one of those two "ps" variables? dunno if it can fix something...
another question: What resolution are you running at?
I run at 1536x1120, it's exactly 4x and 5x the native CPS2 resolution (384x224).
-
running at 1280x720 (720p)
i tried renaming the ps variables. The first one isnt actually used so i removed it. I renamed the pixelshader from PS to something else. No change.
whats interesting is older versions of your shader work fine. 3.3 and lower is good. The 3.5/3.7 have problems. The shaders themselves pass validation correctly so it looks like im missing something
-
Can you set the resolution to 1080p and see what happen?
And post the latest working fx?
-
Another test. Don't delete that first ps var (TEXELSIZE). Use it in this line instead IN.texture_size. Just comment the line below and put the first with ps:
float2 fp = frac(VAR.texCoord/ps);
// float2 fp = frac(VAR.texCoord*IN.texture_size);
And don't forget to comment this line:
//input IN : VIDPARAMS;
-
no change at 1080p
V3.3 was the last working one
ignore the
[maxtempreg(64)] - its just a compiler hint
hopefully this will help
-
Try this code and tell me if it works:
/*
Hyllian's 5xBR v3.5a Shader
Copyright (C) 2011 Hyllian/Jararaca - sergiogdb@gmail.com
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
// The name of this effect
string name : NAME = "FiveXBR3";
float2 ps : TEXELSIZE;
float4x4 World : WORLD;
float4x4 View : VIEW;
float4x4 Projection : PROJECTION;
float4x4 Worldview : WORLDVIEW; // world * view
float4x4 ViewProjection : VIEWPROJECTION; // view * projection
float4x4 WorldViewProjection : WORLDVIEWPROJECTION; // world * view * projection
string combineTechique : COMBINETECHNIQUE = "FiveTimesBR3";
texture SourceTexture : SOURCETEXTURE;
texture WorkingTexture : WORKINGTEXTURE;
sampler decal = sampler_state
{
Texture = (SourceTexture);
MinFilter = POINT;
MagFilter = POINT;
};
const static float coef = 2.0;
const static float3 dtt = float3(65536,255,1);
const static float y_weight = 48.0;
const static float u_weight = 7.0;
const static float v_weight = 6.0;
const static float3x3 yuv = float3x3(0.299, 0.587, 0.114, -0.169, -0.331, 0.499, 0.499, -0.418, -0.0813);
const static float3x3 yuv_weighted = float3x3(y_weight*yuv[0], u_weight*yuv[1], v_weight*yuv[2]);
float4 RGBtoYUV(float4x3 mat_color)
{
float a= abs(mul(yuv_weighted, mat_color[0]));
float b= abs(mul(yuv_weighted, mat_color[1]));
float c= abs(mul(yuv_weighted, mat_color[2]));
float d= abs(mul(yuv_weighted, mat_color[3]));
return float4(a, b, c, d);
}
float4 df(float4 A, float4 B)
{
return float4(abs(A-B));
}
float4 weighted_distance(float4 a, float4 b, float4 c, float4 d, float4 e, float4 f, float4 g, float4 h)
{
return (df(a,b) + df(a,c) + df(d,e) + df(d,f) + 4.0*df(g,h));
}
struct out_vertex
{
float4 position : POSITION;
float2 texCoord : TEXCOORD0;
float4 t1 : TEXCOORD1;
};
//
// Vertex Shader
//
out_vertex VS_VERTEX(float3 position : POSITION, float2 texCoord : TEXCOORD0 )
{
out_vertex OUT;
OUT.position = mul(float4(position,1),WorldViewProjection);
float dx = ps.x;
float dy = ps.y;
OUT.texCoord = texCoord;
OUT.t1.xy = float2( dx, 0); // F
OUT.t1.zw = float2( 0, dy); // H
return OUT;
}
float4 PS_FRAGMENT (in out_vertex VAR) : COLOR
{
bool4 edr, edr_left, edr_up, px; // px = pixel, edr = edge detection rule
bool4 interp_restriction_lv1, interp_restriction_lv2_left, interp_restriction_lv2_up;
bool4 nc; // new_color
bool4 fx, fx_left, fx_up; // inequations of straight lines.
float2 fp = frac(VAR.texCoord/ps);
float2 dx = VAR.t1.xy;
float2 dy = VAR.t1.zw;
float3 A = tex2D(decal, VAR.texCoord -dx -dy).xyz;
float3 B = tex2D(decal, VAR.texCoord -dy).xyz;
float3 C = tex2D(decal, VAR.texCoord +dx -dy).xyz;
float3 D = tex2D(decal, VAR.texCoord -dx ).xyz;
float3 E = tex2D(decal, VAR.texCoord ).xyz;
float3 F = tex2D(decal, VAR.texCoord +dx ).xyz;
float3 G = tex2D(decal, VAR.texCoord -dx +dy).xyz;
float3 H = tex2D(decal, VAR.texCoord +dy).xyz;
float3 I = tex2D(decal, VAR.texCoord +dx +dy).xyz;
float3 A1 = tex2D(decal, VAR.texCoord -dx -2.0*dy).xyz;
float3 C1 = tex2D(decal, VAR.texCoord +dx -2.0*dy).xyz;
float3 A0 = tex2D(decal, VAR.texCoord -2.0*dx -dy).xyz;
float3 G0 = tex2D(decal, VAR.texCoord -2.0*dx +dy).xyz;
float3 C4 = tex2D(decal, VAR.texCoord +2.0*dx -dy).xyz;
float3 I4 = tex2D(decal, VAR.texCoord +2.0*dx +dy).xyz;
float3 G5 = tex2D(decal, VAR.texCoord -dx +2.0*dy).xyz;
float3 I5 = tex2D(decal, VAR.texCoord +dx +2.0*dy).xyz;
float3 B1 = tex2D(decal, VAR.texCoord -2.0*dy).xyz;
float3 D0 = tex2D(decal, VAR.texCoord -2.0*dx ).xyz;
float3 H5 = tex2D(decal, VAR.texCoord +2.0*dy).xyz;
float3 F4 = tex2D(decal, VAR.texCoord +2.0*dx ).xyz;
float4 a = RGBtoYUV( float4x3(A, G, I, C) );
float4 b = RGBtoYUV( float4x3(B, D, H, F) );
float4 c = RGBtoYUV( float4x3(C, A, G, I) );
float4 d = RGBtoYUV( float4x3(D, H, F, B) );
float4 e = RGBtoYUV( float4x3(E, E, E, E) );
float4 f = RGBtoYUV( float4x3(F, B, D, H) );
float4 g = RGBtoYUV( float4x3(G, I, C, A) );
float4 h = RGBtoYUV( float4x3(H, F, B, D) );
float4 i = RGBtoYUV( float4x3(I, C, A, G) );
float4 a1 = RGBtoYUV( float4x3(A1, G0, I5, C4) );
float4 c1 = RGBtoYUV( float4x3(C1, A0, G5, I4) );
float4 a0 = RGBtoYUV( float4x3(A0, G5, I4, C1) );
float4 g0 = RGBtoYUV( float4x3(G0, I5, C4, A1) );
float4 c4 = RGBtoYUV( float4x3(C4, A1, G0, I5) );
float4 i4 = RGBtoYUV( float4x3(I4, C1, A0, G5) );
float4 g5 = RGBtoYUV( float4x3(G5, I4, C1, A0) );
float4 i5 = RGBtoYUV( float4x3(I5, C4, A1, G0) );
float4 b1 = RGBtoYUV( float4x3(B1, D0, H5, F4) );
float4 d0 = RGBtoYUV( float4x3(D0, H5, F4, B1) );
float4 h5 = RGBtoYUV( float4x3(H5, F4, B1, D0) );
float4 f4 = RGBtoYUV( float4x3(F4, B1, D0, H5) );
float4 Ao = float4( 1.0, -1.0, -1.0, 1.0 );
float4 Bo = float4( 1.0, 1.0, -1.0,-1.0 );
float4 Co = float4( 1.5, 0.5, -0.5, 0.5 );
float4 Ax = float4( 1.0, -1.0, -1.0, 1.0 );
float4 Bx = float4( 0.5, 2.0, -0.5,-2.0 );
float4 Cx = float4( 1.0, 1.0, -0.5, 0.0 );
float4 Ay = float4( 1.0, -1.0, -1.0, 1.0 );
float4 By = float4( 2.0, 0.5, -2.0,-0.5 );
float4 Cy = float4( 2.0, 0.0, -1.0, 0.5 );
// These inequations define the line below which interpolation occurs.
fx = (Ao*fp.y+Bo*fp.x > Co);
fx_left = (Ax*fp.y+Bx*fp.x > Cx);
fx_up = (Ay*fp.y+By*fp.x > Cy);
interp_restriction_lv1 = ((e!=f) && (e!=h));
interp_restriction_lv2_left = ((e!=g) && (d!=g));
interp_restriction_lv2_up = ((e!=c) && (b!=c));
edr = (weighted_distance( e, c, g, i, h5, f4, h, f) < weighted_distance( h, d, i5, f, i4, b, e, i)) && interp_restriction_lv1;
edr_left = ((coef*df(f,g)) <= df(h,c)) && interp_restriction_lv2_left;
edr_up = (df(f,g) >= (coef*df(h,c))) && interp_restriction_lv2_up;
nc = ( edr && (fx || edr_left && fx_left || edr_up && fx_up) );
px = (df(e,f) <= df(e,h));
float3 res = nc.x ? px.x ? F : H : nc.y ? px.y ? B : F : nc.z ? px.z ? D : B : nc.w ? px.w ? H : D : E;
return float4(res, 1.0);
}
//
// Technique
//
technique FiveTimesBR3
{
pass P0
{
// shaders
VertexShader = compile vs_3_0 VS_VERTEX();
PixelShader = compile ps_3_0 PS_FRAGMENT();
}
}
This is my last resort. I don't know much about HLSL.
-
didnt load initially i added in
struct input
{
float2 video_size;
float2 texture_size;
float2 output_size;
float frame_count;
};
which is required by my code..when i added that in this is the result
(http://i.imgur.com/wXcvD.jpg) (http://imgur.com/wXcvD)
-
It's not right. Unfortunately, I haven't any new idea to test. Besides, I can't test and debug HLSL here. I'm sure the texture lookups aren't working properly, because the algorithm isn't filtering where it was supposed to.
On PS3, the resolution is 1080p and using the resize option I choose 1536x1120 as viewports and everything works perfect as in the screenshots.
-
im at work today but when i have some time ill push the shader through FX Edit and see whats up
-
Lantus, could you test if these xBR winuae shader (http://eab.abime.net/showpost.php?p=806863&postcount=10) ports work on FBA?
-
ill check it out as soon as i get home tonight. i guess if it doesnt look right theres a problem with my shader code. We will see here shortly
edit: well that shader doesnt look right either so theres a code problem somewhere. thanks for your assistance Hyllian i will get it sorted out
thanks!
-
Is the image being scaled by a certain factor when using the xBR shader?
On PS3, the user can toggle between 1x/2x/3x/4x scaling of the image.
-
please add this filter, it's looking amazing
-
please add this filter, it's looking amazing
You already can use it with FBA through SSNES 0.9.5, which was released two days ago for PC.
-
Hopefully it also gets implemented into FB Alpha 0.2.97.95. IMHO, this is the only graphic's filter you need as it has made everything else before it seem redundant.
-
A filter that would merit in fba, clearly.
-
Some screenshots (http://forum.outerspace.terra.com.br/showpost.php?p=9259289&postcount=209) of it running on SSNES 0.9.5 naked (without CRT).
-
Would be great to see FBA finally use that WIP SSNES renderer code that was alluded to in an earlier post. It should be about time PC emulators in general try to gradually phase out CPU filters as most PCs nowadays at least have a GPU capable of running vertex and fragment shaders with decent performance - and CPU filters take a heavy burden on the CPU which could (should IMHO) be better spent on the actual emulation.
This is the approach I have taken from day one with the PS3 emulator ports - without it, performance would have suffered immeasurably - I doubt I would have even been able to run something like VBA with acceptable performance running with a low-key CPU filter like 2xSaI. On top of that, you get shader stacking and other enviable features in the shader spec we have made, such as 'prev' textures (allowing for motion blurring effects), and 'frame count' (allowing for shaders with animations).
Someone is even working on a Braid-style rewind shader that will work very similar to the game Braid - with VCR-style graphical effects.
In short, it makes sense to go this route and you will get more visual bling in return as well. It's just backwards for it to be 2012 where we fork out a lot of money for a PC to have a fast GPU and a quad-core/whatever CPU, only to then still keep developing emulators that put all the strain on the CPU for filtering duties - instead of leveraging the increased parallelization options available to us (now that we have GPUs that can do the filtering stuff for us) instead and giving the CPU some breathing room at the same time. I would champion it, and you guys have full permission from me and Maister to take whatever code you need from SSNES to make it happen - there are Direct3D and OpenGL versions of the renderer code in the same codebase - should contain all you need. GLSL and Cg is catered for - only HLSL code is needed right now in SSNES - but I will have to add that eventually as I'm targeting 360 too.
It should not be tied to the core because the libretro port for use with SSNES will just use SSNES' own rendering code instead. The interface/ portions of FBA should be a good place to abstract away the OpenGL/D3D SSNES rendering code for use with FBA Win32. I bypass all 'interface' code in FBA libretro/libsnes anyway - I'd like to keep being able to do that - the performance I'm reaching now with the PS3 port depends on it)
-
You already can use it with FBA through SSNES 0.9.5, which was released two days ago for PC.
I suppose this is true but I think the intent of the user was an "easy" solution. I just tried running a game with Phoenix GUI, etc and it wasn't a walk in the park and I've encountered numerous errors. I'm sure I am missing all the relevant shaders since I don't believe the "full" package includes shaders. So it hasn't been an easy experience getting a game to run on my pc with ssnes to test out the shaders. Granted, I simply looked at the forum, some starting tips, not a lot of time invested or asked for any help. I'm sure its a few tweaks here and there, a download or two I may be missing and voila, but it was not intuitive.
Edit: Played with it some more, found 6 xBR filters, downloaded one, tested it. Got it to work. Games run at a crawling 12-15 fps. I don't have a dedicated video card so I'm sure this is part of the problem now. Perhaps this will be revisted once I upgrade my hardware. Tried multiple settings but at least I was able to see the filter in actions.
-
You're right about ssnes configuration not being easy. I recommend these two tutorials about it:
http://filthypants.blogspot.com.br/2011/11/getting-started-with-ssnes.html (http://filthypants.blogspot.com.br/2011/11/getting-started-with-ssnes.html)
http://filthypants.blogspot.com.br/2011/11/advanced-ssnes-configuration-options.html (http://filthypants.blogspot.com.br/2011/11/advanced-ssnes-configuration-options.html)
And, to run shaders at good speed you'll need good gpu at least.
-
I suppose this is true but I think the intent of the user was an "easy" solution. I just tried running a game with Phoenix GUI, etc and it wasn't a walk in the park and I've encountered numerous errors. I'm sure I am missing all the relevant shaders since I don't believe the "full" package includes shaders. So it hasn't been an easy experience getting a game to run on my pc with ssnes to test out the shaders. Granted, I simply looked at the forum, some starting tips, not a lot of time invested or asked for any help. I'm sure its a few tweaks here and there, a download or two I may be missing and voila, but it was not intuitive.
Edit: Played with it some more, found 6 xBR filters, downloaded one, tested it. Got it to work. Games run at a crawling 12-15 fps. I don't have a dedicated video card so I'm sure this is part of the problem now. Perhaps this will be revisted once I upgrade my hardware. Tried multiple settings but at least I was able to see the filter in actions.
Yes, Maister is a UNIX coder who doesn't like to write pretty GUIs and stuff like that (in fact, hates it) - SSNES-Phoenix pretty much assumes of the user that he/she knows what it is they're doing. I agree with you that it could be much more intuitive. Unfortunately, this is going to require somebody getting involved that cares about an intuitive user interface on PC - and neither me or Maister are really interested in doing that.
This is where SSNES PS3 and 360 really come into play I guess - I supply all the shaders with each install of SSNES PS3 (they're just git cloned from a repo called common-shaders) and the user can very easily configure the two shaders along with scaling factor, aspect ratio, and other assorted options.
But I suppose not many people have jailbroken PS3s/360s on this forum, so I guess we still arrive at the problem that SSNES lacks a user-friendly GUI on PC.
With regards to how powerful your GPU has to be for these kinds of shaders - I don't consider the PS3's GPU to be powerful by any stretch of the imagination (in fact, it's weaker than 360's ATI chip, and it's a total pushover for modern-day PC GPUs), and it runs pretty much all of the shaders in my common-shaders repo effortlessly - even in FBO mode where you can run two shaders at a time - with frame buffer objects x4 the actual size of the game width/height. The RSX is a slightly modified Nvidia Geforce 7800-class GPU, so I'd say if your GPU is within the vicinity of that (or well over it), then you should be fine. If you have a 2009/2010 era Nvidia/Intel mobile GPU then you can pretty much forget it - my Geforce 9200M GS in one of my laptops has really crappy performance with SSNES when running these shaders - I can 'nearly' get 60fps with 2xSaL and that's one of the least-demanding shaders out there. Its performance is a total joke compared to the PS3/360 (ran the RE5 tech demo at 4/5fps IIRC).
-
This got buried a few posts ago -
Lantus - there was nothing wrong with your shader code it seems - I got the exact same result after finally adding HLSL shader support to SSNES 360. Perhaps there's some kind of bug or quirk that creates the below par image quality that we get with 5xBR v3.7c on 360.
On the other hand, 4xBR-v3.5+CRT.cg looks pretty much on par with how it looks on PS3 - so I'd just chalk it up to the 5xBR versions having some issues with HLSL and just settle for the 4x versions on 360 - which seem to look fine (2xBR looked very much the same as 5xBR on 360 - as in - not very good).
-
This is a quick and dirty cut-and-paste job, but I've implemented xBR 2x, 3x and 4x in FBA 0.2.97.24. I am not really a programmer and I've probably done 101 things wrong, so feel free to fix the attached files.
I couldn't get diff to work properly, so I'm just uploading the modified files instead to be unzipped over the 0.2.97.24 source.
I copied the xBR source code from the Paintown project, so I'm not sure if it is the latest version of xBR or not. Hyllian can suggest changes to xBR.cpp, if it is not.
After all those disclaimers and my obvious ineptitude, 3xBR makes 3rd Strike look fantastic on my 1360x768 monitor. I hope someone gets a kick out of it. :wink:
-
Nice one! Great contribution!
Looking at the sources, I can say they're the latest CPU filter editions I used in Kega Fusion plugins.
There are three xBR flavors: squared, semi-rounded and rounded. In Kega plugins I named them as "a", "b" and "c", respectively. These flavors differ mainly in how fonts and huds are treated.
In your sources, you've used "b" flavor for 2xBR and 4xBR, and "a" flavor for 3xBR. They differ only by these lines (look at the lines 127, 342 and 544 in your sources to see the flavors you're using):
"a" flavor:
if ((e<i) && ( !eq(PF,PB) && !eq(PF,PC) || !eq(PH,PD) && !eq(PH,PG) || eq(PE,PI) && (!eq(PF,F4) && !eq(PF,I4) || !eq(PH,H5) && !eq(PH,I5)) || eq(PE,PG) || eq(PE,PC)) )\
"b" flavor:
if ((e<i) && ( !eq(PF,PB) && !eq(PH,PD) || eq(PE,PI) && (!eq(PF,I4) && !eq(PH,I5)) || eq(PE,PG) || eq(PE,PC)) )\
"c" flavor:
if (e<i)\
I can't say which of them is the best. It depends on taste. You probably like more the "a" version. You could try adding all flavors to each, making a total of 9 xBR filter options.
-
Thanks guys.
I added support for each of the nine options to all the blitters that support softFX.
Would still really like to get some HLSL in there though. Guess I might have to start looking to DirectX programming at some point.
-
Thanks guys.
I added support for each of the nine options to all the blitters that support softFX.
Would still really like to get some HLSL in there though. Guess I might have to start looking to DirectX programming at some point.
You can take a look at xdk360_video.cpp and shader_hlsl.c from SSNES 360 - only some functions in the render context creation should be 360-specific, the rest should mostly work on PC.
I'm in the process of adding 'FBO mode' (render targets on D3D/HLSL) to it - which will enable two shader passes at once.
-
Thanks for your kind words, Hyllian. I'll experiment with which flavours of xBR I like best until 0.2.97.25 comes out with all of them added. :cool:
I'll have to keep recompiling because I don't want to mess up the menu any more than I already have, can anyone tell me what I missed? When I select 3xBR or 4xBR there's no indicator to say which SoftFX option is selected. It's a small thing, I know, but just in case I find another algorithm in future and want to experiment... :biggrin:
I'm still astounded that it works. All I did was copy the code, copy the function parameters from hq3x, then I just looked at how the other algorithms were added to the menu and copied that, although I didn't do that perfectly.
My main motivation for doing it was that I only have ancient onboard graphics in my PC, so HLSL and other shaders run really slowly.
-
Thanks for your kind words, Hyllian. I'll experiment with which flavours of xBR I like best until 0.2.97.25 comes out with all of them added. :cool:
I'll have to keep recompiling because I don't want to mess up the menu any more than I already have, can anyone tell me what I missed? When I select 3xBR or 4xBR there's no indicator to say which SoftFX option is selected. It's a small thing, I know, but just in case I find another algorithm in future and want to experiment... :biggrin:
I'm still astounded that it works. All I did was copy the code, copy the function parameters from hq3x, then I just looked at how the other algorithms were added to the menu and copied that, although I didn't do that perfectly.
More than likely it's the changes to menu.cpp that are required.
Specifically the CheckMenuRadioItem for each blitter menu needs updating to check all the filter menu items. After adding the nine options the enhanced menu code became;
CheckMenuRadioItem(hMenu, MENU_ENHANCED_SOFT_STRETCH, MENU_ENHANCED_SOFT_STRETCH + 33, var, MF_BYCOMMAND);
-
Ah, that's it, because I don't remember changing that. Thanks. :smilie:
-
Hi, lantus.
I've managed to make a xBR 3.7a shader work on 360 through the RetroArch emulator squarepusher is working.
This is the shader which works in hlsl mode: https://github.com/twinaphex/common-shaders/blob/master/xBR/hlsl/5xBR-v3.7a.cg (https://github.com/twinaphex/common-shaders/blob/master/xBR/hlsl/5xBR-v3.7a.cg)
I had to unroll all vector comparisons to make it work in hlsl mode. I don't know what happens, but it seems hlsl doesn't support vector comparisons.
For example, this line:
bool4 fx;
float4 Ao, Bo, Co;
fx = (Ao*fp.y+Bo*fp.x > Co);
I had to unroll to their components, that is, to scalar comparisons:
fx.x = (Ao.x*fp.y+Bo.x*fp.x > Co.x);
fx.y = (Ao.y*fp.y+Bo.y*fp.x > Co.y);
fx.z = (Ao.z*fp.y+Bo.z*fp.x > Co.z);
fx.w = (Ao.w*fp.y+Bo.w*fp.x > Co.w);
Do you have any idea why the first way only work in Cg mode? If it's the case, I think hlsl is less advanced than Cg.
-
https://github.com/twinaphex/common-shaders/
Dead link !
new link: https://github.com/libretro/common-shaders ?