Daum is an abandoned fork; the last build is >3 years old and quite broken. May be better to aim for something else, if any of the more active branches support d3d.

Totally understood, but I use HyperSpin and RocketLauncher -- and Daum's build is the most compatible for my needs.

Know of anyone that could do it? Or even a more technical description of what I'm asking for would be great. I don't know the shader lingo well.

My understanding is that the shader would need to be converted to D3D, but I don't know much beyond that...

Nobody is going to touch such an ancient, buggy build as Daum. Too much work to update and debug it, even before being able to getting around to do what you want. Time to move on to a more recent build.

I understand that this build is not the latest. Could someone do me a kindness and at least post a general explanation of what the requirements would be to get the shader working with the Daum build -- this question is about a compatible shader, not the application

VileRancour wrote:

if any of the more active branches support d3d.

ECE gutted out shaders for "pixel perfect scaling" last I heard.

leileilol wrote:

VileRancour wrote:

if any of the more active branches support d3d.

ECE gutted out shaders for "pixel perfect scaling" last I heard.

That's right, r4006 was the only and last version I build with GLSL shader support. Since both patches are incompatible with each other, someone would have to develop a completely new patch containing both features, hence why I decided to go for the one that seemed to get more demand. Plus the shaders setup is a little awkward.

newoski wrote:

Hi Guys,

I would love to see Lotte's CRT shader ported to Daum's build of DOSBox. I'd be happy to throw some PayPal love behind the request, if anyone is capable/willing.

Any takers?

Did you try this one? https://www.dropbox.com/s/losqzq56msdyegt/lottes_crt.fx?dl=0

Linked from this thread: https://www.construct.net/en/forum/extending- … ersion-c-108506

David_OSU wrote:

newoski wrote:

Hi Guys,

I would love to see Lotte's CRT shader ported to Daum's build of DOSBox. I'd be happy to throw some PayPal love behind the request, if anyone is capable/willing.

Any takers?

Did you try this one? https://www.dropbox.com/s/losqzq56msdyegt/lottes_crt.fx?dl=0

Linked from this thread: https://www.construct.net/en/forum/extending- … ersion-c-108506

Thanks. Sadly this doesn't seem to work. I load in manually via the GUI and there's no visible shader applied -- which leads me to believe it's not compatible and would need to be adjusted?

I did find a .fx shader version of 5x XBR a few years ago that worked with the Daum build -- it was a shader built for an amiga emulator (can't remember which one).

The Daum build uses the D3D shader support originally developed by Gulikoza (http://www.si-gamer.net/gulikoza/dosbox.html). It supports pixel shaders up to PS3.0. If the CRT shader is doing geometry distortion, it may require vertex shader support, which isn't built into the Daum build.

Or you can wait a few decades for OpenGL shader support to be added to the official DOSbox build.

I have some experience with Daum shaders, so it was not a problem to port the Crt-Lottes. As a bonus, i managed to port the nice CRT Easymode Halation shader also...

Have fun!

Guest-r,

I found your thread on the Winuae/Dosbox shaders the other day. It made me so happy! Send me a PM with your PayPal info! You are the man

Hey, np, this one is on me. 😀
Just tell if you need a fast version of CRT-Lottes too, since i posted the feature complete original
(fast version is about 7x faster i think).

Hi, great work, thanks a lot! 😀
May I ask what the requirements of the shaders are ?
I'm using ykhwong's SVN 07-05-2011 on an Athlon 64 x2 w/ nVidia 6100 GPU and Win7 x64.
DOSBox tries to run the shader, but then Win7 notices me about a kernal driver warning for the nVidia driver.

Hi there. For CRT-Lottes (Full) the requirements are quite high, about a 400-500 Gflops card i would estimate. For "Fast" version i think should work on Intel iGpu's.
(i'm adding this one too, looks quite like the original, but without bloom)

The 6100 gpu is quite weak i fear, maybe it would run some basic shaders only full speed.

Thanks a lot! 😁

Sorry for bumping this, I've tried these shaders with a clean setup of DOSBox SVN Daum (build from 26 January 2014), and while all of them work I notice selective slowdowns with CRT-easymode-hl. Namely, whenever a fade-in effect is used for drawing the entire screen (e.g. in the demo of Warcraft when the Blizzarrd logo is shown and at the start of a mission briefing) there is notable sound stuttering, and the fading in of the screen itself is very slow (compared to no shader).

At the same time I can play first-person games like Duke Nukem 3D or Daggerfall with the CRT-easymode-hl shader with no slowdowns at all, unless you count the fade-in effect in the main menu in Daggerfall. I've tried turning on double buffering in fullscreen mode and increasing the amount of RAM/VRAM allocated to DOSBox, with no effect of note on this issue (see attached configfile). Granted my PC is not too powerful by today's standards (Intel Core i5-3230M 2.60 GHz, 6 GiB RAM, NVIDIA GeForce 710M video card) but I'd assume that if the shader were resource heavy it'd be constantly slow and not at certain odd moments? Is there any way to improve performance?

BTW, are there any newer DOSBox builds that support D3D shaders? I haven't even been able to find a download of ECE r4006 (the earliest release available in the archive is r4007; BTW, pixel perfect scaling is superb).

The big problem is with massive use of case statements all over the DOSBox source code that cannot be optimized by the compiler. Those are the biggest suck of CPU cycles that can be "somewhat easily" manually optimized.

I say "somewhat easily" because it can be done.. but takes a while to figure out how to make the jump tables / arrays as well as modify the case statements into multiple functions and get everything working properly again.

Basically, it can be made to use a whole lot less CPU cycles but is a pretty big undertaking as it turns into a very custom build with no easy way to keep up with the SVN fixes.

It makes it so every action takes the same exact number of CPU cycles for each call instead of unoptimizeable case statements having to go all through the case statement till it finds a match. Unoptimizeable case statements compile into a huge If-Else code block. Much, much, much quicker to just look up a code jump point via an array.

cyclone3d, it's been my understanding that switch-case statements are (at the compiler's discretion) compiled to an O(1) function-lookup array or jump table.

The language specification deliberately constrains the case values to hard-coded integers so the jump table can be generated at compile time; where as if/else criteria are permitted to be evaluated during runtime and can evaluate ranges of values, making jump-tables ineffective except for trivial cases.

I have seen cases where the compiler doesn't generate a table though (maybe tiny enough to fit in some cache space or something), so usually you need sufficient number of cases before the optimizer deems it worthwhile.

Not arguing; that's just my understanding (and dated too.. I haven't professionally done much in the optimization space post-2010 or so) and always curious if things have changed.

Edit.. and to not derail OP; I've seen the same CPU spike during Wolfenstein 3D intro fade-in on the Raspberry Pi using pixel-perfect, because it's implemented software-side and can't keep up. Sure would love to use it on the Pi though; I love my pixels crispy.

Nothing to do with switch-case statements. Fade-in/outs are nearly always implemented using palette changes which have significant emulation cost (regardless of the output mode).