VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 980 of 1006, by jmarsh

User metadata
Rank Member
Rank
Member

If you want pixel perfect all you need to do is use a default fragment shader with a vertex shader that warps the vertices to integer multiples of the input size. The framebuffer is already cleared to black so no need to worry about discarding fragments etc.

Reply 981 of 1006, by James-F

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote on 2020-02-11, 15:29:

OpenGL expectedly needs to blur the shaders' pixel edges to fit the rendering surface (image attached below). So can it get even better?

It can't get any better/sharper.
The 'Sharp' filter prescales then does a bare minimum amount of interpolation to maintain accurate pixel shape.


my important / useful posts are here

Reply 982 of 1006, by Yesterplay80

User metadata
Rank Member
Rank
Member
krcroft wrote on 2020-02-11, 15:29:

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.

I think I managed to fix it myself by commenting out some definitions (for glDeleteprogram) in the voodoo patch that are now already made in the code for the shaders. But bare in mind that I don't actually know what I'm doing, the compiler moaned about that command being defined already so I merely played a hunch, so far it seems to be working. 😀 No update for linux yet, though!

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

Reply 983 of 1006, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote on 2020-02-11, 15:11:
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.

yeah well.. I wasn't complaining or anything..
I am fairly ignorant when it comes to shaders coding/standards and I can assure you that my question was just naive

let me rephrase it:

anyone had the chance to analyze which kind of shader programs are we expected to use with dosbox svn?
is there any possibility that the libretro shaders will work out of the box? (*)
are there any requirements/guidelines that should be taken into account when trying to make existing shader programs compatible with dosbox svn?

(*) I know now that this will not be the case

Reply 984 of 1006, by jmarsh

User metadata
Rank Member
Rank
Member

The format is pretty similar to the original patch: VIDEO - Basic GLSL shader support (prototype)
With the exception that both vertex and fragment shaders should be in the same source file, with the vertex source guarded with "#if defined(VERTEX)/#endif" and the fragment source guarded with "#if defined(FRAGMENT)/#endif". Common definitions/functions doesn't need to be guarded.
If output=openglnb, "#define OPENGLNB 1" will be prepended to the shader source when compiling.
If there are any environment variables named "GLSHADER_*" they will also be prepended as #defines. So for fine-tuning stuff, you could do "set GLSHADER_RADIUS=0.5" or similar at the DOSBox command prompt, then reload the shader using "glshader xxx" and the line "#define RADIUS 0.5" will be injected into the source when it gets compiled.

Reply 985 of 1006, by 7F20

User metadata
Rank Newbie
Rank
Newbie
James-F wrote on 2020-02-11, 15:37:

The 'Sharp' filter prescales then does a bare minimum amount of interpolation to maintain accurate pixel shape.

James, would you be able to tell me if this 'Sharp' setting would let me scale a 320*200 game to 1600*1200 and then back down to 320*240?

Thanks

Reply 986 of 1006, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

The filter will apply to whatever resolution you set in fullresolution= or windowresolution=,, what you do with it afterwards is not dosbox's concern.
How are you scaling back down to 320x40?


my important / useful posts are here

Reply 987 of 1006, by jmarsh

User metadata
Rank Member
Rank
Member

There is no way you can get 240 "clean" pixels from 200. When you go from 1200 -> 240 every 4 out of 5 pixels will be thrown away, leading to uneven scaling. You may as well just do nearest neighbour 320x200 -> 320x240, it will end up looking the same.

Reply 988 of 1006, by krcroft

User metadata
Rank Member
Rank
Member
James-F wrote on 2020-02-11, 15:37:
krcroft wrote on 2020-02-11, 15:29:

OpenGL expectedly needs to blur the shaders' pixel edges to fit the rendering surface (image attached below). So can it get even better?

It can't get any better/sharper.
The 'Sharp' filter prescales then does a bare minimum amount of interpolation to maintain accurate pixel shape.

Right, fully agree that we're seeing that bare minimum amount of interpolation in the screenshot, which is required to fit the pixels to KainXVIII's native screen dimensions.

The bare minimum amount just becomes zero when the rendering area is reduced to an integer multiple of the shader's output, as opposed to rendering perfectly to the edges of full-screen. So with pixel-perfect, the user can sit back and not hand-tweak their output resolution size, and let pixel-perfect shrink the output window as to ensure no interpolation occurs.

We're both right - you're talking about the full continuum of output resolutions where the bare minimum is steady adjusted to fit - and it happens to eventually hit zero at those integer resolutions, before it starts growing again.
Where as I'm talking about only the subset of those resolutions where it's always lands on an integer and thus requires no interpolation (and letting pixel-perfect generate those dimensions for us).

Reply 989 of 1006, by 7F20

User metadata
Rank Newbie
Rank
Newbie
James-F wrote on 2020-02-11, 16:56:

How are you scaling back down to 320x40?

I'm not, I was hoping there was a solution that could scale the image up and back down.

jmarsh wrote on 2020-02-11, 17:26:

When you go from 1200 -> 240 every 4 out of 5 pixels will be thrown away, leading to uneven scaling.

The thought was that uneven integer scaling could be done in x and y directions. 320x5=1600, 200*6=1200 -> 1600x1200/5=320x240. On a regular 240p RGB monitor, this would be the same aspect ratio as the original VGA image @ 320x400 (line-doubled) so it would look correct, as far as the aspect ratio is concerned. The difference would be the extra space would be filled-in with scanlines, but that's kind of the idea.

Could it be done with what is available now?

Reply 991 of 1006, by 7F20

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote on 2020-02-11, 18:42:

As I said the result would look the same as a nearest neighbour resize from 320x200->320x240 i.e. every fifth line repeated.

I see what you're saying. (facepalm)
I guess there isn't any sane way to do it. I give up.

Thanks

Reply 992 of 1006, by krcroft

User metadata
Rank Member
Rank
Member

7F20, if you have an analog CRT PC monitor, can you try driving it a higher resolution than 240p? I recall back in the day that my 386's monitor (14" bubble-style) supported 1024x768 once I got a better video card.

If you could feed it at its highest-supported resolution from the shader, then you should see more natural scaling of pixels to fit the display, instead of the more severe line-doubling-every-5th row (which I suspect would still be visible on a CRT).

Reply 993 of 1006, by 7F20

User metadata
Rank Newbie
Rank
Newbie
krcroft wrote on 2020-02-11, 19:15:

7F20, if you have an analog CRT PC monitor, can you try driving it a higher resolution than 240p?

It's a CGA monitor, so it can't really increase the vertical that high. I have pushed it up to the ~260 line range for some console emulation stuff using modelines, but it can't do 400 vertical. Horizontal it can do ~640p no problem, so I can do hi-res text modes and stuff.

My starting point for a solution was that, if I had a very high vertical resolution, the scaling artifacts would be eliminated because there would be 10x worth of resolution to average together. However, jmarsh is telling me that it doesn't work that way, and that downscaling it will just do an integer multiple downscale and I'll still end up with the ugly extra line every fifth line.

It's too bad I can't get an interpolative downscaling from a high resolution.

Thanks for the idea though.

Reply 995 of 1006, by 7F20

User metadata
Rank Newbie
Rank
Newbie
krcroft wrote on 2020-02-11, 20:37:

(ie: v-stretch knob adjustment)?

Yes, I can, but I'm working with large (20" plus) video broadcast monitors that don't have readily accessible pots for vsize. It's an hour long journey to switch it back and forth, and it would have to happen too frequently. I may just have to get separate monitors setup for separate purposes, but it's a drag to double down on space. (and cost)

Reply 996 of 1006, by AvalonH

User metadata
Rank Newbie
Rank
Newbie

What sample rate do others use for the following settings in the config file :

dosbox mixer=
mt32.rate=
fluid.samplerate=
oplrate=
gusrate=
pcrate=
tandyrate=

At the moment I have all the above set at 49716.
If I set the correct rates to stop any sample rate conversion, mt32.rate=32000 I get muffled sound. Setting the dosbox mixer to 32000khz to match the mt32 fixes it, but then games that also use the SB16 for digital audio sound muffled. I guess there isn't an optimum setting when using two sound devices without having to use sample rate conversion.

Reply 998 of 1006, by Marty2dos

User metadata
Rank Newbie
Rank
Newbie
Yesterplay80 wrote on 2017-10-29, 19:19:
Marty2dos wrote:

Do you plan add regular the OpenGL shader part to your builds? I seen a old version "DOSBox r4006 ECE (with GLSL shader)"

No, I prefer going with the pixel perfect patch and both patches together doesn't work.

How is it that there is shader support? At first everyone was against it because it is crap and now dosbox contains shader support? Now does both work?

Reply 999 of 1006, by Yesterplay80

User metadata
Rank Member
Rank
Member
Marty2dos wrote on 2020-02-13, 13:31:

How is it that there is shader support? At first everyone was against it because it is crap and now dosbox contains shader support? Now does both work?

No one was against it, but back then (over 2 years ago), the patch for the shaders and the one for pixel perfect scaling simply didn't work together, applying one of them changed the source code so much that the other didn't apply any more. Now the shader support is built in directly and the pixel perfect patch is "on hiatus" at the moment, becuase Ant_222 is trtying to adopt it for usage with dosbox-staging.

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