VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 940 of 1031, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

the 4-6 scaler patch should be easy to repair. Maybe one of the next commits will make it possible to apply again, as is.
It's probably the partial 4x4 scaler implementation that went into the commit (that broke it), as my code contains more changes than the part that I committed.
It's no secret that I am messing/experimenting around with the image scaling part, so any patches in that area might continue to break (and get fixed/break again).

If you want to apply the 4-6 patch, just undo the last 2 commits. They don't change any functionality, but made sense given the larger scope.

Water flows down the stream
How to ask questions the smart way!

Reply 942 of 1031, by realnc

User metadata
Rank Member
Rank
Member
Qbix wrote on 2020-01-29, 09:28:
the 4-6 scaler patch should be easy to repair. Maybe one of the next commits will make it possible to apply again, as is. It' […]
Show full quote

the 4-6 scaler patch should be easy to repair. Maybe one of the next commits will make it possible to apply again, as is.
It's probably the partial 4x4 scaler implementation that went into the commit (that broke it), as my code contains more changes than the part that I committed.
It's no secret that I am messing/experimenting around with the image scaling part, so any patches in that area might continue to break (and get fixed/break again).

If you want to apply the 4-6 patch, just undo the last 2 commits. They don't change any functionality, but made sense given the larger scope.

Why not merge these patches?

Reply 943 of 1031, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

The PC Speaker emulation in current SVN is shit.
No Nuked OPL3 support in official SVN.
The lack of support of .ogg and other audio formats for .cue is very limiting (my entire DOSBox CD library is in .OGG).
Maximum scaling of x3 is still blurry since vertical 200 x 3=600, we need something closer to 1200 (x6 for me).

imo, These are fundamental features official DOSBox should have.

I'm going to cry.. 😢


my important / useful posts are here

Reply 944 of 1031, by Yesterplay80

User metadata
Rank Member
Rank
Member
lukeman3000 wrote on 2020-01-29, 10:50:

At this point, which version of ECE is the most feature complete, functional, and “non-broken”?

r4301

James-F wrote on 2020-01-29, 11:34:

The lack of support of .ogg and other audio formats for .cue is very limiting (my entire DOSBox CD library is in .OGG).

Vanilla DOSBox supports OGG as audio files as well, it's MP3, FLAC and OPUS that ECE can handle thanks to krcrofts patch.

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

Reply 946 of 1031, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
Yesterplay80 wrote on 2020-01-29, 08:53:

TBH, the speed bumps are getting worse and worse. First I couldn't get krcrofts patch working any more, because it now depends on opusfile, which I can't get compiled under mingw, but switching to MSYS2 didn't work neither because I can't get SDL-sound working there. Then some update to SVN "killed" Ant_222s pixel perfect patch. Now the latest updates to SVN broke compatibility with VileRancours patch for the 4-6x scalers... I'm no developer and certainly no pro at setting up dev environments, plus time is short anyway atm. And it probably won't get better in the near future.

Honestly, ECEs future doesn't look to bright atm... Maybe it's time to quit and leave the stage to more capable people, who know better what they're doing (I'm looking at DOSBox-X or dosbox-staging).

That certainly doesn't sound great. I hope you can arrive at a solution that involves keeping your hand in. Running a project is as much about judgement and vision as anything, and you've shown a much better balance between features and stability than most.

Dosbox-staging seemed more about modernizing the toolset than making a particular build. Git should make it much easier to share changes between different branches. Maybe using their platform would help tackle some of the problems ahead?

All hail the Great Capacitor Brand Finder

Reply 948 of 1031, by FulValBot

User metadata
Rank Newbie
Rank
Newbie

I have tried in DOSBox ECE output=opengl and a resolution of 1600x1000 (also 1280x1000) to scale 320x200 games (i have a 1080p display) and DooM1... is blurred also with scaler=normal5x and scaler=normal6x, but this only with aspect=true

if i try aspect=false it works fine (but i think with a wrong aspect ratio); no problems with output=surfacepp and output=openglpp and scaler=none (and if i use aspect=false it works fine also with output=opengl and scaler=none, with the same resolutions)

No problems with 640x480 resolution scaled to 1280x960 (that works fine also with output=surfacepp and output=openglpp; i don't have tested v-sync, i don't need it)
also 320x240 scaled to 1280x960 it works fine

with DOSBox 0.74-3 i can't remove blur (with aspect=false there aren't distorsions or unheven pixels)

Reply 949 of 1031, by Yesterplay80

User metadata
Rank Member
Rank
Member
FulValBot wrote on 2020-01-30, 12:12:

I have tried in DOSBox ECE output=opengl and a resolution of 1600x1000 (also 1280x1000) to scale 320x200 games (i have a 1080p display) and DooM1... is blurred also with scaler=normal5x and scaler=normal6x, but this only with aspect=true

That's normal, OpenGL output applies bilinear filtering to the image. You have to choose openglnb or openglpp for the image to be sharp. And what are you trying to achieve by running all kinds of resolutions?

To get a crystal clear fullscreen image with correct aspect ratio set

fullresolution = desktop
output = openglnb (or openglpp, if you want the image to be pixel perfect)
aspect = true
scaler = none

If you prefer playing in windowed mode, just set the desired output resolution (ideally a multiple of the original resolution) with

windowresolution = <whateveryoulike>

and all other options as above.

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

Reply 950 of 1031, by Pr3tty F1y

User metadata
Rank Newbie
Rank
Newbie

These settings give a good/sharp picture for me on my 1080p display:

[sdl]
fullscreen = true
fullborderless = false
fullresolution = 1440x1080
output = opengl

[render]
aspect = true
scaler = normal3x forced

Reply 951 of 1031, by truemaster

User metadata
Rank Newbie
Rank
Newbie

i believe its a mater of time for patches to be corected and new ece to be released. this ece is far fron its doom. also looking at the official dosbox0.75 development they have also issues dont know what issues are they, but its coicidence.

Reply 952 of 1031, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

You asked for experiences i got some, overall it's fine and personally i haven't many dislikes, what i read here are tidbits from my pov and no important things.
I'm very grateful for the implementation of Munt and Fluidsynth.
Usually i like to blurr it, matter of choice if you stared for decades in a crt you won't like the crispness it gives you to well, neither i like the original low resolution and appreciate the visiual enhancements, personally i see no advantage of an exact 320x200 resolution on a "4k" monitor, useless if you ask me.
Or to set the game to 4:3 aspect ratio just because the rotten crt was 4:3 and couldn't display the original 16:10 res proper.
Matter of choice.
I'm happy to bypass that (even for my emulated amigas) a circle has to be a circle and not an oval just because the shitty crt displayed it oval.

However even i have some dislikes, this is mainly something which has been stated already, i like to capture the sound from the fluidsynth.
It is quite a difference for some games if i convert the midi to a waveform in the "plain way" or if i play them back using the exact drivers from back then.
Recently i fumble around with BARIS and it's a nice example for this, except for the GM versions the midi will only sound right played back in DOSBox using the miles drivers and the for this game very special and heavy used GTL libraries.
External Munt i.e. can't offer you this because it disregards the GTL and the music will sound wrong (probably they could be extracted to a sysex file?).
But also Fluidsynth isn't the same, it has some drawbacks in DOSBox ECE but sounds otherwise better to me (might be i only pretend this).

First i noticed both Munt and your implementation have inversed stereo, if i think right about this it is obvious since the MT is a Synthesizer so if you play for an audience this setup will be proper, left becomes right for the listener.
However i found out "reverse.stereo" has to be true else left becomes right channel if you sit in front of the machine, you are the audience in this case.

The implementation of Fluidsynth has a small drawback, it can't load large soundfonts, "Crisis3" which is 1.6GB won't load at all, while sure i can load it to Fluidsynth itself.
OhKeh no one wants or needs "Crisis3" it isn't worth the size in my opinion.
But i like "Fatboy" very well, in my opinion the best soundfont especially when it comes to classical or jazz music.
Fatboy is about 300MB and already reaches some limit, it loads but can fail to reload if you change the volume of Fluidsynth in DOSBox (i like to create batch playlists from the games midi, perhaps you know this already).

In some sort of way a soundfont can't be big enough and still it won't reach the depth and saturation of a synthesizer, this i experienced with your implementation of Munt it's quite a difference even if it's only emulated.

As you can see music is to me as a short sighted much more of interest as the already blurred view i have, and it won't get better over the decades 😉

However, i would like to capture Fluidsynths output without to use the audio loopback because it will distort the signal a little bit (compare a square wave from Tandy output, captured from within DOSBox them are absolute square waves while using the loopback the signal is blurred).
Further i would like if i can load large soundfonts even if i think 1.6GB "Crisis3" isn't needed at all it should be possible.
At least i like to use Fatboy without any problems (which isn't the case as long as long as you load the soundfont only once and didn't change the volume of Fluidsynth which will be the case if you play a game).

Of course i could use another virtual synth such as "coolsoft" but as i already stated especially for games from the early '90s it won't be the same because it won't reproduce the midi exactly like the games played them back.
But most of all i like that i won't have to care about the soundfont to use or it's volume setting once i elaborated that.
That i can create a batch for a music selection which was hardly possible to have on a real machine.

Some like it exact, some others like to have the most enhancements possible.
Well if you would like the exact sound you would select PC Speaker or AdLib, that was what a common user could afford back then.
I no way you would have had GUS, MT-32, SB, SC all in one machine, but let's make use of that.
If i like the exact display i get a crt and burn out my eyes with it.
Else i use the enhancements.

I mean yes dammit i carried an old Belinea Multisync Monitor on my shoulders at home, just for my rotten Miggy (which is neither of any need, the emulated A4000 runs better as my real one, it is mainly to compare the music output, it seems still the PC can't handle breakbeats proper)
Strangewisely a PC isn't worthy enough for such to me, i never cared for them to much, it's a shitty PC still to me.

Ok enough lamento, i like DOSBox ECE.
Keep it this way, keep the idea of the ease.
It is right to play games, far enough.
Playback a PC demo on a dedicated machine which no one had except the one who created the demo?
Not very useful from my pov.
Respect one certain game and risk that the rest won't run well?
In no way.

A friend of mine, to tell it right the recent dev. of "FFED3D" suggested to me once DOSBox-X, he prefers it but i think it's just overloaded, it is a monster to handle and certainly no thing you will need just to play a game.
Nothing, really no advantage to play games over vanilla DOSBox or ECE.

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 953 of 1031, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

I see there is some new magic going on with the official scaler.
Using scaler=none and opengl, at certain resolution bilinear filtering is applied but on others not.
Easiest to test with Quake that can switch all resolutions on the fly.
320x200, 320x240, 800x600 there is no bilinear filtering,, but 360x200, 360x240 is fully filtered.

Ah okay, I see.
My fullresolution=1600x1200 (1920x1200 monitor) and aspect=true, so everything that is perfect integer has no bilinear filtering but non integer does, very clever indeed.
It needs some debugging because 320x400 (in Quake) is an integer of 1600x1200 but it filters it too,, or maybe dosbox rescales it to 640x400 first? (in that case 640 does not scale to 1600)
edit: okay dosbox scales 320x400 to 640x400 so no integer with 1600x1200, tested with windowresolution=original.

I would still like to force a scale2x-3x on non integer resolutions if possible for a less filtered look.
For example on a 1080p monitor, no DOS resolution (200, 240, 400, 480) is integer scale ever, so to control the amount of blur/filtering a forced scaling should be applied first.

EDIT:
Unless of course it's my GPU (Nvidia GTX660) that does this and not dosbox, making this post completely invalid.


my important / useful posts are here

Reply 954 of 1031, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

That change is over a year old: https://sourceforge.net/p/dosbox/code-0/4178/

James-F wrote on 2020-02-08, 09:17:

I would still like to force a scale2x-3x on non integer resolutions if possible for a less filtered look.
For example on a 1080p monitor, no DOS resolution (200, 240, 400, 480) is integer scale ever, so to control the amount of blur/filtering a forced scaling should be applied first.

scaler normal2x/3x forced with output=opengl does an integer upscale first followed by bilinear resizing, how is that different?

Reply 955 of 1031, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

320x200 or 320x240 scales perfectly to 1600x1200 so no interpolation is used,, forcing 2x or 3x is no longer integer of 1600x1200 and it interpolates the image.
I'm not sure dosbox is doing that, but rather my gpu,, need confirmation.

The point of all my commotion is to make the pixels sharper yet maintain their consistency and pixel-aspect-ratio.
Non integer resolution with nearest neighbor scaling distorts the pixels so some interpolation is needed,,, but to make the interpolation less blurry some integer prescaling is needed.
As said before, 3x is not enough for 200p, 240p games, since 200*3 is only 600, scaled to 1080p,, the result is still too blurry.


my important / useful posts are here

Reply 956 of 1031, by FulValBot

User metadata
Rank Newbie
Rank
Newbie

You need to use output=openglpp or output=surfacepp and scaler=none (i have tried scaler=scan2x and scaler=tv2x but this remove aspect ratio correction for all 320x200 games; this also with scaler=normal2x, normal3x, scan3x, tv3x)

output=opengl includes bilinear filter and without integer scaling (all 320x200 games will have distorsions if you use aspect=true...)

with a 1080p and a 12oop displays all 320x240 and all 640x480 need to be scaled to 1280x960 (with a 1440p display these games will be scaled to 1920x1440)

Reply 957 of 1031, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Latest ECE editions removed Scale 4x-6x and Ant_222's scalers.

FulValBot wrote on 2020-02-08, 16:49:

with a 1080p and a 12oop displays all 320x240 and all 640x480 need to be scaled to 1280x960 (with a 1440p display these games will be scaled to 1920x1440)

I want to use bilinear filtering that is intentional and important to maintain undistorted pixel aspect ratio (PAR),, but with resolutions closer to my native display resolution.
Also, 320x240 and 320x200 are perfect integers of 1600x1200 with scaler=none.

It's not hard to understand, without prescaling non-integer lower resolutions before interpolation you get blurry image,, to prevent that you prescale them to a resolution closer to your native display (or higher) before interpolation.
Most DOS games are 320x200 and Scale3x in dosbox is not enough by any means on any modern display.

Any word from the dev team about this?


my important / useful posts are here

Reply 958 of 1031, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote on 2020-02-09, 08:00:

Any word from the dev team about this?

Would you be happy with this instead:
An integer upscale to the closest resolution equal to or larger than the output resolution, followed by bilinear filtering.
So for example with input 320x200 and output 2048x1536:
320x200 -> 7x8 integer upscale = 2240x1600 -> bilinear downscale to 2048x1536.

Reply 959 of 1031, by James-F

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2020-02-09, 12:11:

An integer upscale to the closest resolution equal to or larger than the output resolution, followed by bilinear filtering.

+1000


my important / useful posts are here