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

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

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.

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!

James-F wrote on 2020-02-10, 05:17:

DOSBox should really get on with the times.

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

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"

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.

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

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.

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?

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!

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.

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

Actually about 30. Revised list of Voodoo games for DOS.

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!

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.

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

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.

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.

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.

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.