DOSBox ECE (for Windows)

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: DOSBox ECE (Windows, Linux)

Postby Yesterplay80 » 2017-8-23 @ 07:42

lukeman3000 wrote:Will the linux version(s) of DOSBox ECE work on a raspberry pi running retropie? And will it support all features such as the MT-32 emulation, pixel-perfect patch, and etc.?

I don't think it will run because it was compiled on/for x86 CPUs, the PIs have ARM CPUs though.
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 235
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (Windows, Linux)

Postby Dominus » 2017-8-23 @ 07:47

Correct. You‘d need to built on or cross-compile for RPi. Expect less performance as DOSBox is not optimized for ARM architecture (there was an effort to port the Dynrec core to ARM but no idea what became of it)
User avatar
Dominus
DOSBox Moderator
 
Posts: 7267
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: DOSBox ECE (Windows, Linux)

Postby James-F » 2017-8-24 @ 07:04

Hi YP80.

The main trunk is still at 4029.
The latest SVN with mame sound cores isn't showing in the configuration file in ECE 4034, I think you need to download the source from the mame branch not from the trunk.
https://sourceforge.net/p/dosbox/code-0 ... /branches/
User avatar
James-F
Oldbie
 
Posts: 1397
Joined: 2015-11-30 @ 04:10

Re: DOSBox ECE (Windows, Linux)

Postby KainXVIII » 2017-8-24 @ 08:58

James-F wrote:Hi YP80.

The main trunk is still at 4029.
The latest SVN with mame sound cores isn't showing in the configuration file in ECE 4034, I think you need to download the source from the mame branch not from the trunk.
https://sourceforge.net/p/dosbox/code-0 ... /branches/

Interesting! Can you give more details about new (?) mame sound cores, please?
User avatar
KainXVIII
Member
 
Posts: 214
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: DOSBox ECE (Windows, Linux)

Postby Yesterplay80 » 2017-8-24 @ 09:08

The MAMESOUND branch isn't usable yet, I still compile the DOSBox trunk: viewtopic.php?f=32&t=55580
That's why the only difference between ECE r4034 and r4029 is the splash screen.
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 235
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (Windows, Linux)

Postby KainXVIII » 2017-8-24 @ 13:02

Also is there possible to implement WIzardry 6-7 audio popping fix in your build like in this one https://www.gog.com/forum/wizardry_seri ... opping_fix ?
User avatar
KainXVIII
Member
 
Posts: 214
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: DOSBox ECE (Windows, Linux)

Postby Qbix » 2017-8-24 @ 13:08

It is not really a fix, more a hack :)
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10355
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: DOSBox ECE (Windows, Linux)

Postby KainXVIII » 2017-8-24 @ 13:54

Qbix wrote:It is not really a fix, more a hack :)

Well, yeah, but this hack did his job =)
User avatar
KainXVIII
Member
 
Posts: 214
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: DOSBox ECE (Windows, Linux)

Postby Ant_222 » 2017-8-24 @ 21:18

Yesterplay80, while experimenting with the Pixel-Perfect patch I have found it to perform about 25% faster with -O3 than with the default -O2. Can you compile DOSBox, or at least the file src/gui/pixelscale.cpp, with this optimization level?
Ant_222
Member
 
Posts: 322
Joined: 2010-7-24 @ 21:29

Re: DOSBox ECE (Windows, Linux)

Postby Yesterplay80 » 2017-8-25 @ 08:07

KainXVIII wrote:Also is there possible to implement WIzardry 6-7 audio popping fix in your build like in this one https://www.gog.com/forum/wizardry_seri ... opping_fix ?

His DOSBox build has several customizations I wouldn't want to copy over to DOSBox ECE, so making a diff without coding knowledge is rather difficult for me. Additionaly, hacks aimed at specific games often tend to break compatibility with other games, so I'd prefer to skip that hack completely.

Ant_222 wrote:Yesterplay80, while experimenting with the Pixel-Perfect patch I have found it to perform about 25% faster with -O3 than with the default -O2. Can you compile DOSBox, or at least the file src/gui/pixelscale.cpp, with this optimization level?

I compiled ECE r4035 omitting the -g flag (there's no debugger integrated anyway) and setting the -O3 flag. Please try if it runs as you expected and let me know!
Last edited by Yesterplay80 on 2017-8-25 @ 08:36, edited 1 time in total.
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 235
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (Windows, Linux)

Postby Ant_222 » 2017-8-25 @ 08:34

Yesterplay80 wrote:I compiled ECE r4035 omitting the -g flag (there's no debugger integrated anyway) and setting the -O3 flag. Please try if it runs as you expected and let me know!
Thank you. I did not build any test into the patch so I don't know how to measure its performance using DOSBox only. I have, however, detected a 25-35% difference between -O2 and -O3 while running the algorithm from my testing program, so the effect must be there in DOSBox too.
Ant_222
Member
 
Posts: 322
Joined: 2010-7-24 @ 21:29

Re: DOSBox ECE (Windows, Linux)

Postby Yesterplay80 » 2017-8-25 @ 21:28

FYI: An updated build of DOSBox ECE r4035 is uploading as I type, containing alpha 13 of Ant_222s pixel perfect patch!
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 235
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (Windows, Linux)

Postby DOSBOXUser1 » 2017-8-25 @ 21:57

Hello !

Does anyone know, how to change the Gamma-setting within the 3Dfx-emulation of DOSBOX ECE ?

I tried to set the environment variables, but DOSBOX ECE seems to ignore these settings. In Tomb Raider I get a really dark screen ... needs a higher Gamma-value ...

SET SST_RGAMMA=1.6
SET SST_GGAMMA=1.6
SET SST_BGAMMA=1.6

unfortunately doesn't work ...

Any ideas ? :cool:
DOSBOXUser1
Newbie
 
Posts: 5
Joined: 2010-11-24 @ 02:16

Re: DOSBox ECE (Windows, Linux)

Postby Giuliano » 2017-8-26 @ 17:06

Hello everyone!

Just joined this forum. I must say, I really enjoy playing old games with DOSBox and DOSBox-ECE. Thank you.

I have always played my favorite games using DOSBox or DOSBox-ECE with the following configuration:

Code: Select all
[sdl]
fullscreen=true
fulldouble=false
fullresolution=640x480
output=ddraw

[dosbox]
machine=svga_s3

[render]
aspect=true
scaler=normal2x

But this week I decided to test them with:

Code: Select all
[sdl]
fullscreen=true
fulldouble=false
fullresolution=desktop
output=ddraw

[dosbox]
machine=svga_s3

[render]
aspect=true
scaler=none

I have noticed the following differences:

1 - fullresolution=desktop and scaler=none give me a bigger game screen (use the monitor's full vertical range).
2 - It is pixel perfect, since normal2x seems to distort the pixels in order to enhance low resolution modes.
3 - But there is one caveat: the image with fullresolution=desktop is brighter than with fullresolution=640x480.

So, games that use brightness and darkness to create a proper "ambiance" are no longer giving the same visual effect. In other games, the new brightness makes some color tones appear too "loud", where they were supposed to only give a sense of shadow or dégradé.

Does DOSBox-ECE offer some way to tweak the brightness?

Cheers!
Last edited by Giuliano on 2017-8-27 @ 01:19, edited 1 time in total.
Giuliano
Newbie
 
Posts: 13
Joined: 2017-8-26 @ 16:24

Re: DOSBox ECE (Windows, Linux)

Postby Ant_222 » 2017-8-26 @ 21:37

Giuliano wrote:But this week I decided to test them with:
Code: Select all
[sdl]
fullscreen=true
fullresolution=desktop
output=ddraw

[render]
aspect=true
I have noticed the following differences:
...
2 - It is pixel perfect, since normal2x seems to distort the pixels in order to enhance low resolution modes.[/code]
It is not pixel-perfect because your output is ddraw. For pixel-perfect display use surfacepp. normal2x is actually a pixel-perfect scaler—just try it with surface output and without aspect-ratio correction. overalay, ddraw, and opengl interpolate the result of scaling and thus destroy pixel-perfection.
Ant_222
Member
 
Posts: 322
Joined: 2010-7-24 @ 21:29

Re: DOSBox ECE (Windows, Linux)

Postby Giuliano » 2017-8-27 @ 01:18

It is not pixel-perfect because your output is ddraw. For pixel-perfect display use surfacepp.


Yes, you're right. I thought it was pixel perfect until now, when I tested it with output=surfacepp. There's a noticeable difference.

(...) just try it with surface output and without aspect-ratio correction.


Just tested with aspect=false, but the game output becomes distorted, since its original resolution is 320x200, which the game stretched to 640x480 in a real PC.

It may be a dumb question, but, why doesn't the game stretch its resolution to 640x480 when it runs inside DOSBox?

Regarding my original question, with fullresolution=desktop (be it output=surfacepp or output=ddraw), the game output is brighter than normal.

I manage to get the correct brightness with fullresolution=640x480 and output=ddraw, which is the configuration I've been using for a long time.

But I would like to change it, from now on, to fullresolution=desktop and output=surfacepp.... but with correct brightness if possible.

Is there a way to tweak the brightness using a command line inside DOSBox-ECE? Or it's only possible by modifying the source code?

Of course, I am correcting the brightness using the monitor's brightness control, but a way to tweak it inside DOSBox-ECE would be better, imho.

Thank you!
Giuliano
Newbie
 
Posts: 13
Joined: 2017-8-26 @ 16:24

Re: DOSBox ECE (Windows, Linux)

Postby Ant_222 » 2017-8-27 @ 09:16

Giuliano wrote:
(...) just try it with surface output and without aspect-ratio correction.
Just tested with aspect=false, but the game output becomes distorted, since its original resolution is 320x200, which the game stretched to 640x480 in a real PC.
That is how DOSBox's normalnx scalers work—applying the same integer scale vertically and horizontally.
It may be a dumb question, but, why doesn't the game stretch its resolution to 640x480 when it runs inside DOSBox?
Because without aspect-ratio correction it keeps the vertical and horizontal scales equal. With aspect-ratio correction it will resize the image to the correct proportions but will distort the pixels (with surface, I mean).

Questions specific to the pixel-perfect patch (rather than to ECE in general) I will gladly answer in the dedicated thread.
Regarding my original question, with fullresolution=desktop (be it output=surfacepp or output=ddraw), the game output is brighter than normal. I manage to get the correct brightness with fullresolution=640x480 and output=ddraw, which is the configuration I've been using for a long time. But I would like to change it, from now on, to fullresolution=desktop and output=surfacepp.... but with correct brightness if possible. Is there a way to tweak the brightness using a command line inside DOSBox-ECE? Or it's only possible by modifying the source code? Of course, I am correcting the brightness using the monitor's brightness control, but a way to tweak it inside DOSBox-ECE would be better, imho.
I am not sure this problem is related to DOSBox ECE or to the pixel-perfect patch. Do you have it in the standard, unpatched, version of DOSBox? If you do, then I suggest that you report the problem in the DOSBox General section. If, however, the standard DOSBox is not at fault, let us see some screenshots together with the corresponding settings.
Ant_222
Member
 
Posts: 322
Joined: 2010-7-24 @ 21:29

Re: DOSBox ECE (Windows, Linux)

Postby Giuliano » 2017-8-27 @ 22:52

Questions specific to the pixel-perfect patch (rather than to ECE in general) I will gladly answer in the dedicated thread.


Thank you. Some new questions arose and I will post them there.

I am not sure this problem is related to DOSBox ECE or to the pixel-perfect patch. Do you have it in the standard, unpatched, version of DOSBox? If you do, then I suggest that you report the problem in the DOSBox General section. If, however, the standard DOSBox is not at fault, let us see some screenshots together with the corresponding settings.


Yes, when I use fullresolution=desktop and output=ddraw with the standard DOSBox, the brightness problem appear as well (image too bright). Brightness is correct with fullresolution=640x480 and output=ddraw.

My reasoning of posting my question to DOSBox-ECE is that I've been seeing a lot of improvements at ECE—like surfacepp and fmstrength—, so I thought that a "brightness tweak" would most probably exist in ECE rather than in the standard version.

Thank you!
Giuliano
Newbie
 
Posts: 13
Joined: 2017-8-26 @ 16:24

Re: DOSBox ECE (Windows, Linux)

Postby lukeman3000 » 2017-8-28 @ 04:10

Hey yesterplay -

This is a small aesthetic thing, but I booted up the most recent build of ECE and noticed the new launch screen image.

Image


Personally, I really dig the old one:

Image


That said, the older background image (without the blue filter) and the newer DOSBox logo look pretty good together, too.. (quick mock-up; didn't feather the edges well):

Image

Is there any practical way for me to switch back to the old launch image, or create a new one, if I prefer?
lukeman3000
Member
 
Posts: 187
Joined: 2009-3-17 @ 00:59

Re: DOSBox ECE (Windows, Linux)

Postby Yesterplay80 » 2017-8-28 @ 08:35

lukeman3000 wrote:Is there any practical way for me to switch back to the old launch image, or create a new one, if I prefer?

Not without compiling a new new binary from the source code and replacing the image file, sorry.

FYI: I adjusted the version numbers for my builds to the latest corresponding revisions which were changed, which means that for the regular DOSBox (vanilla and ECE) it is now r4029 again, because that was the last revision where changes were made in the SF trunk. DOSBox with MAME sound core however has version r4036, because in the last few revisions, changes were only made in this branch. So please refer to the file name to make sure you download the version you are looking for, not just the revision number! Newest != Safest! Also I omitted the "SVN" from the file name, as it's kind of redundant.

Furthermore, I stopped compiling Linux builds. I never managed to compile them as I'd liked them to be (mostly static, instead of shared as they are now) and no one seemed to use them anyway. So the archive folder is where you can find the last linux builds and source codes now, if anyone's even interested.
Last edited by Yesterplay80 on 2017-8-28 @ 09:32, edited 5 times in total.
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 235
Joined: 2016-2-23 @ 11:02
Location: Germany

PreviousNext

Return to DOSBox Development

Who is online

Users browsing this forum: Google [Bot], istellabot [Bot] and 2 guests