VIDEO - Basic GLSL shader support (prototype)

Here you can discuss the development of patches.

Re: Basic GLSL shader support (prototype)

Postby NY00123 » 2013-7-24 @ 20:36

kekko wrote:sorry to bother again, sources patched correctly, but linker can't find some gl function instance:

<snip>


It is basically what happens when different GL functions are given out-of-the-box on different platforms. I'd say the most portable solution for that (late October edit: may actually be wrong) is really retrieving *all* GL functions dynamically (say with SDL_GL_GetProcAddress). I have come up with the currently given form while working on this, though.

Some more details about the way I've made it work for now on GNU/Linux with X11: I have added a definition of the macro GL_GLEXT_PROTOTYPES right before including SDL_opengl.h. Unfortunately it means that a few declarations of function pointers in sdlmain.cpp (within stock DOSBox) like glGenBuffersARB result in naming conflicts. So, these are simply commented out for now.

EDIT (October 13th): Sadly it looks like some things are no as simple as I've hoped. To be more specific, you can't trust a loader function like SDL_GL_GetProcAddress as a way of checking for the existence of a GL function, core or not, even if it appears to work locally. Let's hope what I've done in the last update to the patch (see later post) works, where the only additional functions dynamically retrieved are Core 2.0 functions.
Last edited by NY00123 on 2013-10-13 @ 08:02, edited 4 times in total.
NY00123
Member
 
Posts: 219
Joined: 2010-2-13 @ 19:42

Re: Basic GLSL shader support (prototype)

Postby ykhwong » 2013-7-24 @ 21:00

Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h
Code: Select all
 
#if C_OPENGL
+#include <GL/glew.h>
+#define C_OPENGL_USE_SHADERS 1
+#ifdef C_OPENGL_USE_SHADERS
+#define GL_GLEXT_PROTOTYPES
+#define GL_SGIX_fragment_lighting
+#endif
 #include "SDL_opengl.h"
ykhwong
Oldbie
 
Posts: 627
Joined: 2004-3-17 @ 15:35

Re: Basic GLSL shader support (prototype)

Postby kolano » 2013-7-25 @ 03:04

Hrm, I have been hoping for a patch that would support the xBR shaders. So right on.
User avatar
kolano
Oldbie
 
Posts: 526
Joined: 2010-12-26 @ 21:03

Re: Basic GLSL shader support (prototype)

Postby gulikoza » 2013-7-25 @ 07:14

AFAIK all functions that are not part of OpenGL 1.1 have to be retrieved dynamically. Windows platform will always link with 1.1 lib only, since any additional functionality is provided by the graphics drivers, not the core library.
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Basic GLSL shader support (prototype)

Postby NY00123 » 2013-7-25 @ 08:11

I have just heard (from Dominus) that the patched DOSBox fails to work as expected on a machine where he has tried to run it, since one of the internal shaders can't be compiled. A reported error tells that the function 'texture' is undefined.
If anybody gets that, for now you may use any of the shaders I have bundled before (default included), although you should edit any of these, replacing all occurrences of the 'texture' function with 'texture2D'. Originally I have refrained from using 'texture2D' since it is deprecated in OpenGL 3.3 and OpenGL ES 3.0. However, for now it may be the wrong thing to do, it seems.

gulikoza wrote:AFAIK all functions that are not part of OpenGL 1.1 have to be retrieved dynamically. Windows platform will always link with 1.1 lib only, since any additional functionality is provided by the graphics drivers, not the core library.


Yeah, this is an example of what I have referred to in my last post. Truly, it's especially noticeable on the Windows platform (for Win32 apps), with no references to newer OpenGL versions being gradually added to the platform itself.
NY00123
Member
 
Posts: 219
Joined: 2010-2-13 @ 19:42

Re: Basic GLSL shader support (prototype)

Postby kekko » 2013-8-09 @ 19:26

ykhwong wrote:Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h
Code: Select all
 
#if C_OPENGL
+#include <GL/glew.h>
+#define C_OPENGL_USE_SHADERS 1
+#ifdef C_OPENGL_USE_SHADERS
+#define GL_GLEXT_PROTOTYPES
+#define GL_SGIX_fragment_lighting
+#endif
 #include "SDL_opengl.h"


that makes it build the sources, but program crashes on GFX_LoadGLShader --> glCreateShader
User avatar
kekko
Member
 
Posts: 480
Joined: 2004-3-24 @ 18:56

Re: Basic GLSL shader support (prototype)

Postby NY00123 » 2013-8-09 @ 21:11

kekko wrote:
ykhwong wrote:Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h
Code: Select all
 
#if C_OPENGL
+#include <GL/glew.h>
+#define C_OPENGL_USE_SHADERS 1
+#ifdef C_OPENGL_USE_SHADERS
+#define GL_GLEXT_PROTOTYPES
+#define GL_SGIX_fragment_lighting
+#endif
 #include "SDL_opengl.h"


that makes it build the sources, but program crashes on GFX_LoadGLShader --> glCreateShader


A couple of problems I see with this approach:
- GL_SGIX_fragment_lighting sounds like an extension unavailable on the Windows platform to me.
- There is no additional function call added, so how can the driver-dependent implementations of functions like glCreateShader be determined?

Sadly, I think the simplest solution is still manually retrieving *all* of the (driver-dependent) "problematic" GL functions using SDL_GL_GetProcAddress. The reason this problem exists even on recent releases of Windows is that, obviously, people from Microsoft prefer that developers use Direct3D, rather than OpenGL.
NY00123
Member
 
Posts: 219
Joined: 2010-2-13 @ 19:42

Re: Basic GLSL shader support (prototype)

Postby NY00123 » 2013-8-29 @ 20:55

A minor update to the GLSL patch, along with the sample shader files, is attached.

- All occurrences of the keyword 'texture' in the fragment shader files have been replaced with 'texture2D'. While 'texture2D' may be deprecated in GL 3.3 and GL ES 3.0, 'texture' is not available on older setups, it seems.
- The same has been done in the internal default fragment shader within the patch itself.
- This one is for the Windows users, I believe: All GL 2.0 functions required for the GLSL functionality are queried from the driver now, using SDL_GL_GetProcAddress. The core variant of every GL 2.0 function is chosen, even if there is, say, an ARB variant. Example: glCompileShader vs glCompileShaderARB.
- Note that I have not actually tested this on Windows so far!
- The macro C_OPENGL_USE_SHADERS is gone, and shaders are used if all such GL 2.0 functions are available. If not, then the usual non-GLSL path should be used, at least in theory. To pick the right path, for now the modified code simply checks if none of the retrieved function pointers is a NULL pointer.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 219
Joined: 2010-2-13 @ 19:42

Re: Basic GLSL shader support (prototype)

Postby dugan » 2015-5-02 @ 07:23

Envy Windows users and their ability to use xBR shaders no longer. I've converted two xBR shaders to use with this patch. You can find them in the attached zip file.

SABR 3.0

Screenshot

Joshua Street's SABR shader. Forked from 5xBR 3.7c and currently on version 3.0. Incidentally, the only pixel-smoothing shader included with Mednafen.

Source

SABR-XCOMified

Screenshot

Built by the OpenXCom community to be an improvement on SABR.

Source
OpenXCom Mod Info

As you can see from their screenshots, they're more similar than different, and the differences are quite subtle. They are, after all, both xBR.

These go in the usual place (~/.dosbox-SVN/glshaders, on my Linux box), and they're activated in the usual way ("glshader=").
You do not have the required permissions to view the files attached to this post.
Last edited by dugan on 2015-5-02 @ 07:40, edited 2 times in total.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

Re: Basic GLSL shader support (prototype)

Postby Dominus » 2015-5-02 @ 07:38

Nice! Thanks!
User avatar
Dominus
DOSBox Moderator
 
Posts: 7545
Joined: 2002-10-03 @ 09:54
Location: Vienna or Ludwigsburg

Re: Basic GLSL shader support (prototype)

Postby dugan » 2015-12-23 @ 15:56

I converted Libretro's Cg scanline shader to this format, mainly to prove to myself that I could do it. It ended up being a very clean port. The zipfile is attached, and the shaders themselves are small enough to just inline.

At the very least, it should be a useful example for people who want to convert more RetroArch shaders.

There's a small change in the names of the uniforms: rubyTextureSize is "texture_size", rubyInputSize is "video_size", and rubyOutputSize is "output_size". The texture coordinates (v_texCoord in this implementation) and sample (rubyTexture) are passed as parameters to the fragment shader's main method and are given arbitrary names in the code.

There was also one vector in the vertex shader where I had to swap the X and Y values, to get horizontal instead of vertical scanlines. This is no doubt because Cg shaders expect texture coordinates in a weird order.

Anyway, here's the vertex shader:

Code: Select all
attribute vec4 a_position;
varying vec2 v_texCoord;
varying vec2 omega;
uniform vec2 rubyTextureSize;
uniform vec2 rubyInputSize;
uniform vec2 rubyOutputSize;
uniform int rubyFrameCount;

void main()
{
  gl_Position = a_position;
  v_texCoord = vec2((a_position.x+1.0)/2.0*rubyInputSize.x/rubyTextureSize.x,(1.0-a_position.y)/2.0*rubyInputSize.y/rubyTextureSize.y);

  // Note that the x and y dimensions are swapped compared to the value in libretro/common-shaders/scanline.cg.
  // If you don't swap them for DosBox then you get vertical scanlines.
  omega = vec2(2.0 * 3.1415 * rubyTextureSize.y, 3.1415 * rubyOutputSize.x * rubyOutputSize.x / rubyInputSize.x);

}


And the fragment shader:

Code: Select all
const float SCANLINE_BASE_BRIGHTNESS = 0.95;
const float SCANLINE_SINE_COMP_A = 0.05;
const float SCANLINE_SINE_COMP_B = 0.15;

varying vec2 v_texCoord;
varying vec2 omega;
uniform sampler2D rubyTexture;

void main()
{
  vec2 sine_comp = vec2(SCANLINE_SINE_COMP_A, SCANLINE_SINE_COMP_B);
  vec3 res = texture2D(rubyTexture, v_texCoord).xyz;

  vec3 scanline = res * (SCANLINE_BASE_BRIGHTNESS + dot(sine_comp * sin(v_texCoord * omega), vec2(1.0, 1.0)));

  gl_FragColor = vec4(scanline.x, scanline.y, scanline.z, 1.0);
}
You do not have the required permissions to view the files attached to this post.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

Re: Basic GLSL shader support (prototype)

Postby dugan » 2016-2-21 @ 01:30

I've built on this for My Dosbox Fork. It has a good selection of shaders, including several CRT shaders and several xBR shaders.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

Re: Basic GLSL shader support (prototype)

Postby Great Dragon » 2017-2-07 @ 21:38

dugan wrote:I've built on this for My Dosbox Fork. It has a good selection of shaders, including several CRT shaders and several xBR shaders.

Hello Dugan,

How actually can I use your shaders? I've tried to use"crt-lottes" with DosBox SVN ECE (renamed extensions to glslf/v) but a picture is just turned into a black box.
User avatar
Great Dragon
Newbie
 
Posts: 31
Joined: 2016-6-16 @ 23:58

Re: Basic GLSL shader support (prototype)

Postby konrad » 2017-2-19 @ 17:21

is it or would it be possible somehow to use retroarch's "crt-royale" shader with directly with dosbox (the dosbox core in retroarch is not really very usable).
konrad
Newbie
 
Posts: 12
Joined: 2012-9-02 @ 13:03

Re: Basic GLSL shader support (prototype)

Postby Laukku » 2017-2-19 @ 18:16

konrad wrote:is it or would it be possible somehow to use retroarch's "crt-royale" shader with directly with dosbox (the dosbox core in retroarch is not really very usable).

Apparently not, as it seems to be RetroArch-only: http://filthypants.blogspot.fi/2015/04/ ... aders.html
This shader was written by a guy named TroggleMonkey and it uses some intense, RetroArch-specific black magic to overcome many of the issues with CRT emulation that I thought were unavoidable, particularly using large-scale blurring passes without totally wrecking performance and making a true RGB phosphor / shadow mask that looks good at less than 4K resolution. As I said, it is Cg-only and only works on RetroArch, at that (i.e., no OpenEmu, even though it supports Cg in general).
My YouTube account, with miscellanous DOS game stuff: http://www.youtube.com/user/LaukkuTheGreit
User avatar
Laukku
Newbie
 
Posts: 49
Joined: 2011-8-31 @ 06:27

Re: Basic GLSL shader support (prototype)

Postby konrad » 2017-2-20 @ 11:42

Laukku wrote:Apparently not, as it seems to be RetroArch-only: http://filthypants.blogspot.fi/2015/04/ ... aders.html


hm, too bad...it's by far the best one i've ever used. i don't really understand what exactly it is about this shader that would only work in retroarch...i mean it's just a shader right? a very complex shader but still...it should be possible to port it somehow...? then again, unfortunately i really don't know anything about this stuff.
konrad
Newbie
 
Posts: 12
Joined: 2012-9-02 @ 13:03

Re: Basic GLSL shader support (prototype)

Postby dugan » 2017-2-25 @ 04:36

The shaders for my DosBox fork will only work with my DosBox fork, because they require the OpenGL 3 backend that I wrote for my DosBox fork to support them. This backend only supports single-pass shaders, and thus will not support multi-pass shaders such as CRT Royale.

I didn't even know about ECE until just now. I haven't been able to see its source code (is it available?), but it's likely that ECE's shaders require a different version of GLSL and different uniforms (values passed from the program to the shader) than what my shaders expect. If ECE's shader support is based on what's at the beginning of this thread, which is likely, then that is definitely the case.

Note: the next time you need an answer for "why doesn't this work with ECE", you should really ask the maintainer of ECE.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests