Mixer behavior depends on sbtype= and/or sbmixer= settings.

More detail here.

ripsaw8080 wrote on 2020-06-29, 21:45:

Mixer behavior depends on sbtype= and/or sbmixer= settings.

More detail here.

Then why does it not do it on regular DOSBox .74 or my SVM build I also use from time to time?

I can only guess that it's due to different settings, e.g. you use sbtype=sb1/sb2 or sbmixer=false in those cases where Dune 2 is not affecting your mixer settings. Perhaps there is some confusion as to which .conf file is being used. You can check the current settings by typing "sbtype" and "sbmixer" at the prompt.

At my place, with default settings (meaning sbtype=sb16 and sbmixer=true) in official 0.74(-3) and SVN, Dune 2 (US floppy version 1.07) is changing the mixer settings. As you can see in the linked thread, the user there was encountering the described behavior.

MT_ wrote on 2020-03-06, 12:09:

Yesterplay80 wrote on 2020-02-21, 15:42:

Srandista wrote on 2020-02-21, 15:05:

What was the last version with Pixel perfect scaling? r4301?

Yup.

Hi, Yesterplay80. Given that for many users like me,is the most/only interesting feature of DOSBox ECE compared with the regular official DOSBox, it would probably make sense to add a direct link to the latest build of DOSBox ECE that had pixel-perfect scaling, to the page of DOSBox ECE (dosboxece.yesterplay.net/en/ ). Thanks.

ECE no longer has pixel-perfect scaling!?

I am using dosbox ece to run grand prix 2. I have a steering wheel and pedals for this game, and for a few years now I have been using it with the "timed = false" option because with cycles "auto" it makes the game play at the correct speed but the steering wheel drifts and acts up. If I reduce the number of cycles from "cycles auto" to say, "cycles 10000" the game runs EXTREMELY slow but the steering wheel does not get super Jittery and drifty.

Is there something I can do to make TIMED = true work? I get an awesome HUGE resolution with my steering wheel when I have it set to timed=true, compared to timed=false.

I've tried different settings with the cycles. 80000, 50000, and 30000. All three of these were too jittery with the timed = true setting.

EDIT: I THINK I FIXED IT.

I was using an older version of ECE (4205) I downloaded the new one (4356) and it does not jitter on TIMED = TRUE with cycles at "AUTO".

Thanks guys- sorry for the wild goose chase!

jaygame1 wrote on 2020-07-04, 21:32:

ECE no longer has pixel-perfect scaling!?

It has, via the shader support that came with regular DOSBox. But it doesn't contain Ant_222's pixel perfect patch any longer, because he's focusing on dosbox-staging and his patch didn't apply to DOSBox SVN any more.

Yesterplay80 wrote on 2020-07-06, 08:21:

jaygame1 wrote on 2020-07-04, 21:32:

ECE no longer has pixel-perfect scaling!?

It has, via the shader support that came with regular DOSBox. But it doesn't contain Ant_222's pixel perfect patch any longer, because he's focusing on dosbox-staging and his patch didn't apply to DOSBox SVN any more.

So how would I go about enabling it, then?

jaygame1 wrote on 2020-07-10, 18:51:

So how would I go about enabling it, then?

It's not an ECE specific option. https://github.com/tyrells/dosbox-svn-shaders

jaygame1 wrote on 2020-07-10, 18:51:

So how would I go about enabling it, then?

I believe the pixel-perfect scaling equivalent is now done by using the built-in sharp shader?

1glshader  = sharp

Something I noticed with shaders is that they don't work 100% of the time, depending on the resolution.

For instance, running a program like Deluxe Paint at EGA 640x350 and drawing a circle results in an ellipse.

Running IntegerScaler and disabling scalers entirely fixes the aspect ratio, but it makes my computer pretty choppy and slow.

Impatiently waiting for a scaler that works as well as Ant_222's patch, or Staging with Fluidsynth/MUNT support...

Edit: Setting glshader = sharp seems to have fixed the aspect ratio issue I was having, but it's not integer-scaled.

Is there a way to force integer-scaling?

Edit 2: Forcing resolution to 4:3 (in my case, 1920x1440) apparently forces integer scaling, except anything above 640x480. I am not sure what else to try to have pixel-perfect, integer-scaled, aspect-accurate display...

PoulpSquad wrote on 2020-07-11, 23:33:

Is there a way to force integer-scaling?

Try this.

Go to the GitHub Repository for the DOSBox Shaders that was posted earlier in this thread. https://github.com/tyrells/dosbox-svn-shaders and download a copy of the code in zip format. According to the readme, "pixel_perfect.glsl" provides an identical level of scaling in the majority of resolutions when compared to the original Pixel Perfect patch included in DOSBox ECE.

In the zip file go to the interpolation folder and copy "pixel_perfect.glsl" into the main DOSBox Directory.

In your games .conf file (or in the main dosbox-ECE.conf) set the following changes:
[sdl]
output =openglnb

[render]
glshader = pixel_perfect

You may also have to play around with the"scaler" or the "fullresolution" setting to get a usable screen size depending on your GPU aspect settings in your OS. For my system it works best to have "fullresolution" set manually to my monitor's maximum resolution and "scaler=none"

Additionally, if you're using the console you Don't want to see "Shader file "pixel_perfect" not found" in the DOSBox status window. As this means the Shader isn't being used and is likely either in the wrong location or written improperly in the .conf file.

Happy Gaming.

Thanks @Crimson_Zero - my main gripe for now that i can't use "glshaders" subdirectory to store all my shaders, they only can be used from dosbox directory despite what config file says..

KainXVIII wrote on 2020-07-18, 18:57:

Thanks @Crimson_Zero - my main gripe for now that i can't use "glshaders" subdirectory to store all my shaders, they only can be used from dosbox directory despite what config file says..

Your welcome! That little directory issue got me too initially before I noticed that the DOSBox console reported that it couldn't find the shaders even though they were in the supposed "correct" location.

Though it does appear that a work around exists if you really want to use the "glshaders" subdirectory.

Simply put "pixel_perfect.glsl" into the main "glshaders" subdirectory and in your .conf file set the following:

[render]
glshader = glshaders\pixel_perfect

It worked in my test at least!

Crimson_Zero wrote on 2020-07-18, 19:12:

Your welcome! That little directory issue got me too initially before I noticed that the DOSBox console reported that it couldn […]
Show full quote

KainXVIII wrote on 2020-07-18, 18:57:

Thanks @Crimson_Zero - my main gripe for now that i can't use "glshaders" subdirectory to store all my shaders, they only can be used from dosbox directory despite what config file says..

Your welcome! That little directory issue got me too initially before I noticed that the DOSBox console reported that it couldn't find the shaders even though they were in the supposed "correct" location.

Though it does appear that a work around exists if you really want to use the "glshaders" subdirectory.

Simply put "pixel_perfect.glsl" into the main "glshaders" subdirectory and in your .conf file set the following:

[render]
glshader = glshaders\pixel_perfect

It worked in my test at least!

Thanks, i will try your method!

Crimson_Zero wrote on 2020-07-18, 18:05:

Try this. […]
Show full quote

PoulpSquad wrote on 2020-07-11, 23:33:

Is there a way to force integer-scaling?

Try this.

Go to the GitHub Repository for the DOSBox Shaders that was posted earlier in this thread. https://github.com/tyrells/dosbox-svn-shaders and download a copy of the code in zip format. According to the readme, "pixel_perfect.glsl" provides an identical level of scaling in the majority of resolutions when compared to the original Pixel Perfect patch included in DOSBox ECE.

In the zip file go to the interpolation folder and copy "pixel_perfect.glsl" into the main DOSBox Directory.

In your games .conf file (or in the main dosbox-ECE.conf) set the following changes:
[sdl]
output =openglnb

[render]
glshader = pixel_perfect

You may also have to play around with the"scaler" or the "fullresolution" setting to get a usable screen size depending on your GPU aspect settings in your OS. For my system it works best to have "fullresolution" set manually to my monitor's maximum resolution and "scaler=none"

Additionally, if you're using the console you Don't want to see "Shader file "pixel_perfect" not found" in the DOSBox status window. As this means the Shader isn't being used and is likely either in the wrong location or written improperly in the .conf file.

Happy Gaming.

Thanks a lot for your help.

I followed your instructions, and drew a disc in DP, with these results:

I had to take a picture of my monitor with my mobile phone, because taking a screenshot with CTRL+F5 results in this:

Obviously DOSBox *is* capable of proper aspect correction.

I tried disabling aspect correction in NVIDIA control panel with no change.

So close...

FYI, screen captures in DOSBox are not aspect corrected.

It appears you are using 640x350 resolution for DP -- that is not a square pixel mode, so aspect correction makes the circle an ellipse. I guess using a square pixel resolution like 640x480 will give you the results you are looking for, i.e. no stretching from aspect correction.

ripsaw8080 wrote on 2020-07-20, 00:01:

FYI, screen captures in DOSBox are not aspect corrected.

It appears you are using 640x350 resolution for DP -- that is not a square pixel mode, so aspect correction makes the circle an ellipse. I guess using a square pixel resolution like 640x480 will give you the results you are looking for, i.e. no stretching from aspect correction.

That is correct, I am using 640x350 pixels. All other resolutions are displayed correctly.

IntegerScaler with the latest DOSBox SVN works fine in any resolution I can think of, but it interferes with other software and makes my computer really choppy and slow.

DOSBox ECE r4301 works fine too.

I guess there is nothing I can do about it?

Please clarify your specific meaning of "works fine".

I mean that a disc will appear as a disc in DP in 640x350.

As I mentioned before, 640x350 is a non-square pixel mode, and with aspect correction it *should* be stretched into an ellipse. If you don't want aspect correction, then disable it with aspect=false.