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.

Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h

1 
2#if C_OPENGL
3+#include <GL/glew.h>
4+#define C_OPENGL_USE_SHADERS 1
5+#ifdef C_OPENGL_USE_SHADERS
6+#define GL_GLEXT_PROTOTYPES
7+#define GL_SGIX_fragment_lighting
8+#endif
9 #include "SDL_opengl.h"

Hrm, I have been hoping for a patch that would support the xBR shaders. So right on.

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.

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.

ykhwong wrote:

Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h […]
Show full quote

Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h

Copy code to clipboard

1 
2#if C_OPENGL
3+#include <GL/glew.h>
4+#define C_OPENGL_USE_SHADERS 1
5+#ifdef C_OPENGL_USE_SHADERS
6+#define GL_GLEXT_PROTOTYPES
7+#define GL_SGIX_fragment_lighting
8+#endif
9 #include "SDL_opengl.h"

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

kekko wrote:

ykhwong wrote:

Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h […]
Show full quote

Try adding #include <GL/glew.h> and #define GL_SGIX_fragment_lighting before #include SDL_opengl.h

Copy code to clipboard

1 
2#if C_OPENGL
3+#include <GL/glew.h>
4+#define C_OPENGL_USE_SHADERS 1
5+#ifdef C_OPENGL_USE_SHADERS
6+#define GL_GLEXT_PROTOTYPES
7+#define GL_SGIX_fragment_lighting
8+#endif
9 #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.

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.

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=").

Nice! Thanks!

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:

1attribute vec4 a_position;
2varying vec2 v_texCoord;
3varying vec2 omega;
4uniform vec2 rubyTextureSize;
5uniform vec2 rubyInputSize;
6uniform vec2 rubyOutputSize;
7uniform int rubyFrameCount;
8
9void main()
10{
11  gl_Position = a_position;
12  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);
13
14  // Note that the x and y dimensions are swapped compared to the value in libretro/common-shaders/scanline.cg.
15  // If you don't swap them for DosBox then you get vertical scanlines.
16  omega = vec2(2.0 * 3.1415 * rubyTextureSize.y, 3.1415 * rubyOutputSize.x * rubyOutputSize.x / rubyInputSize.x);
17
18}

And the fragment shader:

1const float SCANLINE_BASE_BRIGHTNESS = 0.95;
2const float SCANLINE_SINE_COMP_A = 0.05;
3const float SCANLINE_SINE_COMP_B = 0.15;
4
5varying vec2 v_texCoord;
6varying vec2 omega;
7uniform sampler2D rubyTexture;
8
9void main()
10{
11  vec2 sine_comp = vec2(SCANLINE_SINE_COMP_A, SCANLINE_SINE_COMP_B);
12  vec3 res = texture2D(rubyTexture, v_texCoord).xyz;
13
14  vec3 scanline = res * (SCANLINE_BASE_BRIGHTNESS + dot(sine_comp * sin(v_texCoord * omega), vec2(1.0, 1.0)));
15
16  gl_FragColor = vec4(scanline.x, scanline.y, scanline.z, 1.0);
17}

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 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.

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 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/more-crt-shaders.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).

Laukku wrote:

Apparently not, as it seems to be RetroArch-only: http://filthypants.blogspot.fi/2015/04/more-crt-shaders.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.

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.