VOGONS

Common searches


First post, by newoski

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 1 of 31, by VileR

User metadata
Rank Oldbie
Rank
Oldbie

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.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 2 of 31, by newoski

User metadata
Rank Newbie
Rank
Newbie

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...

Reply 3 of 31, by collector

User metadata
Rank l33t
Rank
l33t

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.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 4 of 31, by newoski

User metadata
Rank Newbie
Rank
Newbie

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

Reply 6 of 31, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 7 of 31, by David_OSU

User metadata
Rank Newbie
Rank
Newbie
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

Reply 8 of 31, by newoski

User metadata
Rank Newbie
Rank
Newbie
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?

Reply 9 of 31, by David_OSU

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 10 of 31, by guest.r

User metadata
Rank Newbie
Rank
Newbie

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!

Attachments

  • Filename
    CRT-easymode-hl.zip
    File size
    3.92 KiB
    Downloads
    233 downloads
    File comment
    CRT Easymode Halation shader
    File license
    Fair use/fair dealing exception
  • Filename
    CRT-Lottes.zip
    File size
    2.66 KiB
    Downloads
    229 downloads
    File comment
    CRT Lottes Full shader
    File license
    Fair use/fair dealing exception

Reply 13 of 31, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 14 of 31, by guest.r

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

  • Filename
    CRT-Lottes-Fast.zip
    File size
    2.3 KiB
    Downloads
    174 downloads
    File license
    Fair use/fair dealing exception

Reply 15 of 31, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Thanks a lot! 😁

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 16 of 31, by MrFlibble

User metadata
Rank Oldbie
Rank
Oldbie

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).

Attachments

  • Filename
    dosbox.conf
    File size
    30.92 KiB
    Downloads
    40 downloads
    File license
    Fair use/fair dealing exception

DOS Games Archive | Free open source games | RGB Classic Games

Reply 17 of 31, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

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.

Yamaha YMF modified setupds and drivers
Yamaha XG resource repository - updated November 27, 2018
Yamaha YMF7x4 Guide
AW744L II - YMF744 - AOpen Cobra Sound Card - Install SB-Link Header

Reply 18 of 31, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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.