VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 200 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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 for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 201 of 1550, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 202 of 1550, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

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/HEAD/ … osbox/branches/


my important / useful posts are here

Reply 203 of 1550, by KainXVIII

User metadata
Rank Member
Rank
Member
James-F wrote:
Hi YP80. […]
Show full quote

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/HEAD/ … osbox/branches/

Interesting! Can you give more details about new (?) mame sound cores, please?

Reply 204 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

The MAMESOUND branch isn't usable yet, I still compile the DOSBox trunk: Questions about the new mamesound branch on SF
That's why the only difference between ECE r4034 and r4029 is the splash screen.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 205 of 1550, by KainXVIII

User metadata
Rank Member
Rank
Member

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 ?

Reply 208 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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?

Reply 209 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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-08-25, 08:36. Edited 1 time in total.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 210 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 211 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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 for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 212 of 1550, by DOSBOXUser1

User metadata
Rank Newbie
Rank
Newbie

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 ? 😎

Reply 213 of 1550, by Giuliano

User metadata
Rank Newbie
Rank
Newbie

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:

[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:

[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-08-27, 01:19. Edited 1 time in total.

Reply 214 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Giuliano wrote:
But this week I decided to test them with: […]
Show full quote

But this week I decided to test them with:

[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.

Reply 215 of 1550, by Giuliano

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 216 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 217 of 1550, by Giuliano

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 218 of 1550, by lukeman3000

User metadata
Rank Member
Rank
Member

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.

2DmxZ1Y.png

Personally, I really dig the old one:

lx0Ddyw.png

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):

qJmRS56.png

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

Reply 219 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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-08-28, 09:32. Edited 5 times in total.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)