Giter VIP home page Giter VIP logo

libretro / common-shaders Goto Github PK

View Code? Open in Web Editor NEW
1.0K 77.0 250.0 33.43 MB

Collection of commonly used Cg shaders. These shaders are usable by either HLSL and/or Cg runtime compilers. The cg2glsl script will translate most of these into GLSL shaders.

Home Page: http://www.libretro.com

Makefile 0.04% C++ 1.13% C 96.84% Pawn 0.43% MATLAB 0.25% Python 0.03% POV-Ray SDL 0.28% SourcePawn 1.01%

common-shaders's Introduction

================================
 -- Common shaders --
================================

This is a package of pixel shaders intended for old school emulators. 
Copyrights are held by the respective authors.
The shaders are coded in the Cg language, suitable for both OpenGL and D3D.
Most of these shaders are converted from other languages (GLSL, FX, HLSL, etc).

The shaders all follow a convention which must be followed by the implementer 
of an OGL/D3D backend.

Known implementations of this spec are currently:
- RetroArch
- SNES9x (Win32 port)
- OpenEmu

Entry points:
   Vertex: main_vertex
   Fragment: main_fragment

Texture unit:
   All shaders work on texture unit 0 (the default). 2D textures must be used.
   Power-of-two sized textures are recommended for optimal visual quality.
   The shaders must deal with the actual picture data not 
   filling out the entire texture.
   Incoming texture coordinates and uniforms provide this information.

   The texture coordinate origin is defined to be top-left oriented, i.e.
   a texture coordinate of (0, 0) will always refer to the top-left pixel of
   the visible frame. This is opposite of what most graphical APIs expect.
   The implementation must always ensure that this ordering is held for any
   texture that the shader has access to.

   Every texture bound for a shader must have black border mode set.
   I.e. sampling a texel outside the given texture coordinates must always return a pixel
   with RGBA values (0, 0, 0, 0).

Uniforms:
   Some parameters will need to be passed to all shaders, 
   both vertex and fragment program.
   A generic entry point for fragment shader will look like:

   float4 main_fragment (float2 tex : TEXCOORD0, 
      uniform input IN, uniform sampler2D s_p : TEXUNIT0) : COLOR
   {}

   The input is a struct looking like:
   struct input
   {
      float2 video_size;
      float2 texture_size;
      float2 output_size;
      float frame_count;
      float frame_direction;
   };

   TEXCOORD0: Texture coordinates for the current input frame will be passed in TEXCOORD0.
   (TEXCOORD is a valid alias for TEXCOORD0).

   COLOR0: Although legal, no data of interest is passed here.
   You cannot assume anything about data in this stream.

   IN.video_size: The size of the actual video data in the texture, 
   e.g for a SNES this will be generally 
   (256, 224) for normal resolution frames.

   IN.texture_size: This is the size of the texture itself. 
   Optimally power-of-two sized.

   IN.output_size: The size of the video output. 
   This is the size of the viewport shown on screen.

   IN.frame_count: A counter of the frame number. 
   This increases with 1 every frame. 
   This value is really an integer, 
   but needs to be float for CGs lack of integer uniforms.

   IN.frame_direction: A number telling which direction
   the frames are flowing. For regular playing, this value should be 1.0.
   While the game is rewinding, this value should be -1.0.

   modelViewProj: This uniform needs to be set in vertex shader. 
   It is a uniform for the current MVP transform.

Pre-filtering:
   Most of these shaders are intended to be used with a non-filtered input. 
   Nearest-neighbor filtering on the textures themselves are preferred.
   Some shaders, like scanline will most likely 
   prefer bilinear texture filtering.


Genres:
   There are several different types of shaders available, 
   some of the relevant types are sorted into folders.

   2x-classic:
      These are the typical, classic filters usually run on CPU, such as 
      HQ2x, 2xSaI, SuperEagle, etc, converted into shaders.

   Blur:
      Shaders focusing on bluring the output image.

   Enhance:
      Shaders focusing on enhancing the image quality 
      through other means than bluring only. 

   TV:
      Shaders focusing on replicating the visual image of a 
      game running on a CRT screen.

   Misc:
      Shaders that do not directly fit into any of the above categories.

   Meta:
      Contains meta-shaders *.cgp.


=============================
 -- Cg meta-shader format --
=============================

Rationale:
The .cg files themselves contain no metadata necessary to perform advanced
filtering. They also cannot process an effect in multiple passes, which
is necessary for some effects. The CgFX format does exist, but it would
need current shaders to be rewritten to a HLSL-esque format.
It also suffers a problem mentioned below.

Rather than putting everything into one file (XML shader format), this
format is config file based. This greatly helps testing shader combinations
as there is no need to rearrange code in one big file. Another plus with
this approach is that a large library of .cg files can be used to combine
many shaders without needing to redundantly copy code over. It also
helps testing as it is possible to unit-test every pass separately 
completely seamless.


Format:

The meta-shader format is based around the idea of a config file with the
format: key = value. Values with spaces need to be wrapped in quotes:
key = "value stuff". No .ini sections or similar are allowed. Meta-shaders
may include comments, prefixed by the "#" character, both on their own in
an otherwise empty line or at the end of a key = value pair.

The meta-format has four purposes:
-  Combine several standalone .cg shaders into a multipass shader.
-  Define scaling parameters for each pass. I.e., a HQ2x shader
   might want to output with a scale of exactly 2x.
-  Control filtering of textures. Many shaders will want nearest-neighbor
   filtering, and some will want linear.
-  Define external lookup textures. Shaders can access external textures
   found in .tga files.

Parameters:

-  shaders (int): This param defines how many .cg shaders will be loaded.
   This value must be at least one.
   The path to these shaders will be found as a string in parameters
   shader0, shader1, ... shaderN, and so on.
   The path is relative to the directory the meta-shader
   was loaded from.

- filter_linearN (boolean): This parameter defines how the texture of the 
   input to pass N will be filtered.
   N = 0 affects how the pass 0 (initial pass) samples the raw input frame.
   N = 1 affects how pass 1 samples the raw input frame; in other words, it controls the sampling of pass 0 output
   (A boolean value here might be true/false/1/0).
   Should this value not be defined, the filtering option is
   implementation defined.

-  float_framebufferN (boolean): This parameters defines if shader N
   should render to a 32-bit floating point buffer.
   This only takes effect if shaderN is actually rendered to an FBO.
   This is useful for shaders which have to store FBO values outside [0, 1] range.

-  frame_count_modN (int): This positive parameter defines
   which modulo to apply to IN.frame_count.
   IN.frame_count will take the value frame_count % frame_count_modN.

-  scale_typeN (string): This can be set to one of these values:
   "source":   Output size of shader pass N is relative to the input size
               as found in IN.video_size. Value is float.
   "viewport": Output size of shader pass N is relative to the size of the
               window viewport. Value is float.
               This value can change over time if the user 
               resizes his/her window!
   "absolute": Output size is statically defined to a certain size.
               Useful for hi-res blenders or similiar.

   If no scale type is assumed, it is assumed that it is set to "source"
   with scaleN set to 1.0.

   It is possible to set scale_type_xN and scale_type_yN to specialize
   the scaling type in either direction. scale_typeN however
   overrides both of these.

   Exceptions:
   If no scale_type is set for the very last shader,
   it is assumed to output at the full resolution rather than assuming
   a scale of 1.0x, and bypasses any frame-buffer object rendering. 
   If there is only one shader, it is
   also considered to be the very last shader. If any scale option
   is defined, it has to go through a frame-buffer object, and
   subsequently rendered to screen. The filtering option used when stretching
   is implementation defined. It is encouraged to not have any
   scaling parameters in last pass if you care about the filtering
   option here.

   In first pass, should no scaling factor be defined, the implementation
   is free to choose a fitting scale. This means, that for a single pass
   shader, it is allowed for the implementation to set a scale, 
   render to FBO, and stretch. (Rule above).

-  scaleN, scale_xN, scale_yN (float/int):
   These values control the scaling params from scale_typeN.
   The values may be either floating or int depending on the type.
   scaleN controls both scaling type in horizontal and vertical directions.

   If scaleN is defined, scale_xN and scale_yN have no effect.
   scale_xN and scale_yN controls scaling properties for the directions
   separately. Should only one of these be defined, the other direction
   will assume a "source" scale with value 1.0, i.e. no change in resolution.

   Should scale_type_xN and scale_type_yN be set to different values,
   the use of scaleN is undefined (i.e. if X-type is absolute (takes int),
   and Y-type is source (takes float).)

-  textures (multiple strings):
   The textures param defines one or more lookup textures IDs.
   Several IDs are delimited with ';'. I.e. textures = "foo;bar"
   These IDs serves as the names for a Cg sampler uniform. I.e.
   uniform sampler2D foo;
   uniform sampler2D bar;

   The path of the textures can be found in the IDs, i.e.
   foo = image0.tga
   bar = image1.tga
   The paths of these textures are relative to the directory
   the meta-shader was loaded from.

   It is also possible to control the filtering options of the
   lookup texture as a boolean option in ID_linear = true/false.
   I.e. foo_linear = false, will force nearest neighbor filtering
   for texture "foo". If this param is not set, it is assumed to be
   linearily filtered.

   The textures will be loaded "as-is", 
   and coordinates (0, 0), (0, 1), (1, 0), (1, 1) will correspond
   to the corners of the texture. Since the texture coordinates
   of the texture in TEXUNIT0 might not be as convenient,
   the texture coordinates for all lookup textures will be found
   in TEXCOORD1. (Note: You cannot assume which texture unit the
   lookup textures will be bound to however!)

   The implementation only guarantees to be able to
   load plain top-left non-RLE .tga files. 
   It may provide possibilities to load i.e. .png and other popular formats.


Multi-pass uniforms:

   During multi-pass rendering, some additional uniforms are available.

   With multi-pass rendering, it is possible to utilize the resulting output
   for every pass that came before it, including the unfiltered input.
   This allows for an additive approach to shading rather than
   serial style.

   The unfiltered input can be found in the ORIG struct:

   uniform sampler2D ORIG.texture: Texture handle. 
   Must not be set to a predefined texture unit.
   uniform float2 ORIG.video_size: The video size of original frame.
   uniform float2 ORIG.texture_size: The texture size of original frame.
   in float2 ORIG.tex_coord: An attribute input holding the texture
                             coordinates of original frame.

   PASS%u: This struct holds the same data as the ORIG struct,
   although the result of passes {1, 2, 3 ...}, i.e.
   PASS1.texture holds the result of the first shader pass.
   If rendering pass N, passes {1, ..., N-2} are available.
   (N-1 being input in the regular IN structure).

   PREV: 
   This struct holds the same data as the ORIG struct,
   and corresponds to the raw input image from the previous frame.
   Useful for motion blur.

   PREV1..6:
   Similar struct as PREV, but holds the data for passes further back in time.
   PREV1 is the frame before PREV, PREV2 the frame before that again, and so on.
   This allows up to 8-tap motion blur.


For backend implementers:
===================================
 -- Rendering the shader chain: --
===================================

With all these options, the rendering pipeline can become somewhat complex.
The meta-shader format greatly utilizes the possibility of offscreen
rendering to achieve its effects. 
In OpenGL usually this is referred to as frame-buffer objects,
and in HLSL as render targets (?). This feature will be referred to as
FBO from here. FBO texture is assumed to be a texture bound to the FBO.

As long as the visual result is approximately identical,
the implementation does not have
to employ FBO.

With multiple passes our chain looks like this conceptually:

|Source image| ---> |Shader 0| ---> |FBO 0| ---> |Shader 1| ---> 
|FBO 1| ---> |Shader 2| ---> (Back buffer)

In the case that Shader 2 has set some scaling params, we need to first render
to an FBO before stretching it to the back buffer.

|Source image| ---> ... |Shader 2| ---> |FBO 2| ---> (Back buffer)

Scaling parameters determine the sizes of the FBOs. For visual fidelity it
is recommended that power-of-two sized textures are bound to them. This
is due to floating point inaccuracies that become far more apparent when not
using power-of-two textures. If the absolute maximum size of the source image
is known, then it is possible to preallocate the FBOs.

Do note that the size of FBOn is determined by dimensions of FBOn-1 
when "source" scale is used, _not_ the source image size! 
Of course, FBO0 would use source image size, as there is no FBO-1 ;)

I.e., with SNES there is a maximum width of 512 and height of 478.
If a source relative scale of 3.0x is desired for first pass, it is thus safe to
allocate a FBO with size of 2048x2048. However, most frames will just use a
tiny fraction of this texture.

With "viewport" scale it might be necessary to reallocate the FBO in run-time
if the user resizes the window.

common-shaders's People

Contributors

alcaro avatar aliaspider avatar ccatington avatar crossvr avatar duganchen avatar dwedit avatar easymode- avatar fr500 avatar gjalsem avatar harlequinvg avatar hizzlekizzle avatar hunterk avatar hyllian avatar inactive123 avatar leilei- avatar monroe88 avatar mudlord avatar ov2 avatar refinedsoftwarellc avatar robloach avatar rz5 avatar tatsuya79 avatar themaister avatar timgates42 avatar trogglemonkey avatar velocityra avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

common-shaders's Issues

NTSC shaders

Whenever I use them in Retropie, my screen turns either black or pink

Any way to fix this?

crt-interlaced-halation GLSL

In RetroArch 1.4.1 x64, the GLSL version of crt-interlaced-halation is missing pass2, it's being called for in the glslp file

Motionblur-simple.cg

I'm using 0.9.9.6 x64 from the 10/13 megapack

i7 950
GTX 580
Video card drivers all set to application controlled -- nothing forced.

Whenever I add motionblur-simple.cg to my shader stack, no matter whether it is first or last, it always results in a blank/black/gray screen. No amount of changing the shader scale or nearest/linear filter makes a difference. Tried changing vysnc, hard sync, window scale, basically every option with no result. Core doesn't seem to matter -- it happens on gambatte, vba-m, and bsnes accuracy for sure. My main intent is to use a motion blur shader with dot.cg for my handheld games.

Coincidentally, because handheld/lcd_cgwg.cgp also uses motionblur-simple in it's passes, that shader does not work. braid-rewind.cg also does not work on it's own or otherwise. motionblur-blue.cg works.

I don't think it's system related... specifically because this shader works fine in my case and I will be using it for the time being... https://gist.github.com/eadmaster/4108112

I also tested motionblur-simple.cg on a spare laptop with a 460M and a fresh retroarch install with the same results.

There is no output to the console regarding any of this.

edit 10/31
Just confirmed motionblur-simple.cg does not work on my Samsung Galaxy S III i747 either.

"super-4xbr-3d" Possible to remove 3d mask?

I am experimenting some with different shaders, and I am wondering if anyone can help to remove the 3d mask on -

super-4xbr-3d-pass0
super-4xbr-3d-pass1
super-4xbr-3d-pass2
super-4xbr-3d-pass3

If it is possible to just open these with a text document and just remove some code line to make them filter everything. I really need this to be done on these certain xbr filters, so if anyone could help me I would be very glad!

I should add that the reason I want super-4xbr is because it's the only xbr filter I can get to work nice with 4x gpu resolution.

OR if anyone can tell me why super-xbr-6p wont work with 4x gpu resolution but only with native. If it is easier to make that work instead?

I also wonder if it is possible to use texture filtering at higher than native gpu resolution without it screwing up pre-rendered backgrounds?

crt-royale-fake-bloom-intel.cgp freeze retroarch on linux

Hello trying to use crt royale on my Intel® HD Graphics 4600 on linux but it causes a black screen and this error in console :
Mesa 10.2.4 implementation error: Failed to compile vertex shader: vec4
compile failed: no register to spill

How to debug shader loading?

I'm using RA from master on Fedora 24. I've noticed that there are many shaders (from the GLSL package downloaded via the updater) that upon loading.. do nothing. fx-aa.glsl is one example. However, running retroarch --verbose doesn't produce any errors regarding shader loading. Is there some way to find out why the shader doesn't load?

handheld/lcd_cgwg simple case sensitivity problem

In lcd-cgwg.cgp the motion blur file is referenced by

shader0 = Motionblur-simple.cg

but the file itself is named

motionblur-simple.cg

Notice the case of the letter "M". To this shaders fails to load on case sensitive filesystems (like mine here). Simply rename this file (or the reference) fixes the problem.

4x internal and up = lag

Hello,
I just have a question about mednafen in retroarch. I try to run games in 4 times internal but it causes lag no matter what I do. I have tried with threaded video on and it makes it better, but not enough. (I also have to turn that off in the config before restarting retroarch, because otherwise it crashes.)
It wont let me chose hardware rendering as a video option, only software. I dont know if that would fix it anyway.
My cpu is a i7 4790k and gpu a gtx 980ti and no other game is causing trouble, so it has nothing to do with drivers I suppose. I have also tried different versions on retroarch without succes.
I also emulated ps1 in 1999 on my Pentium 2 without much trouble so this does not make any sense. What am I doing wrong?

MAME's RGB3 effect / visual effect

I was wondering if this effect could be ported as shader or filter, this is the ultimate crt shader for me that's because the effect emulates perfectly a crt monitor I've just checked my old crt tv and it has the same grid as the RGB3 effect and the old arcades had that grid too.

Every crt shader I tested have a visual error that happens when any game comes from bright to dark the horizontal lines stand out so some of those lines are thicker than others.

The dotmask shader is similar to the RGB3 effect but the dots stand out a lot, on the other hand the RGB3 effect is flawless I can hardly see the dots even if I'm near the screen, and the games emulation in modern TVs dont look pixelate at all, besides there are no visual errors such as the afore mentioned.

CRT-Geom with thinner scanlines

Is it possible to modify the current version of crt-geom.cg to get thinner scanlines as shown on Game Tech Wiki?

With CURVATURE = "0.0" and SHARPER = "2.0" I get regular scanlines like this. But the goal is this - a fine mesh which contributes to a nice blending without an excessive amount of blur.

I guess it's all about this line: <fragment filter="nearest" outscale_x="1" outscale_y="2">. Is it possible to set outscale_x and outscale_y attributes in Cg shader? @Themaister, any help here?

Here is the full quote from GTW:

To obtain thinner, 480p-esque scanlines, first tweak the shader to apply greater sharpness, but only apply it to the TextureSize. The code should look like this:
uniform vec2 rubyTextureSize;
vec2 TextureSize = vec2(2*rubyTextureSize.x, 2*rubyTextureSize.y);
Again, this is for both the vertex and fragment portions. Don't forget to seek out any other instances of rubyTextureSize, and replace them with simply TextureSize.

Now, go to the beginning of the fragment portion, and modify it as such:
<fragment filter="nearest" outscale_x="1" outscale_y="2"><![CDATA[
This will only yield satisfactory results at 4x integer scale. Anything else will likely cause problems. It might also be wise to disable the phosphor emulation, as leaving it on produces a "grid"-like effect, which may or may not be desirable.

Bilateral blur shader, other blur shaders broken

The bilateral blur shader is broken. Its errors look like this:

RetroArch [ERROR] : : load_preset : : Failed to load shaders ...
RetroArch [WARN] : : gl_set_shader : : [GL]: Failed to set multipass shader. Falling back to stock.
RetroArch [ERROR] : : load_program : : CG error: The compile returned an error.
RetroArch [ERROR] : : load_program : : Fragment:
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(100) : error C5043: profile requires index expression to be compile-time constant
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(100) : error C5043: profile requires index expression to be compile-time constant
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(100) : error C5043: profile requires index expression to be compile-time constant
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(110) : error C5043: profile requires index expression to be compile-time constant
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(110) : error C5043: profile requires index expression to be compile-time constant
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(110) : error C5043: profile requires index expression to be compile-time constant
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(110) : error C5043: profile requires index expression to be compile-time constant
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(95) : error C5013: profile does not support "for" statements and "for" could not be unrolled.
C:\Program Files\RetroArch\shaders\blurs\bilateral.cg(105) : error C5013: profile does not support "for" statements and "for" could not be unrolled.


Many of the other shaders in the "blurs" folder are also broken. The errors they give look like this:

RetroArch [ERROR] : : load_preset : : Failed to load shaders ...
RetroArch [WARN] : : gl_set_shader : : [GL]: Failed to set multipass shader. Falling back to stock.
RetroArch [ERROR] : : load_program : : CG error: The compile returned an error.
RetroArch [ERROR] : : load_program : : Fragment:
C:\Program Files\RetroArch\shaders\blurs/.../include/quad-pixel-communication.h(86) : error C3004: function "float ddx(float);" not supported in this profile
C:\Program Files\RetroArch\shaders\blurs/.../include/quad-pixel-communication.h(86) : error C3004: function "float ddy(float);" not supported in this profile
C:\Program Files\RetroArch\shaders\blurs/.../include/gamma-management.h(419) : error C3004: function "float4 tex2Dlod(sampler2D, float4);" not supported in this profile
C:\Program Files\RetroArch\shaders\blurs/.../include/quad-pixel-communication.h(137) : error C3004: function "float3 ddx(float3);" not supported in this profile
C:\Program Files\RetroArch\shaders\blurs/.../include/quad-pixel-communication.h(138) : error C3004: function "float3 ddy(float3);" not supported in this profile
C:\Program Files\RetroArch\shaders\blurs/.../include/quad-pixel-communication.h(139) : error C3004: function "float3 ddy(float3);" not supported in this profile

Shader for PPSSPP's Hybrid Method

The Hybrid method from PPSSPP combines the sharp color transitions from xbr with smooth gradiants.

The algorithm is as follows:

  1. determine a feature mask C based on a sobel-ish filter + splatting, and upscale that mask bilinearly
  2. generate 2 scaled images: A - using Bilinear filtering, B - using xBRZ
  3. output = A_C + B_(1-C)

Step 1) and 3) needs a shader file to create the Hybrid look.
For 2) xBR/ Super xBR / or any other filter can be used.

PPSSPP Source Header:
https://github.com/hrydgard/ppsspp/blob/c2f4fad56aada331bbd8dd7db99037285bab853f/GPU/Common/TextureScalerCommon.h

PPSSPP Source CPP:
https://github.com/hrydgard/ppsspp/blob/c2f4fad56aada331bbd8dd7db99037285bab853f/GPU/Common/TextureScalerCommon.cpp

MAME RGB effects

Hi,
I'd like to ask if MAME RGB effects/masks (also found in FBA D3D7 blitter) can be added to RetroArch. I've found that these effects enhance the scaled image fidelity without altering it significantly.

Waifu2x ported as a shader

I was told by a forum member at ngemu to try and ask here. I wonder if anyone can port the Waifu2x upscaler and denoiser as a shader to use for PS1 emulation. You can see the result of Waifu in action here, and it looks amazing.
FFIX-
http://i.imgur.com/zR1kjlE.jpg

FFVII
http://i.imgur.com/CzRczDb.jpg

FFVII - 2
http://i.imgur.com/X27lVJ5.jpg

FFVII - 3
http://i.imgur.com/fYwxIBY.png

Seriously this needs to be done. If it is possible to play pre-rendered PS1 games like this (and well, realtime would also benefit) it just must be done. In worst case I could pay a little if the hussle is too much. Here is a URL to a Google translated Waifu2x site

https://translate.googleusercontent.com/translate_c?depth=1&hl=en&prev=search&rurl=translate.google.se&sl=ja&u=https://github.com/lltcggie/waifu2x-caffe/releases&usg=ALkJrhivu32FwUwuPxodRAFRTS4bRFPimA

/Mike

About [tex2dblurNxNshared] function in [blur-functions.h]

Accroding the reference document, and ddx, ddy gradient,
if using tex2Dblur12x12shared as example, with the quad layout (mirrored offset)

8a 7a 6a 6b 7b 8b
5a 4a 3a 3b 4b 5b
2a 1a 0a 0b 1b 2b
2c 1c 0c 0d 1d 2d
5c 4c 3c 3d 4d 5d
8c 7c 6c 6d 7d 8d

the quad vector for gathering should be

    quad_gather(quad_vector * sample1_texel_offset * pow(2, 1-tex_uv.w), sample1curr, sample1adjx, sample1adjy, sample1diag);
    quad_gather(quad_vector * sample2_texel_offset * pow(2, 1-tex_uv.w), sample2curr, sample2adjx, sample2adjy, sample2diag);
   ...and so on

otherwise the weighting and estimated sample doesn't match up.

Apply to a video stream?

Let me preface this by mentioning I know nothing about shaders outside of the context of video gaming, and little about them inside of it.

I love the PhosphorLUT shader, and it seems useful outside of RetroArch, say, for nostalgia purposes, or perhaps for other emulators that don't support the libretro framework, or for video processing. (on a 4K screen it's easier on the eyes than any other upscaling method I've seen).

I figure the latter would probably be relatively easy, even. But I have no idea where to start. In short (unless someone more knowledgeable than me thinks this is the wrong question to ask), is it possible to pipe an arbitrary video stream to a set of .cg programs, to "watch" it with the filters applied? What about for a capture card or TV tuner? I guess if patching VLC to process with .cg filters (if this doesn't exist natively within it already) would solve these.

If I'm not out of my mind for wanting to do so as a first program in a new language, would anyone have the faintest idea where to start to go about doing that?

xBRshaders crash the OpenGL driver

I'm using Windows 7 x64, my video card is an nVidia GTX570.

I was testing some shaders, xBR shaders just won't work, if loaded at startup window will open and close immediately.

Running from the console gives me this:

C:\Games\Emulators\RetroArch>retroarch.exe "Mega Man 8 (USA).cue"
***WARNING USING SINGLE-THREADED CD READER***
unhandled setting UI: psx.input.port1.gun_chairs
unhandled setting UI: psx.input.port2.gun_chairs
unhandled setting UI: psx.input.port3.gun_chairs
unhandled setting UI: psx.input.port4.gun_chairs
unhandled setting UI: psx.input.port5.gun_chairs
unhandled setting UI: psx.input.port6.gun_chairs
unhandled setting UI: psx.input.port7.gun_chairs
unhandled setting UI: psx.input.port8.gun_chairs
psx.bios_na: C:/Games/Emulators/RetroArch/scph5501.bin
[mednafen]: Module psx doesn't support save states.
RetroArch [ERROR] :: Implementation does not support save states. Cannot use rewind.

PS-X Realtime Kernel Ver.2.5
Copyright 1993,1994 (C) Sony Computer Entertainment Inc.
KERNEL SETUP!

Configuration : EvCB 0x10 TCB 0x04

crt-interlaced-halation.cgp w/ Genesis Plus GX

0.9.9.6 x64 from the 10/13 megapack, fresh config for testing

When using crt-interlaced-halation.cgp with a Sega Master System game, it results in a blank/black/gray screen. I want to note it also does not work with Sega Game Gear games, but that's not a big deal since those shouldn't appear on a CRT anyway.

This also happens with the CRT-Geom shaders obtained from the first link in this blog post by HunterK, which also has halation, curvature, etc... so that might provide some insight somehow. I personally use CRT-Geom because it doesn't produce that damn black pixel in the middle. XP

This does not affect Sega Genesis... it looks great w/ CRT shaders. And of course it works fine with SNES and NES.

Documentation and licensing

I think this collection could really use a README that lists off the the shaders, what they do, and what license they are under. In addition, some of these shaders are GPL instead of LGPL, which complicates the licensing of any program that wants to utilize them.

Interlacing shader looks wrong on Full screen games

Games with top and bottom bars look fine with the interlacing shader

ff771411

Whereas games that are full screen (which accounts for most games) look wrong with the interlacing shader. The distribution of lines look wrong
retroarch-0704-071539

HLSL/FX11 modification broke shaders on windows

Many shaders like crt-geom or lcd-grid-v2 aren't working anymore on win7 x64 with an Nvidia card here.

[INFO] [CG]: Loading Cg shader: "shaders/crt/shaders/crt-geom.cg".
[ERROR] CG error: The compile returned an error.
[ERROR] Fragment:
shaders/crt/shaders/crt-geom.cg(88) : error C0000: syntax error, unexpected '(',
 expecting '{' at token "("
shaders/crt/shaders/crt-geom.cg(220) : error C0000: syntax error, unexpected ')'
, expecting "::" at token ")"
shaders/crt/shaders/crt-geom.cg(234) : error C0000: syntax error, unexpected '.'
, expecting "::" at token "."
shaders/crt/shaders/crt-geom.cg(294) : error C0000: syntax error, unexpected '='
, expecting "::" at token "="
shaders/crt/shaders/crt-geom.cg(312) : error C0000: syntax error, unexpected '='
, expecting "::" at token "="
shaders/crt/shaders/crt-geom.cg(320) : error C0000: syntax error, unexpected '='
, expecting "::" at token "="
shaders/crt/shaders/crt-geom.cg(323) : error C0000: syntax error, unexpected '='
, expecting "::" at token "="
shaders/crt/shaders/crt-geom.cg(354) : error C0000: syntax error, unexpected '.'
, expecting "::" at token "."
shaders/crt/shaders/crt-geom.cg(362) : error C0000: syntax error, unexpected "*=
", expecting "::" at token "*="
shaders/crt/shaders/crt-geom.cg(371) : error C0000: syntax error, unexpected "*=
", expecting "::" at token "*="

[ERROR] Failed to load shaders ...
[INFO] [CG]: Destroying programs.
[INFO] [CG]: Vertex profile: gp5vp
[INFO] [CG]: Fragment profile: gp5fp
[INFO] [CG]: Loading stock Cg file.
[INFO] [CG]: Found semantic "POSITION" in prog #24.
[INFO] [CG]: Found semantic "COLOR" in prog #24.
[INFO] [CG]: Found semantic "TEXCOORD0" in prog #24.
[INFO] [CG]: Found semantic "POSITION" in prog #23.
[INFO] [CG]: Found semantic "COLOR" in prog #23.
[INFO] [CG]: Found semantic "TEXCOORD0" in prog #23.
[INFO] [CG]: Found semantic "POSITION" in prog #22.
[INFO] [CG]: Found semantic "COLOR" in prog #22.
[INFO] [CG]: Found semantic "TEXCOORD0" in prog #22.
[WARN] [GL]: Failed to set multipass shader. Falling back to stock.

CRT Shader Rotation for Vertical MAME Games

Current CRT shaders don't rotate for vertically orientated games in MAME. Would it be possible to add auto detection to them so if they see a game running at something like 240x320, the scanlines and shadowmask are rotated? Or maybe a manual vertical parameter?

I've seen some discussion about a version of Lottes shader modified for vertical games in MAME here: http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=331810&page=0&view=expanded&sb=5&o=&vc=1

more realistic Handheld shader

the Handheld "dot" shader doesn't look very realistic, especially in fullscreen mode.

What about porting the "LCD3x" filter by gigahertz? (the best i've seen so far)
EDIT: i've posted a request here: gigaherz/lcd3x#2

Also i'm looking for a plain motion blur shader (it is present in many old portable LCDs).

[Request] More color variants for console-border

I'm loving the recent additions of the console-borders for Game Gear, GameBoy Advance, and GameBoy Pocket! They are one of the main reasons I'm upgrading my install of RetroArch.

I'd like if there were more color variants of some of them. For example, a silver Pocket and an indigo Advance as that's what I had back in the day and it would give me dem feels.

Either include the .psds, OR with [probably a lot of] work we can have the "body" of the devices separated from the buttons and such so it can be more easily edited. I would directly edit the pngs myself but I'm not good at masking off the buttons and screen area. I gave it a quick go once already and I did pretty awful.

[Request] Magnify/Overscan Shader

In Reshade there is a shader called Magnify which can stretch each side of the screen individually in order to remove bars, glitches, etc on the edges of the screen. I would like for this to be ported or created for the common shaders. Using it from Reshade results in scanlines being messed up because of Reshade manipulating the entire screen. But if it were a shader, I wouldn't have to worry about the scanlines being messed up. This is needed for things like the nes cores. Where they have top/bottom and left/right grouped together. Some games might need one side tinkered with. Like the nes, usually needs just the left and the top tinkered with. The current overscan option for nes takes away too much from the bottom as it overscans the top. The reshade shader can take away from the top while still keeping the bottom intact. So if someone can create this, that would be great.

[Feature Request] Presets to emulate specific CRT TV/monitor models accurately

As the title suggests, I think it would be a neat feature if we had presets which would emulate popular/notable CRT TVs. Ideally these presets would not just be 'good enough', they'd be as accurate as the base shader allows.

Since RetroArch/libretro supports overlays/borders to fill the black space which is sometimes present while using emulator cores, these new presets could have high quality pictures of the CRTs they're modelling as borders.

To my knowledge, the shader which exposes the most CRT related parameters is @TroggleMonkey's crt-royale set of shaders, so ideally the presets would be based on this.

The author of each preset would ideally be in possession of the CRT he's modelling as well as a calibrated 100% sRGB color space 4K resolution display to work on.

Based on a cursory read of this Tested article, here are some preset names we could have:

crt-baseShaderName-Sony-BVM-20F1U.glslp
crt-baseNameShader-Sony-BVM-D32E1WU.glslp
crt-baseShaderName-Sony-PVM-20M4U.glslp
crt-baseShaderName-Sony-FD-Trinitron-WEGA-KD-34XBR960.glslp

ePSXe

Just one question Hyllian, is "super-4xbr-3d-6p-smoother" possible to get for ePSXe?

Interlacing shader reports warning message

I'm using the stable build from Arch repos.
Since a recent RetroArch git build interlacing shader has started to consistently output a "RetroArch [INFO] :: Shader log: 0:135(17): warning: `_ret_0' used uninitialized" message while loading. There doesn't seem to be any difference in video output.

[Request] Side-by-side shader for playing on an HMD

Would it be possible to create a simple side-by-side type shader (scale game down a little, place same cloned video on left and right side of screen) for use with an HMD (Oculus Rift, Google Cardboard/other phone HMD)?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.