First post, by NY00123
NOTE: It actually seems like I wasn't the first to try this: Re: Patch for OpenGL fullscreen bug. Haven't seen a recent response from that forum member, though.
[EDIT] Warning: Do not blame me if any arbitrary shader makes you feel bad (say dizzy) while using it. You're on your own anyway, and some things may currently be done in an improper way (technically).
I have attached a patch that adds basic GLSL shader support, along with a few sample shaders, one of them being an adaptation of this: https://gitorious.org/bsnes/xml-shaders/blobs … terlaced.shader.
Note that a pair of shader files (vertex and fragment) should go into a "glshaders" directory, located where the default DOSBox config file (i.e. dosbox-SVN.conf) is found. Basically, same as the "capture" dir. For more details see http://www.dosbox.com/wiki/Dosbox.conf.
Furthermore, the common filename (without the file extension) should be set in the DOSBox configuration file. Finally, OpenGL output is a must and it's also recommended to *disable* any software scaler. Furthermore, output=openglnb may work better.
Usage example for CRT-interlaced.glslf and CRT-interlaced.glslv:
Now, if one wonders why should that be done, especially considering the fact there is already a patch with shader support by gulikoza (actually a portion of a Direct3D patch), then here are a couple of reasons:
- Potentially prepare the GL code to be compatible with any environment that supports OpenGL ES 2.0 (but not desktop GL).
- Let the ones interested in that take advantage of shaders on a wider range of platforms.
Note that among the included shaders, there is an adaptation of the CRT-interlaced shader from a source tree relevant to the emulator that was known as bsnes (now named higan). It couldn't be used as-is, though, since I wanted to ensure it is ES 2.0 compatible. Basically, any usage of the fixed pipeline should be gone. In practice, the patch has not yet been tested with true OpenGL ES 2.0 (or OpenGL 3.1)...
It is further the case that a lot of the features of the XML shader file format described here are *not* implemented:
However, it seems to me the format has changed since then, and there are still more changes to come, unsurprisingly. Furthermore, it's just simpler for now to have a pair of basic shader files that can be loaded by DOSBox. The "default" files attached here are also used internally in DOSBox (after applying the patch), in case no shader is desired or one is not found. Finally, it is actually the case for now that, more often than not, a custom fragment shader can be compiled with the internal default vertex shader.
A couple of changes to the format for compatibility with ES 2 (not tested so far): Specify a precision in each fragment shader for the various floats, and manually pass a set of vertices from the DOSBox app (which runs on a CPU) to the vertex shader.
Note that currently the texture coordinates are *not* passed. These are calculated by the vertex shader using the inputs rubyTextureSize and rubyInputSize, along with the input vertex coordinates. It may be more efficient to simply pass these to the vertex shader, rather than let it re-calculate this (a few times per frame). For now, though, this is the case.
Finally, based on the XML shader format, an internal frame counter (rubyFrameCount) is incremented once per frame. In case a custom shader is used, this is done even if there is no actual update to the screen, while a refresh is done on the emulated machine's side. This is done using very little code reminding of stuff done in gulikoza's Direct3D patch. However, *no* buffer swap is done and the shader program is *not* being executed if there is no actual update. If it were the case then someone could complain that GL VSync doesn't work well when it does on vanilla DOSBox.