Is this what you're looking for? - http://www.si-gamer.net/gulikoza/img/PrinceCRT.png

if so, get a Direct3D-enabled build with pixel shader support (such as ykhwong's SVN-Daum) and use "CRT.D3D.fx" which is available here: http://www.si-gamer.net/gulikoza/dosbox.html#Download

be ready to throw lots of GPU power at it though.

Opengl will smoothen things out a little bit but also mask/hide pixels of different sizes.

What resolution do you render the images at? If you have it scale to 1024 x 768 with opengl it shouldn't be very blurry at all. Openglnb on the other hand will give you razer sharp pixels, but at the cost of seeing pixels of different sizes quite clearly.

Could you post your config file here (and what desktop resolution you typically use with that CRT) and I'll try to optimise it a bit!

Thank you for the replies! 😀

Oh wow, were the scan lines really that heavy? I can get them if I set my monitor to 640x480, but while visible, they don't really soften the image like that.

Currently I have been experimenting with following setups:

fullresolution=640x480(faint scan lines), or 800x600, 1024x768 (No difference between those two)
output=opengl
scaler=none

This generally gives a blurry, rounded appearance to everything. If I change "scaler=normal2x" and "full resolution=800x600 or 1024x768" I get a less blurry, but also less rounded image.

The CRT itself is a 17" (Highest flicker-free res. is 1024x768 @ 85hz) .

I'll try out those Shaders and get some SS and my config up when I'm home.

Ok for 1024 x 768 resolution I recommend:

[sdl]
fullscreen=true
fullresolution=1024x768
output=opengl

[render]
frameskip=0
aspect=true
scaler=normal3x

Soundbrave wrote:

Oh wow, were the scan lines really that heavy? I can get them if I set my monitor to 640x480, but while visible, they don't really soften the image like that.

That's because the scanlines produced by your CRT are much finer than those produced by CGA/Tandy/EGA monitors. On VGA and up, low resolutions like 320x200 are scan-doubled, so each pixel occupies two scanlines which makes it look more like a small block than a dot.
CGA/Tandy/EGA monitors have a true 200-line mode - only one scanline for each row of pixels, so the scanlines are much thicker. That D3D CRT shader isn't perfect, but it's pretty close to the real deal... compare with this photo of a Tandy CM-11: http://www.oldskool.org/guides/tvdog/images/T … wclockLarge.jpg

Using opengl at a higher-than-original resolution without a scaler is blurry and rounded, but for the wrong reasons, and really not comparable to the output of a 200-line monitor. Some people even claim to prefer that kind of blur, but why they do is completely beyond me. ;)

If you use normal2x along with the crt shader, you'll get the doublescanned version 😉

Cool, thank you for the info! I seem to recall that the first PC I had, while an 8086 processor, had a VGA card and VGA monitor (this would have been late 80s, possibly 90 or so?) Which is probably why I don't recall those scanlines.. or just being too young then.

I tried out that shader, and it is pretty neat! The monitor curvature that it emulates is a bit much, since I'm already using a non-flat CRT. It also doesn't seem to want to work with the custom config files I use for different games, either, I have to use dosbox's default config file. I will play around with it some more. 😀

The curvature can be easily modified by editing the .fx file.

[Thread moved to DOSBox General Section]

gulikoza wrote:

If you use normal2x along with the crt shader, you'll get the doublescanned version 😉

Eh, not quite, at least not how a more modern CRT monitor would display it. At 4x scale, a double-scan version of the shader would display very thin scanlines, about half as thin as the regular shader's, effectively simulating 400 lines.

I have looked high and low, and tried many different things, but only by using DOSBox through RetroArch have I been able to achieve a somewhat similar effect:

I got this effect with a few minor additions to the shader code, but unfortunately I have no clue how to port the modification to the format that the DOSBox D3D patch uses, since it requires some RetroArch-exclusive shader spec features, namely the outscale attributes described here:

http://gitorious.org/bsnes/pages/XmlShaderFormat

Now, this wouldn't be an issue, except that the DOSBox core for RetroArch, or at least the only compiled version I could find, is buggy as hell, and either doesn't work right with some games or crashes outright with others. I would love to use this version of the shader with the more compatible D3D version of DOSBox, but I have no idea how to port the changes over to the existing D3D CRT shader. It's a shame, because while it's not perfect, I think it's more faithful to how DOS games in the VGA era look on modern CRT monitors, rather than the standard version, which seems more fit for pre-VGA DOS games and console games.

For reference, this is the shader code used to create that shot:

http://www.mediafire.com/download.php?42oj7soib3pzjnv

If someone could somehow recreate this for use with regular DOSBox, that'd be awesome.

I won't pretend to be an expert, certainly getting a true emulation would require shaping each individual pixel...but I believe the CRT shader is pretty close at least in the part of creating that nostalgic feeling even if not pixel perfect.

I only had my old IIyama VisionMaster Pro 450 for the reference (and it's also the one I most used to), there are some shots in the D3D patch thread: Re: Direct3D patch (Host). Having normal2x also requires more output pixels to achieve the desired effect (say 1200 vertical resolution so shader has some space when working with 400 instead of 200 input lines). When I posted the pic of the updated CRT shader I had a bug where dot-mask was not applied correctly. Here's an image running at 1600x1200, I can't really spot much difference (normal2x + crt shader).

But I'll check your code and see what I can come up with.

It's fairly easy to port the changes. Visually I can't really spot any differences between this one and the previous one+normal2x at 1600x1200 (apart from parameter changes of course), but I agree this version might be better lower resolutions. You can try it, but I believe the only build that supports it is the one posted in the Glide thread: Re: Glide patch

1--- CRT-geom-curved.fx  2013-04-30 13:57:05.192607064 +0200
2+++ CRT-geom-flat-monitor.fx    2013-04-30 13:51:32.774024000 +0200
3@@ -25,7 +25,7 @@
4   #define LINEAR_PROCESSING
5
6   // Enable screen curvature.
7-  #define CURVATURE
8+  //#define CURVATURE
9
10   // Enable 3x oversampling of the beam profile
11   #define OVERSAMPLE
12@@ -42,7 +42,7 @@
13   float monitorgamma = 2.2;
14
15   // overscan (e.g. 1.02 for 2% overscan)
16-  float2 overscan = { 0.99, 0.99 };
17+  float2 overscan = { 1.0, 1.0 };
18
19   // aspect ratio
20   float2 aspect = { 1.0, 0.75 };
21@@ -52,18 +52,18 @@
22   float d = 2.0;
23
24   // radius of curvature
25-  float R = 2.0;
26+  float R = 1.5;
27
28   // tilt angle in radians
29   // (behavior might be a bit wrong if both components are nonzero)
30-  float2 angle = { 0.0, -0.0 };
31+  float2 angle = { 0.0, 0.001 };
32
33   // size of curved corners
34-  float cornersize = 0.03;
35+  float cornersize = 0.001;
36
37   // border smoothness parameter
38   // decrease if borders are too aliased
39-  float cornersmooth = 80.0;
40+  float cornersmooth = 1000.0;
41
42   // END of parameters
43
44@@ -269,7 +269,7 @@
45
46     // Of all the pixels that are mapped onto the texel we are
47     // currently rendering, which pixel are we currently rendering?
48-    float2 ratio_scale = xy * SourceDims - 0.5;
49+    float2 ratio_scale = xy * 2.0 * SourceDims - 0.5;
50
51 #ifdef OVERSAMPLE
52     float filter = fwidth(ratio_scale.y);
53@@ -278,7 +278,7 @@
54     float2 uv_ratio = frac(ratio_scale);
55
56     // Snap to the center of the underlying texel.
57-    xy = (floor(ratio_scale) + 0.5) / SourceDims;
58+    xy = (floor(ratio_scale) + 0.5) / (2.0 * SourceDims);
59
60     // Calculate Lanczos scaling coefficients describing the effect

61     // of various neighbour texels in a scanline on the current
62@@ -297,20 +297,21 @@
63     // Calculate the effective colour of the current and next
64     // scanlines at the horizontal location of the current pixel,
65     // using the Lanczos coefficients above.
66+    float2 one = TexelSize / 2.0;
67
68     float4 col  = clamp(
69                     mul(coeffs, float4x4(
70-                           TEX2D(xy + float2(-TexelSize.r, 0.0)),
71+                           TEX2D(xy + float2(-one.r, 0.0)),
72                            TEX2D(xy),
73-                           TEX2D(xy + float2(TexelSize.x, 0.0)),
74-                           TEX2D(xy + float2(2.0 * TexelSize.x, 0.0))
75+                           TEX2D(xy + float2(one.x, 0.0)),
76+                           TEX2D(xy + float2(2.0 * one.x, 0.0))
77                     )), 0.0, 1.0);
78     float4 col2 = clamp(
79                     mul(coeffs, float4x4(
80-                           TEX2D(xy + float2(-TexelSize.x, TexelSize.y)),
81-                           TEX2D(xy + float2(0.0, TexelSize.y)),
82-                           TEX2D(xy + TexelSize),
83-                           TEX2D(xy + float2(2.0 * TexelSize.x, TexelSize.y))
84+                           TEX2D(xy + float2(-one.x, one.y)),
85+                           TEX2D(xy + float2(0.0, one.y)),
86+                           TEX2D(xy + one),
87+                           TEX2D(xy + float2(2.0 * one.x, one.y))
88                     )), 0.0, 1.0);
89
90 #ifndef LINEAR_PROCESSING

Hmm, I tried it with that version of DOSBox and it didn't work. Also tried it with the latest ykhwong build, and nothing there either.

Admittedly, I'm pretty new to these versions of DOSBox (I've mostly used the stable build up until now), so maybe I'm doing something wrong. It couldn't be a compilation error, could it? I'm using an AMD card if it helps. I've heard sometimes AMD cards have problems with shaders.

What didn't work? The console prints any shader compilation errors if they happen.

I develop on an AMD card 😀

I tried that build in the glide thread, but couldn't get it to output direct3d at all (console just keeps reporting "Using SDL_HWSURFACE"). Tried the usual sdl videodriver and dll swapping tricks... maybe specific dll versions are needed?

gulikoza wrote:

What didn't work? The console prints any shader compilation errors if they happen.

I develop on an AMD card 😀

Turns out it wasn't reading the shader. Adding a .D3D.fx on the filename fixed that.

However, the resulting image has no scanlines, only the dot mask pattern. This usually happens when you just double the texture size without adding the outscale x and y attributes as in the original RetroArch/bsnes shader I posted. Does it work on your end at 1280x800?

Apparently not 😀. But it works at 1920x1200...

Ok, maybe you can help me out here. There is no outscale parameter in D3D shaders as any scaling is controlled from dosbox.conf. If you set scaler=none, windowresolution=1280x800 it should render the original 320x200 into 1064x800 (having aspect=true) buffer. That's like having outscale=3.325x4 set if I understand the parameter correctly. It has enough vertical pixels to work with, so why are there no scanlines? 😀

It's weird, because if you raise the resolution vertically by like, one pixel, you DO see scanlines, but on certain spots in the picture they get fainter and fainter until they disappear, after which they appear again. Obviously a side effect of non-integer scaling.

I suspect the lack of scanlines is due to how the shader is written, as the original bsnes/RetroArch version is written with support for games with hi-res interlaced modes in mind. Obviously this version doesn't support interlacing, so in such games instead of drawing every other scanline per frame, it would just produce a whole, scanline-less picture. As far as I can tell from how you modified the shader, all you did (and the normal2x scaler does this as well) is basically make the shader think the game has twice the resolution it actually does, so it goes into hi-res mode essentially.

I am admittedly still very much learning about shader stuff, so what the outscale attribute in the XML spec actually does is a bit beyond me, but it appears to apply the scaling to the shader itself rather than the image. You'll notice if you set the image resolution to, say, 640x400, the lines will look exactly like on the pic I posted. The modification I made appears to take that effect, and apply it to an image twice that resolution. I don't really understand how or why, but it looks that way to me.

Basically, I'm guessing getting a proper line-doubling effect without relying on the outscale attributes probably requires changing the shader code itself in some areas, as the lines appear as a result of the code, rather than being generated by the code, if that makes sense. However, I have no clue how this would be done.

GPDP wrote:

I suspect the lack of scanlines is due to how the shader is written, as the original bsnes/RetroArch version is written with support for games with hi-res interlaced modes in mind. Obviously this version doesn't support interlacing, so in such games instead of drawing every other scanline per frame, it would just produce a whole, scanline-less picture.

Actually the original CRT shader from which all these versions were made from did not have any interlace support. It was only added in the later iteration and I would assume it alternates the lines in which scanlines appear. From my perspective, this isn't useful for DOS emulation as interlace modes were very rare. So, the goal is to have (static) scanlines, similar to how CRT monitors showed the image. (BTW: you've turned interlace support off as well by setting ilfac = vec2(1.0,1.0))

GPDP wrote:

As far as I can tell from how you modified the shader, all you did (and the normal2x scaler does this as well) is basically make the shader think the game has twice the resolution it actually does, so it goes into hi-res mode essentially.

Yes exactly and this is what I thought you wanted to achieve with your version. I compared your shader to the original shader I started porting the D3D version from and basically applied the same changes to the D3D version (except for ouscale which seems to be controlling the shader and is not part of the code). The pixels are not doubled (as are with normal2x) so yes, I was hoping this would produce the desired effect 😀