VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 961 of 1178, by realnc

User metadata
Rank Member
Rank
Member
FulValBot wrote on 2020-02-09, 13:42:

You would like to emulate CRT screens, but it's (and will be) not possible...

No. He's talking about "sharp bilinear":

https://github.com/rsn8887/Sharp-Bilinear-Shaders

Reply 962 of 1178, by James-F

User metadata
Rank Oldbie
Rank
Oldbie
realnc wrote on 2020-02-10, 02:29:

He's talking about "sharp bilinear":
https://github.com/rsn8887/Sharp-Bilinear-Shaders

Yep.
This is exactly what a "big integer prescale then interpolation" does, and exactly what I am asking for.

"sharp-bilinear-simple"
This shader does an automatic optimum integer prescale (2x, 3x, 4x etc.), depending on game and screen resolution.

Low resolution pixel art (DOS games, consoles, etc.) deserves better than a simple blurry bilinear upscale.
DOSBox should really get on with the times.


my important / useful posts are here

Reply 963 of 1178, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

So, while I still didn't find the time to read into GIT, at least I found some time to get a new build of DOSBox ECE compiled, based on the latest revision from SurceForge (r4318). I managed to get opusfile compiled under MinGW (installing the base packages for pkg-config and libpwinthread for MSYS2 did the trick), so it now also uses revision 14 of krcrofts patch for more CD audio replacement file types.

Since Qbix is till experimenting with the scaling in DOSBox. I won't even bother trying to get the 5x/6x scaler patch wortking atm. And Ant_222s pixel perfect scaling patch is still "broken", so those two features are mssing right now, all others should be present and working, though. So far only a Windows build is available, I'll try to get one for Linux ready asap, maybe even today.

UPDATE: Linux version is uploaded, too!

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 965 of 1178, by collector

User metadata
Rank l33t
Rank
l33t

The Munt emulation in ECE is not working for me anymore. It sounds like it cannot find the ROMs, even though they are present in the specified romdir and the ROMs work with earlier versions. I also noticed that if the ROMs are not present in the specified location it no longer tells you "MT32: Control ROM file not found"

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

Reply 966 of 1178, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
collector wrote on 2020-02-10, 19:55:

The Munt emulation in ECE is not working for me anymore. It sounds like it cannot find the ROMs, even though they are present in the specified romdir and the ROMs work with earlier versions. I also noticed that if the ROMs are not present in the specified location it no longer tells you "MT32: Control ROM file not found"

Which OS are you on? It works for me here under Windows, if I change the rom path it also shows it can't find them.

MT32.JPG
Filename
MT32.JPG
File size
125.11 KiB
Views
743 views
File license
Fair use/fair dealing exception
jmarsh wrote on 2020-02-10, 19:40:

Try glshader=sharp (SVN r4319). Make sure scaler is set to none.

And there goes the Voodoo patch, gone with r4319...

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 967 of 1178, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote on 2020-02-10, 20:06:

And there goes the Voodoo patch, gone with r4319...

TBH I find this to be a pretty inappropriate response.
People have been complaining (loudly) that they want larger scalers, pixel-perfect resizing, this-or-that fancy resizing algorithm implemented... this takes care of all of those issues (or at least opens the door for them to be solved without code modification), and instead you're bitching because it breaks an out-of-tree patch.

Reply 968 of 1178, by 7F20

User metadata
Rank Member
Rank
Member
James-F wrote on 2020-02-10, 05:17:
Yep. This is exactly what a "big integer prescale then interpolation" does, and exactly what I am asking for. […]
Show full quote

Yep.
This is exactly what a "big integer prescale then interpolation" does, and exactly what I am asking for.

Low resolution pixel art (DOS games, consoles, etc.) deserves better than a simple blurry bilinear upscale.
DOSBox should really get on with the times.

This is exactly what I've been looking for from dosbox. My general goal is to get dos era games (mostly shmups and early fps) running at 240p. I'm trying to get 320x200 upscaled to 1600x1200 and then downscaled to 320x240. That will give me integer scaling in both directions and it will end up with a PAR equivalent image at the same 4:3 ratio.

Is this already possible?

Reply 969 of 1178, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2020-02-10, 20:36:
Yesterplay80 wrote on 2020-02-10, 20:06:

And there goes the Voodoo patch, gone with r4319...

TBH I find this to be a pretty inappropriate response.
People have been complaining (loudly) that they want larger scalers, pixel-perfect resizing, this-or-that fancy resizing algorithm implemented... this takes care of all of those issues (or at least opens the door for them to be solved without code modification), and instead you're bitching because it breaks an out-of-tree patch.

I merely stated that the latest update broke compatibility with that patch. Sorry I did!

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 970 of 1178, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

SVN [4319] OpenGL shader support.

OMG YES!!!!!!!!
glshader = sharp

Can I say finally?
Finally!!

edit:
Voodoo is the least useful patch.
Like 1 or 2 DOS games supported voodoo?
It will not be missed.


my important / useful posts are here

Reply 971 of 1178, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote on 2020-02-11, 11:30:

Voodoo is the least useful patch.
Like 1 or 2 DOS games supported voodoo?
It will not be missed.

If you say so...

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 973 of 1178, by KainXVIII

User metadata
Rank Member
Rank
Member

So i tried sharp shader and it looks..pretty bad? And since pixel perfect patch is no longer supported - 😫
Scratch that - i was using openglnb instead of opengl output!

eric.png
Filename
eric.png
File size
212.75 KiB
Views
624 views
File license
Public domain
ericsharp.png
Filename
ericsharp.png
File size
544.8 KiB
Views
623 views
File license
Public domain

Reply 974 of 1178, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Yes, it is glorious.
The higher you native resolution of your display, the sharper the image will look.
When the upscaling factor is big (say from 320x200 to 1080p) the sharper the image will look with less and less blur, and accurate pixel geometry.
There is no modern emulator with low resolution like SNES, Genesis, NES etc.. that does not have this filter.


my important / useful posts are here

Reply 975 of 1178, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

anyone tried using one of the libretro shaders?
https://github.com/libretro/glsl-shaders

I've tried both CRT-EasyMode and CRT-Lottes-Fast and all I get is a black frame

the console does not output any error/warning regarding being unable to load/compile the .glsl file

I'm on Windows 10 laptop, using the Intel HD610 integrated gpu that should support Shader Model 5.1
The built-in shaders are working fine.

PS: voodoo emulation seems to work fine as well, as per ECE r4319

Reply 976 of 1178, by collector

User metadata
Rank l33t
Rank
l33t

OK, the problem is that I was not changing mididevice from default. Other Munt builds and I could have sworn earlier ECE builds did not need this.

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

Reply 977 of 1178, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
Delfino Furioso wrote on 2020-02-11, 14:42:

anyone tried using one of the libretro shaders?
https://github.com/libretro/glsl-shaders

You can't just take shader sources from any random project and expect them to work without any modifications.

Reply 978 of 1178, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
collector wrote on 2020-02-11, 14:55:

OK, the problem is that I was not changing mididevice from default. Other Munt builds and I could have sworn earlier ECE builds did not need this.

Yes, the first few ECE builds including MT32emu had it set as default, you're right. But I already changed that quite some time ago, because MT32 isn't supported by all games and I thought it better to have a midi device as default that works with every game.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 979 of 1178, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

It's a huge improvement - finally no pixel size inconsistencies. Thank you for jmarsh and ny00123!

OpenGL expectedly needs to blur the shaders' pixel edges to fit the rendering surface (image attached below). So can it get even better? Pixel-Perfect Shaders, assuming an even-integer multiple (either up or down) can be found between the shaders' output and the rendering surface. Indeed, ant-222 is busy working on Pixel-Perfect once again.

For native DOS output, PP doesn't need shaders; so it's the visual re-interpretations offered by shaders where PP can help eliminate pixel blur by adjusting the rendering size.

Yesterplay80, I also share your sentiment regarding the voodoo patch: an unfortunate but unavoidable consequence of unaccepted patches that touch the same area changed by upstream. Hopefully that patch author can refurbish it again or someone else can take up work.

With 4k displays, I can easily see all three coming into play: Voodoo emulation @480p ==> GSL shaders (say, applying a Sony Trinitron RGB color adjustment and curvature) @960p ==> Pixel Perfect rendering size adjustment to 2160x1920 on 1440p and 4k displays.

Attachments

  • 2020-02-11_07-46.png
    Filename
    2020-02-11_07-46.png
    File size
    2.63 KiB
    Views
    556 views
    File license
    Fair use/fair dealing exception
Last edited by krcroft on 2020-02-11, 15:47. Edited 5 times in total.