VOGONS

Common searches


Reply 20 of 36, by NY00123

User metadata
Rank Member
Rank
Member
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.

Reply 21 of 36, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie

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

 
#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"

Reply 23 of 36, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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.

http://www.si-gamer.net/gulikoza

Reply 24 of 36, by NY00123

User metadata
Rank Member
Rank
Member

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.

Reply 25 of 36, by kekko

User metadata
Rank Oldbie
Rank
Oldbie
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

 
#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

Reply 26 of 36, by NY00123

User metadata
Rank Member
Rank
Member
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

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

Reply 27 of 36, by NY00123

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    glshaders_20130829.zip
    File size
    13.2 KiB
    Downloads
    208 downloads
    File comment
    Updated sample shader files (swapping 'texture' for 'texture2D')
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_glsl_20130829.diff
    File size
    21.08 KiB
    Downloads
    200 downloads
    File comment
    Updated GLSL patch
    File license
    Fair use/fair dealing exception

Reply 28 of 36, by dugan

User metadata
Rank Newbie
Rank
Newbie

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

Attachments

  • Filename
    sabr.zip
    File size
    13.86 KiB
    Downloads
    164 downloads
    File comment
    SABR 3.0 and SABR-XCOMified
    File license
    Fair use/fair dealing exception
Last edited by dugan on 2015-05-02, 07:40. Edited 2 times in total.

Reply 29 of 36, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Nice! Thanks!

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 30 of 36, by dugan

User metadata
Rank Newbie
Rank
Newbie

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:

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:

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);
}

Attachments

  • Filename
    scanline.zip
    File size
    929 Bytes
    Downloads
    172 downloads
    File comment
    Scanline shader
    File license
    Fair use/fair dealing exception

Reply 32 of 36, by Great Dragon

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 34 of 36, by Laukku

User metadata
Rank Newbie
Rank
Newbie
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).

My YouTube account, with miscellanous DOS game stuff: http://www.youtube.com/user/LaukkuTheGreit

Reply 35 of 36, by konrad

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 36 of 36, by dugan

User metadata
Rank Newbie
Rank
Newbie

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.