Quoting myself, of course only if you're capable of doing it:

Open a command box, change to the directory where the d3d-enabled dosbox resides, type DIR and post the output. Then type "cd […]
Show full quote

Open a command box, change to the directory where the d3d-enabled
dosbox resides, type DIR and post the output.
Then type "cd shaders" and type DIR again, add that output here, too.
Then change back to the previous directory and type "dosbox" or whatever
the executable is named, and tell if it's working or not.

This time you are missing Scaling.inc file.

Thanks Guli!.😀

Hey guys Could you tell me how to get Pixel shader work properly ! , i always get D3D:Using Triple buffering (in consol )

anyone ?

Anyone what? Have you read the instructions on my page; do you get any actual errors?

no problem i figured it out it's only work with fullscreen 😀

Inspired by this thread, I did a quick port of the BSNES' CRT.OpenGL.shader. It compiles but it's horribly broken. Anyone spot any obvious mistakes? Disable CURVATURE for startes, it makes it even worse 😜

One problem is that I forgot matrices are transposed in OpenGL and D3D. Switching mul() arguments on lines 201 and 208 (coeff and float4x4) makes it look almost good. dotMaskWeights is not computed correctly, without it the picture is much better 😀

Alright...a good night's sleep seems to make it all better 😀. The attached shader, except for the distortion, seems visually ok. Anyone can compare it to the original?

I fixed the barrel distortion and also made some corrections to the dotMaskWeights calculation so that the effect is uniform (it was wrong in the previous version, I compared it to the Ultima screenshot from the GLSL shader). The output now seems very close to the one GLSL screenshot I have. The only thing that bothers me a bit is that black border around prince (see the legs, where does that come from?).
The other issue is of course the garbage on right and bottom side. I will fix that in the patch (initialize entire texture to black).

The CRT surface curvature distortion seems nice in static shots, but in motion it creates distracting artifacts in certain cases. I think this is because the scanlines bend but the underlying pixels do not. It's most noticeable when the entire screen scrolls, and there are regular pixel patterns like a checkerboard. The resulting moiré patterns are interesting in their own right, but not realistic.

gulikoza wrote:

The only thing that bothers me a bit is that black border around prince (see the legs, where does that come from?).

The Ultima V screenshot at the other thread has a similar glitch (Look carefully at the top of the "V"). The light blues next to the pure white are dark. This might be intentional if the same thing happens on a real CRT, but I find that improbable.

There's another glitch in the Ultima screenshot: look at the flames beneath the "o" in "warriors". Now that definitely is unintentional.

The distortion patterns I mentioned are not visible in fullscreen, so it seems this shader/effect needs a lot of pixels to work with or the patterns emerge.

I'd guess so...dosbox startup screen looks very bad without scaling, but seems fine once enlarged to 1920x1200. It makes sense you'd need at least 4 or 5 rows to properly show one scanline. Also, while 320x200 material seems almost perfect on 1920x1200 fullscreen, the effects are much less visible with 640x400 games, although these two modes looked similar (if not the same, comparing scanlines) on my 19" CRT.

For me, the OpenGL.CRT shaders looks better the higher the window resolution is.

It may be worth mentioning that the OpenGL.CRT in bsnes does not suffer from the issue of artifacts/garbage on the right and bottom. This seemed to me too to indicate that some buffer needed to be cleared, but after replacing all the mallocs with callocs I wasn't able to get rid of them.

Let me know if you find a fix for this!

It's already fixed (in the D3D patch) 😎

The problem is that entire texture has to be cleared as the shader will sample texels outside the viewable area. For OpenGL, there should be a glTexImage2D() call overwriting entire texture with black after each resize.

gulikoza - amazing job! CRT.D3D.fx looks great 😁

Just tested this shader on two different setups (rendering at 1280x1024 on both):

1. NVIDIA GeForce GT 240 (on a Core2Quad 2.84GHz w/XP Pro SP3) -
   Fast and smooth... works just fine
2. NVIDIA GeForce 7300 SE (on a Core2Duo 2.66GHz w/XP Pro SP3) -
   
   Major problems with this one - rendering is slow and choppy, and my entire system actually slows to a crawl... any game is practically unplayable. Even text screens are drawn as if they're coming from a BBS through a 2400 bps modem 😵
   don't know how to monitor GPU load with this card, but GPU temperature does increase by a few degrees. (As expected, seems to have nothing to do with CPU load, which stays very low).

any ideas about this? Or is this all I can expect from such an old card?

Sure, I can use it just fine on PC #1 with the GT 240... but #2 is my main work PC, and I need my DOSBox fix during "extended breaks" 😜

I'd expect it needs some juice. It's a PS3.0 shader (wouldn't compile with PS2.0 profile).

Yeah, figured as much. I don't run anything graphically advanced on that pc so never bothered to upgrade the video card.