VOGONS

Common searches


DosBox-0.74-ES (SDL2)

Topic actions

First post, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

Greetings fellow DosBox fans!

I would like to announce that I have created a new branch of DosBox 0.74!

My branch offers these features:

> All rendering/scaling handled by OpenGL-ES shaders
> OpenGL-ES support works on Arm chips on Linux

  1. - Works 100% on my ODroid U3 running this Ubuntu:
    http://odroid.in/ubuntu_14.04lts/ubuntu-14.04 … 20150224.img.xz
    - Other Arm should work if an OpenGL-ES capable desktop is present!

> Supports 2-pass rendering; 2nd pass has bilinear interpolation enabled

  1. - Comes included with optimized bicubic filtering 2-pass shader
    - Comes included with single-pass "CRT" shader
    - ODroid is only fast enough to run the simplest of shaders though!
    - You can always change the shaders to do whatever you might want

> Fallback to regular OpenGL on x86 desktops (thanks to SDL). GLES shader files work for both!
> Fully ported to SDL 2.0.4
> On Linux, MUNT library (libmt32emu) support is integrated for MT32 emulation

  • - You will still need the MT32 control ROMs

> On Linux, FluidSynth support is integrated for General MIDI (GM) emulation

  • - A small sound font is included, but you can use others

> (On Windows, you can use regular midi out plus either
MUNT for MT32 or CoolSoft's Virtual Midi Synth for GM,
so you don't need it built-in. Technically you still could.)
> Physical CD-ROM support is lost (dropped by SDL)
> Built-in screen-capture support is lost (there are work-arounds now-a-days)

You can browse the source code here:

https://github.com/aqualung99/dosbox-0.74-ES

or clone with:

https://github.com/aqualung99/dosbox-0.74-ES.git


See the file 'Install-0.75GLES.txt' for instructions on installing the
prerequisites and other optional components.

I've left the default CPU cycles to be "Auto" but I highly, highly recommend setting
a fixed number of cycles, on *all* platforms. The "Auto" code no longer seems reliable.

This version is known working on the following platforms:

> ODroid U3 running Ubuntu 14.04.2
> AMD x86 running Arch
> i7 x86 running Arch
> i7 x86 running Fedora
> i7 x86 running Windows
- If you build under Windows using DevStudio, make sure you include the "/Oy-"
compiler flag to disable the "Omit frame pointers" optimization.
I've noticed that particular optimization causes the Microsoft compiler to
generate bad DosBox timing code.

Thank you and thanks to the DosBox team!


-aqualung99

Update!

I have ported Timothy Lottes' CRT shader to the DosBox-ES format! The new shader is called "DosBoxMain_Lottes2.ps" and is now installed as part of the normal build. See pictures below!

Please note this new shader is complex and even my Jetson K1 (ARM) has a hard time running it quickly. But PCs run it great (remember, my version supports both ARM OpenGL-ES and x86 OpenGL! And a single shader for all!)

AuIoQCw.png
qdWnUuY.png
O4JTEnC.png
WmQbiqV.png
btoSnrj.png

Last edited by aqualung99 on 2017-04-15, 22:42. Edited 1 time in total.

Reply 1 of 41, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 2 of 41, by Wengier

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

Reply 3 of 41, by mr_bigmouth_502

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

Reply 6 of 41, by aqualung99

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

Reply 8 of 41, by aqualung99

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

Reply 10 of 41, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 11 of 41, by aqualung99

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

Reply 12 of 41, by Great Dragon

User metadata
Rank Newbie
Rank
Newbie

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

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

Reply 13 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

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

Reply 14 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

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

Reply 15 of 41, by Great Dragon

User metadata
Rank Newbie
Rank
Newbie

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
7aaee1598945313.jpg bd645f598945223.jpg

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 ?

Last edited by Great Dragon on 2017-09-14, 22:15. Edited 2 times in total.

Reply 16 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 17 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 18 of 41, by Yesterplay80

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

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

Reply 19 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

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.