Moving to patches forum for now. Maybe we need a fork forum 😉

Looking good, will have to try on OS X one day 😉

Dominus wrote:

Moving to patches forum for now. Maybe we need a fork forum 😉

Looking good, will have to try on OS X one day 😉

I support a fork forum, but, I am wondering if it should include all programs that were derived from DOSBox, such as vDos and vDos-lfn as well?

Wengier wrote:

Dominus wrote:

Moving to patches forum for now. Maybe we need a fork forum 😉

Looking good, will have to try on OS X one day 😉

I support a fork forum, but, I am wondering if it should include all programs that were derived from DOSBox, such as vDos and vDos-lfn as well?

I support this idea as well. BUT there should be a disclaimer stating that these forks aren't officially supported by the DOSBox team. 😉

Any chance to see a compilation build of this fork?

Did you do anything for the mt32 support beyond just integrating munt's official dosbox patch? If so, I just might have to borrow your work on that for My Dosbox Fork.

dugan wrote:

Did you do anything for the mt32 support beyond just integrating munt's official dosbox patch? If so, I just might have to borrow your work on that for My Dosbox Fork.

No, IIRC I integrated the example DosBox patch from Munt. Nothing too fancy, most of the work was on the video side.

Just dropping a note that I've updated my original post. I haven't made any code changes however I have added a new CRT shader -- screenshots are above!

Great Dragon wrote:

Any chance to see a compilation build of this fork?

I don't know what a compilation build is, but I've posted a Windows binary for Windows folks who may not be able to build this themselves. I don't have a real hosting site, so I had to keep the file size small. That means, I had to skip the soundfonts (you can google for them though!)

Windows binary posted here:

https://github.com/aqualung99/dosbox-0.74-ES/ … dows_041617.zip

Just extract to some folder like C:\DosBox and go. On first run, it will create your "DosBox-0.74-ES.conf" file in your "C:\Users\[You]\AppData\Local\DosBox" folder, so just run once to create that file, then you can go edit it to change the shader.
Again, the Windows build does not include FluidSynth nor Munt built-in. It expects those components to be external midi configs, selected in the .conf file.

is it possible to make this work from running without a desktop? like from CLI? i see a huge slowdown in emulation on my raspberry pi 3 after compiling from the steps in the readme.

Does this branch accept new shaders as plugins, and if so, is there an instruction on how to add a custom shader?

EDIT: I should like to implement my pixel-perfect patch as a shader for your branch of DOXBox, but I shall need such variables as the output resolution and the aspect ratio as calculated by DOSBox (render.src.ratio). Can you pass them to the shader? If I manage to write this shader, we can move all pre-calclulation to .cpp code in order not to repeat it for each fragment/pixel.

Ant_222 wrote:

Does this branch accept new shaders as plugins, and if so, is there an instruction on how to add a custom shader?

EDIT: I should like to implement my pixel-perfect patch as a shader for your branch of DOXBox, but I shall need such variables as the output resolution and the aspect ratio as calculated by DOSBox (render.src.ratio). Can you pass them to the shader? If I manage to write this shader, we can move all pre-calclulation to .cpp code in order not to repeat it for each fragment/pixel.

Yes; there are no instructions though, beyond whatever comments I have added to the code. The shaders are written in OpenGL-ES, and function on PC and ARM alike. There are a few extra restrictions for OpenGL-ES shaders but nothing too bad. I was still able to implement the Lotte2 shader, for instance. If you are interested in making a shader, I can give you a few more details about the Textures and UV coordinates that would probably be helpful (maybe more helpful than just trying to decipher the existing shaders.)

The shaders are setup so you assign different shader files for different purposes. Pixel shaders and vertex shaders are each handled separately. The primary shaders for the program are in the [sdl] section of the config file called "vertex_shader", "pixel_shader", and "pixel_shader_no_palette". The vertex shader is always used (it does very little), the "pixel_shader" shader is used for all paletted video modes; the "pixel_shader_no_palette" is used for video modes that don't use a palette.

In addition, we support 2-pass rendering, for additional affects like bicubic interpolation. When using two-pass rendering, the results of the first pass are fed back into the shader for the 2nd pass. The shaders used for the second pass are called "vertex_shader_pass2" and "pixel_shader_pass2". Usually when I used 2-pass shaders I use the "fb_bicubic" ones for the 2nd pass.

As for your "pixel perfect" patch, there is no need. I have already recently implemented that in my code. I've posted a new Window binary containing this change. To use it, you will need to edit your "DosBox-0.74-ES.conf" file.
I have added a new option to the [sdl] section of the config called "make_square_pixels". This only works properly in Windowed mode, unfortunately. It does not work in fullscreen.
In Windowed mode, if you set "make_square_pixels=true" then the window will always be a 4x3 aspect ratio. If you set "make_square_pixels=false" then the pixel layout from the DOS program is used as-is. You can then use perfect multiples of your target resolution to get pixel-perfect doubling, tripling, etc. For example, if your target program runs at 320x200, and you set your window resolution to 640x400 and set make_square_pixels=false, then you will get perfect doubled pixels with no correction.

@aqualung99

Thanks for the Windows build. I've just downloaded a recent one from github repo.

Can you give some settings advice please? As I can't make shaders look nice. Not even close to what you posted in this thread.

It looks like resolution of the shared (Lottes2 in this case) is very low. How can I scale it? My settings for "windowresolution" are 1280x960. And I don't see any scale options in dosbox config. Like Daum's build has for instance.

Might you possibly have 2-pass enabled? You normally don't want to mix the two. If not, it might be a bug...what kind of video card do you have?
I usually run with the Lottes2 and here is what my [sdl] section looks like:

fullscreen=false
fullresolution=1920x1080
windowresolution=1333x1000
output=opengles
autolock=true
sensitivity=200
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74-ES.map
vertex_shader=.\Shaders\DosBoxMain.vs
pixel_shader=.\Shaders\DosBoxMain_Lottes2.ps
pixel_shader_no_palette=.\Shaders\DosBoxNoPal.ps
vertex_shader_pass2=.\Shaders\fb_bicubic.vs
pixel_shader_pass2=.\Shaders\fb_bicubic.ps
perform_2pass=false
make_square_pixels=true
use_16bit_textures=false

show_perf_counters=false

And for the sake of completeness, if you didn't like the Lottes2 but just wanted regular bicubic filtering, you would make sure these lines were set like so:

pixel_shader=.\Shaders\DosBoxMain.ps
vertex_shader_pass2=.\Shaders\fb_bicubic.vs
pixel_shader_pass2=.\Shaders\fb_bicubic.ps
perform_2pass=true

Thanks. Removing 2nd pass helped.

I love Lottes shader in general and your implementation of it Lottes2. It has lack of glow effect and you can't choose shadowmask type. Like you can do it in its RetroArch implementation. But still it's better to have it on compare to raw pixel view. Your regular lottes shader isn't usable much to me as it has some ugly ping hue.
CRT shader looks ok but I prefer Daum's version. It looks to me exactly how it was back in the days.

Lottes2 VS Daum D3D CRT

Anyway thanks for your hard work with shaders implementation. I think it's as important as an emulator accuracy. But unfortunately DosBox community doesn't pay much attention to it ((

Any chance to see some improvements in your build? Like using latest SVN build from official repo, community patches like OPL3 fix etc, and more shaders ?

Thank you! Yes, I still have a lot of passion for this project. Unfortunately work gets busy sometimes and I don't have as much time to spend on it.
Once I have the time though, the improved OPL3 is high on my list. Probably 2nd is porting over the 3Dfx/Glide work that has been done in the community, and hopefully even improving on it.
I don't know much about the history of the DosBox code since the big shutdown at 0.74. But I know the 0.74 code pretty well and would need a pretty good reason to start over again.

Also, you are getting some precision errors in your output. That's the cause of the occasional missing/extra vertical row of pixels. I see this on the ARM GPUs all the time because they use very low-precision floats (8-bit I believe.)

You can very likely correct this problem (depending on your video card) by going into the lottes2.ps file and changing the word "mediump" to "highp". While you're at it, change "lowp" to "highp" too couldn't hurt. Your card will either ignore you (because it cannot comply) or else it will comply at the cost of some framerate.

Great Dragon wrote:

Anyway thanks for your hard work with shaders implementation. I think it's as important as an emulator accuracy. But unfortunately DosBox community doesn't pay much attention to it ((

That takes patience. I've been releasing my build regularly for about a year now and it's just recently that it got some more attention thanks to it being listed at emucr.com and ppxclub.com. Also, according to the statistics on my blog, my DOSBox ECE site gets a lot more visits daily than I'd have thought, obviously not every one using a build/fork is talking about it.

So plaese, aqualung99, don't let a lack of response disencourage you, I'm pretty sure your build has a lot of fans, because many people love the possibility to have their games looking like they did on their old CRTs!

aqualung99 wrote:

Probably 2nd is porting over the 3Dfx/Glide work that has been done in the community, and hopefully even improving on it.

That would be great! even greater would be if you'd release your improvements as a new diff against the current SVN afterwards! Any chance you could do that with your shader support?

Thank you for the kind words. I appreciate the support!

Perhaps I should take a look at the extent of the differences between my branch and the current SVN as a next task. Because I don't really know how large or small a job that may be. Although if the current SVN is still linking to SDL 1.0 it's not really an option either way.