Recently I tried to combine two shaders (by copying over code of one shader to another and adding it as a second pass) and failed miserably. Since I don't have the time and energy to really learn this, I'd like to propose a new feature for the d3d patch that might be interesting not only for me (and shouldn't be too hard to implement for people who know what they do):

Filter chaining, or the ability to define two or more filters that are executed after each other.

Would be really nice to have.

That would be hard, since some shaders work by scaling the original image...having a few those filters chained, would require 4x, 8x scaling...

At 2560x1600 8x scaling would be just want I'd want for 320x200 games. I'm able to achieve such in the current DOSBox to a limited degree by combining scalers with shaders (i.e. Super2xSAI scaler+GS4xHqFilter shader).

Is it me, or does this cool CRT.d3d.fx introduce input latency?

because other than the input problem, this is the BEST OUTPUT MODE EVER so far. though scanlines don't bend for me

I assume you've already tried messing with the CURVATURE and distortion settings in the .fx?

haven't noticed any lagging input myself, and yeah this shader is badass. Major fan of how 640x200 modes actually get 200 scanlines (as opposed to 400 w/ some of the internal scalers...)

Since the curvature already causes areas outside of the screen to be shown, i wonder how complicated it would be to use this area for overscan/border color?

CPU & GPU specs? The shader hits GPU pretty hard and since D3D output is threaded, it can lag 1 frame behind (it syncs at the start of the next frame, so Direct3D has time from the end of the frame until the next one to actually draw the image).

@VileRancour: I guess it shouldn't be that hard. D3D uses texture border color at the top and left edges and unwritten texture space (if the texture is larger than Dosbox framebuffer) on the right and bottom. I guess you could set both of these to overscan color...

I tried messing around with the shader, putting in MCHerc.fx's alpha fade into it

I know nothing of HLSL.

http://www.youtube.com/watch?v=Xz0o4KbnNIw

in principle, would it be possible to adapt something like MAME's newfangled HLSL pixelshader for CRT simulation?

I don't know a damn thing about workin' this sort of juju, but it's got them PERSISTENT PHOSPHORS! and shadow-mask effect using .pngs! (amongst other things)

MAME HLSL fx files seem pretty simple (as in readable code) they should be mostly compatible apart from different variable names (MAME has TargetWidth/TargetHeight, dosbox has TexelSize/SourceDims) which need to be set by the application.
A different thing is how this effects are applied...does MAME support multiple effect chained in the rendering process? The current D3D patch only supports a single effect...

oh... yeah, looks like they are stored in multiple .fx files and then chained according to the hlsl configuration in the .ini. Though I haven't had the chance to actually test this thing myself yet.

I'm moving and unfortunately I won't be able to take my Iiyama 19" CRT with me. Plus it started flickering and the image can't be stretched to full width anymore. This is it I guess, sigh...
I took some time to try to improve the crt shader to get as close as effect as possible. I already knew that with default settings the scanlines are much too wide from what my 19" CRT shows. I tried modifying the shader but setting scaler=normal2x (thus increasing the source resolution from 320x200 to 640x400) makes it look almost perfect in regard to the scanline width. 640x480 and 800x600 are also pretty close (using 24" LCD with 1920x1200 fullresolution in dosbox) in Duke3D so I'm happy for now. Here are some pictures for reference 😁

I wonder if the D3D patch could add 3d model support, as in displaying the screen to a specific texture a (obj format) model could map to (kinda like mame overlays but a bit more realistic). Could go the extra mile and model that very monitor you're abandnoning too for the more 'virtual reminiscence' aspect 😀

I know the feeling of losing a dying CRT. Especially if the manufacturer is obscure enough to not being able to find a replacement on ebay 🙁

What exactly do you mean? Like drawing the case of the monitor around the image? Nah, I'm not that nostalgic 😁

But ripsaw8080 mentioned on the previous page that the pixelshader does not bend pixels only scanlines. It would be possible to do a more complex geometry of the texture (instead of a simple quad) to really bend it in the corners. But then again, my CRT was Trinitron (Diamondtron actually) so the screen curvature was not that apparent. Before this one I had a 15" Sony which was again a Trinitron...I also remember the first time I saw a Trinitron it could almost be seen as if the image was bent in the other direction (I don't see this effect anymore...either I got used to it or the LCD seems similar to that and I really got used to it). Again the CRT.fx does not perform well since it will cut off parts of the image if curvature distortion is negative...

As requested by Targaff in the OpenGL thread, a D3D port of OpenGL dot'n'bloom shader. Not really thoroughly tested, but seems fine from the look of it 😁

Not exactly sure what it's supposed to simulate, looks interesting though.. nice work!

For the next time you feel like porting a shader, how about CRT-Simple? might not look as nice for higher source resolutions, but maybe some older cards (ok, my older cards) won't choke on it so much...

gulikoza <3 That is sweet, thank you! Not sure what it is about this particular look but I find it really appealing. Here's a pic of me being crap at Worms but looking pretty while losing.

VileRancour wrote:

For the next time you feel like porting a shader, how about CRT-Simple? might not look as nice for higher source resolutions, but maybe some older cards (ok, my older cards) won't choke on it so much...

Sure 😉 The code is very similar to the CRT shader so I just compared the two...not tested much, but I haven't spotted any obvious mistakes...

Today is exactly 1 year since I finished the CRT shader 🤣

Excellent, thanks!

Curiously, I don't think I see much of a performance improvement over CRT.d3d.fx, but this needs some more testing on this end.

In yhkwong's build I notice the performance really drops if I keep switching between CRT shaders. Memory leak somewhere?

I also noticed CRT-simple doesn't darken darker colors so much as the CRT shader. Quake looks better on it 😁

Here's a screenshot of the latest CRT shader I've ported to D3D (source was CRT-geom-interlaced-curved.shader [2012/02/06], but the interlaced effects have been removed as D3D patch does not support that at the moment). This is the first run it showed something so I haven't checked it all yet. I've added some things to D3D patch (the previous CRT shader might not be entirely correct as input image dimensions were not passed to the shaders and it had to do calculations without it) so you'll have to wait until I release the update to the patch 😀

edit: the next version of the patch will also support forcing full updates from the shader, so the alpha-feedback shaders (as posted by leileilol above) will work correctly.