Aspect is =false.

DOSBox uses 1:1 when aspect=false, but it seems you're using a shader that has its own rules, so you take that up with the author of the shader.

Ok, thank you for your help!

I'll make sure to ask them.

Was wondering if I could get some help since I don't have the expertise to do this.

I'd like to get the thin "480p-esque" scanlines for DOSBox using the CRT-Geom shader, but the method listed here is for an old format it seems. I couldn't figure out what I should change in the newer version get this effect.

http://emulation.gametechwiki.com/index.php/CRT_Geom

I got the shader from Tyrell's repo here: https://github.com/tyrells/dosbox-svn-shaders … t/crt-geom.glsl

Quick question, I was referred here from my post in Pixel Pefect Patch issues DOSBox ECE r4356

I'd like to understand why the latest ECE build gives directions for using "output=surfacepp" or "output=openglpp", but I'm getting errors when doing so.
It appears things have changed and yet aren't documented. As a software developer myself, I am a fan of current documentation as well as "documentation as code".
I would be happy to open a pull request to update it, however I'm seeing an empty repo on Github. I love the work being done on this project and want it to succeed.

I have to admit I'm new to using ECE, but have been using DOSBox for 8 years or so. But IMO, new users shouldn't have to search on VOGONs to be able to use features 😀

Before you get too worked up about it, note that ECE is NOT official DOSBox, nor supported by the DOSBox devs. The difference between the two are largely experimental. Newbies should be using Official DOSB0x 0.74-3.

johnnystarr wrote on 2020-07-25, 14:24:

Quick question, I was referred here from my post in Pixel Pefect Patch issues DOSBox ECE r4356 […]
Show full quote

Quick question, I was referred here from my post in Pixel Pefect Patch issues DOSBox ECE r4356

I'd like to understand why the latest ECE build gives directions for using "output=surfacepp" or "output=openglpp", but I'm getting errors when doing so.
It appears things have changed and yet aren't documented. As a software developer myself, I am a fan of current documentation as well as "documentation as code".
I would be happy to open a pull request to update it, however I'm seeing an empty repo on Github. I love the work being done on this project and want it to succeed.

I have to admit I'm new to using ECE, but have been using DOSBox for 8 years or so. But IMO, new users shouldn't have to search on VOGONs to be able to use features 😀

The last DOSBox ECE that had the pixel perfect patch implemented was r4301, which you can find in the archives section of the DOSBox on the DOSBox ECE homepage. the source code is also downloadable there. It's from Dec 11, 2019. So not that old.

DOSBox changed enough since that build that the pixel perfect patch won't work on any build based on it. The author of the patch is currently focused on another project. Re: DOSBox ECE (for Windows & Linux)

Alternatively, you can use the new OpenGL shader support to download and enable a shader that, according to the author, gives the exact same results as the Pixel Perfect Patch in the majority of resolutions. Re: DOSBox ECE (for Windows & Linux) I personally use this option. (Note that as stated in the linked post the pixel_perfect.glsl goes into the root DOSBox folder, not glshaders. That's likely why it wasn't enabled in your previous topic Re: Pixel Pefect Patch issues DOSBox ECE r4356 )

PoulpSquad wrote on 2020-07-20, 00:26:

That is correct, I am using 640x350 pixels. All other resolutions are displayed correctly. […]
Show full quote

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?

So I was messing around with this, and did find a way to create a perfect circle in Deluxe Paint using the current DOSBox ECE with the pixel_perfect.glsl shader in 640x350 using fullscreen mode.

This post from DOSBox-X was the big clue. https://github.com/joncampbell123/dosbox-x/issues/400 As apparently VGA graphics modes pad the display area to 400 lines to make it work with VGA monitors. So changing to EGA is necessary

So from a clean dosbox-ECE.conf I made the following changes:

[sdl] fullresolution = 1920x1080 output = openglnb […]
Show full quote

[sdl]
fullresolution = 1920x1080
output = openglnb

[dosbox]
machine = ega

[render]
aspect = true
scaler = none
glshader = pixel_perfect

Obviously change the full resolution to whatever your monitors is. Or use fullresolution = desktop

For curiosity's sake, what games/programs were you wanting the 640x350 EGA video mode for? It seems to be a short list of games that use this mode where a better VGA mode isn't available...

Crimson_Zero wrote on 2020-07-26, 18:40:

So I was messing around with this, and did find a way to create a perfect circle in Deluxe Paint using the current DOSBox ECE wi […]
Show full quote

PoulpSquad wrote on 2020-07-20, 00:26:

That is correct, I am using 640x350 pixels. All other resolutions are displayed correctly. […]
Show full quote

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?

So I was messing around with this, and did find a way to create a perfect circle in Deluxe Paint using the current DOSBox ECE with the pixel_perfect.glsl shader in 640x350 using fullscreen mode.

This post from DOSBox-X was the big clue. https://github.com/joncampbell123/dosbox-x/issues/400 As apparently VGA graphics modes pad the display area to 400 lines to make it work with VGA monitors. So changing to EGA is necessary

So from a clean dosbox-ECE.conf I made the following changes:

[sdl] fullresolution = 1920x1080 output = openglnb […]
Show full quote

[sdl]
fullresolution = 1920x1080
output = openglnb

[dosbox]
machine = ega

[render]
aspect = true
scaler = none
glshader = pixel_perfect

Obviously change the full resolution to whatever your monitors is. Or use fullresolution = desktop

For curiosity's sake, what games/programs were you wanting the 640x350 EGA video mode for? It seems to be a short list of games that use this mode where a better VGA mode isn't available...

Thank you for looking into this.

No game in particular. It's just a case where aspect correction is messed up. Maybe Darkseed uses 640x350.

Aspect=true messes with aspect ratio also. I gave up on integer scaling on DOSBox. I'm waiting for DOSBox staging to include Fluidsynth and MUNT, and I'll switch to that from DOSBox ECE r4301.

PoulpSquad wrote on 2020-07-26, 23:28:

Thank you for looking into this.

No game in particular. It's just a case where aspect correction is messed up. Maybe Darkseed uses 640x350.

Aspect=true messes with aspect ratio also. I gave up on integer scaling on DOSBox. I'm waiting for DOSBox staging to include Fluidsynth and MUNT, and I'll switch to that from DOSBox ECE r4301.

No problem, it's an interesting issue! On that note did you try the above settings? From what I've read through Ant_222 VIDEO Patch for pixel-perfect scaling (SDL1) thread his patch respects the DOSBox aspect correction setting VIDEO Patch for pixel-perfect scaling (SDL1).

From his change log:
Uploading the Windows binary and the diff patch. The algorithm now respects the aspect setting.
This was required to play games whose native pixel aspect ratio is different from the one DOSBox assumes. Lure of the Temptress seems one of them.

And he later states that in most cases Aspect should be set to true Re: Full-screen mode

Since pixel_perfect.glsl is based on his patch, I would assume the same applies. It certainly seems so for 640x350 EGA anyways!

How can I mount a cd image file (iso) as a d drive when booting? I insert below code into "dosbox-ECE.conf" but it is totally impossible to mount cd-rom by using"oakcdrom.sys" and "mscdex.exe" in both of autoexec.bat and config.sys, after I succeed booting process in dosbox .

imgmount c image40.img-t hdd -size 512,63,2,650 -fs fat
imgmount d game.iso -t iso -fs iso -ide 2m
boot -l c

and I heard that "mounting a CD while booting requires the IDE emulation".Does DOSBOX-ECE really supports IDE emulation like DOSBOX-X ?

johnnystarr wrote on 2020-07-25, 14:24:

I'd like to understand why the latest ECE build gives directions for using "output=surfacepp" or "output=openglpp", but I'm getting errors when doing so.

That's easy to explain: I simply forgot to remove/edit the corresponding text files. 😉

bshi02 wrote on 2020-07-29, 03:01:

and I heard that "mounting a CD while booting requires the IDE emulation".Does DOSBOX-ECE really supports IDE emulation like DOSBOX-X ?

Nope. Never did and probably never will.

Yesterplay80 wrote on 2020-07-30, 06:41:

I simply forgot to remove/edit the corresponding text files. 😉

I saw a repo in Github that was empty... Perhaps had content at one point. Is this your personal project, or is it open source? Asking because I'd be more than happy to open a PR to fix the documentation. I'm a professional engineer.

Between ece r4356, svn r4356, staging 0.76.0-alpha-399-g6c010, & x 0.83.3, ece runs mips without corrupted output, but, output will be corrupted after a cls, but, a dir after cls and it will give uncorrupted output again, which should help narrow down the remaining error, diff of what cls is touching vs dir. Next best is svn, it too will run uncorrupted, but, it's hit and miss, one fresh instance runs uncorrupted, run a fresh instance again, corrupted, same steps, different result, and with the uncorrupted run, after a cls corrupts the output, dir doesn't correct it back to clean like ece.

edit: more ece behavior, will start with borked output. dir wont fix, cls then dir does fix.

Are you sure it's not just a bug in the program? No system was so fast back in 1986 when MIPS was written, so try cycles=2000 or thereabouts for speeds more appropriate for the era than cycles=max.

ece outputs the screen correctly regardless, and corrects a garbled screen by running dir a time or two while the others are stuck at garbled output. Enough to possibly figure out what goes wrong and keep it from doing so. It may be limited to mips, or may crop up elsewhere, and at different speeds, with how ece is behaving that concern is nearly moot.

It appears that it messes up when the IBM/PC multiple exceeds 99.99, as you will notice the lines that mess up have a blank there. Please keep in mind that cycles=max is not a constant speed; DOSBox is trying to calculate the needed cycles over time, so it will give varying results.

Hi guys; just looking for some clarification -

* ECE no longer has ant's pixel-perfect support, but it can be added?

* Does the latest version of DOSBox (0.74-3) have ant's pixel-perfect?

* Is r4301 still the latest version of ECE that is the most feature-complete and stable? (presuming it includes pixel perfect as well?)

* Lastly, and this may be extending beyond the scope of this thread - does ScummVM now support some kind of pixel-perfect scaling? And furthermore, if so, what reasons might there be to continue playing games with DOSBox as opposed to ScummVM from a practical/functional point of view? I like DOSBox; I'm just wondering what differences (noticeable by the user) there are in the gaming experience between the two, at this point in time.

lukeman3000 wrote on 2020-09-02, 21:21:

Hi guys; just looking for some clarification - […]
Show full quote

Hi guys; just looking for some clarification -

* ECE no longer has ant's pixel-perfect support, but it can be added?

* Does the latest version of DOSBox (0.74-3) have ant's pixel-perfect?

* Is r4301 still the latest version of ECE that is the most feature-complete and stable? (presuming it includes pixel perfect as well?)

* Lastly, and this may be extending beyond the scope of this thread - does ScummVM now support some kind of pixel-perfect scaling? And furthermore, if so, what reasons might there be to continue playing games with DOSBox as opposed to ScummVM from a practical/functional point of view? I like DOSBox; I'm just wondering what differences (noticeable by the user) there are in the gaming experience between the two, at this point in time.

Pixel-perfect support can be added through shaders https://github.com/tyrells/dosbox-svn-shaders
ScummVM is usually better and have pixel-perfect scaling, but some games are not 100% compatible (https://www.scummvm.org/compatibility/), so expect a bunch of bugs compared to pure dosbox emulation.

KainXVIII wrote on 2020-09-02, 21:43:

lukeman3000 wrote on 2020-09-02, 21:21:

Hi guys; just looking for some clarification - […]
Show full quote

Hi guys; just looking for some clarification -

* ECE no longer has ant's pixel-perfect support, but it can be added?

* Does the latest version of DOSBox (0.74-3) have ant's pixel-perfect?

* Is r4301 still the latest version of ECE that is the most feature-complete and stable? (presuming it includes pixel perfect as well?)

* Lastly, and this may be extending beyond the scope of this thread - does ScummVM now support some kind of pixel-perfect scaling? And furthermore, if so, what reasons might there be to continue playing games with DOSBox as opposed to ScummVM from a practical/functional point of view? I like DOSBox; I'm just wondering what differences (noticeable by the user) there are in the gaming experience between the two, at this point in time.

Pixel-perfect support can be added through shaders https://github.com/tyrells/dosbox-svn-shaders
ScummVM is usually better and have pixel-perfect scaling, but some games are not 100% compatible (https://www.scummvm.org/compatibility/), so expect a bunch of bugs compared to pure dosbox emulation.

Thanks; just checked out that link. It looks like the pixel perfect implementation in ECE may still be superior in at least some ways. In which case, is ECE version r4301 still the most stable and feature-complete release containing ant's pixel perfect patch?