pantercat wrote:

Maybe you've downloaded the binary instead of the source? […]
Show full quote

Maybe you've downloaded the binary instead of the source?

DOSBox ECE rXXXX (Linux).7z is 32-bit. If your system is 64-bit and you do not want ie install multiarch, download DOSBox ECE rXXXX (Linux source).7z && extract && compile.

./configure && ./autogen.sh && make

You will have the binary in the src directory.

You may also want to strip it, otherwise you end up with quite a large binary.

1strip dosbox

Before strip my 64bit binary was 35563992 bytes (33MB), after stripping it, this was reduced to 3959544 bytes (3.8MB).
Strip discards debugging symbols, and unless your a developer your unlikely to need that additional data.

Thanks to all for the answers! 😊

My programming skills are limited to writing simple bash scripts, so compiling is not something, I completely understand in all its glamour - but I understood, what you were saying, with the dependencies 😀

If I understood everything right:
The binaries (that I downloaded) are 32-bit and won't work, because the dependencies installed on my system are 64 bit -- and they have the same names.
Solutions: install 32-bit dependencies and use the binaries that I downloaded OR compile the 64-bit version from source to use allready installed dependencies.
The source code on yesterplay80 contains both, 32 and 64 bit....? I guess, if dependencies are missing, I will get a message during compiling.

What do you think is the better solution? Is there a difference in performance? My laptop is not amongst the fastest.
Is one of the two versions more likely to work over time, when updates are released? I am using Debian Stable, so I will not have access to the newest libraries, like in Ubuntu.
Multiarch support is allready installed on my system.

@kcroft: To understand your answer, it will take some time 😉

@_Rob: thanks for the tip. I never heard of strip, but I understand, what it does and will use it - I am not a developer, but I'd love to try some of the new features in the SVN 😀 Can I simply run the command after compiling, in the folder of the binary?

Roger Wilco wrote:

Thanks to all for the answers! :blush: […]
Show full quote

Thanks to all for the answers! 😊

My programming skills are limited to writing simple bash scripts, so compiling is not something, I completely understand in all its glamour - but I understood, what you were saying, with the dependencies 😀

If I understood everything right:
The binaries (that I downloaded) are 32-bit and won't work, because the dependencies installed on my system are 64 bit -- and they have the same names.
Solutions: install 32-bit dependencies and use the binaries that I downloaded OR compile the 64-bit version from source to use allready installed dependencies.

Correct.

Roger Wilco wrote:

The source code on yesterplay80 contains both, 32 and 64 bit....? I guess, if dependencies are missing, I will get a message during compiling.

There is only one source tree, irrespective of architecture. You get a 32bit binary if you use a 32bit build environment, and a 64bit binary if you use a 64bit build environment. If your running a 64bit operating system, your build environment will by default be 64bit.

For setting up a 32bit build environment on a 64bit operating system is beyond the scope here, and you should check elsewhere.

Roger Wilco wrote:

What do you think is the better solution? Is there a difference in performance? My laptop is not amongst the fastest.

Technically this is not an easy answer to give, there are claimed advantages and disadvantages to both. 32bit binaries are smaller, so use less RAM, and occupy less space on the CPUs stack. On the other hand, a 32bit binary will require (potentially many) additional 32bit libraries to be installed, and loaded into memory, which may mean you have both 32bit and 64bit versions in RAM which is a waste.

Roger Wilco wrote:

Is one of the two versions more likely to work over time, when updates are released? I am using Debian Stable, so I will not have access to the newest libraries, like in Ubuntu.
Multiarch support is allready installed on my system.

My understanding (correct me if I'm wrong), is that the DOSBox developers mainly target the 32bit version.

I don't think DOSBox requires the latest and greatest updates, so this should not really matter.

Roger Wilco wrote:

@kcroft: To understand your answer, it will take some time 😉

@_Rob: thanks for the tip. I never heard of strip, but I understand, what it does and will use it - I am not a developer, but I'd love to try some of the new features in the SVN 😀 Can I simply run the command after compiling, in the folder of the binary?

strip is only applicable if you build dosbox yourself. The pre-compiled versions you can download are already stripped.

Thank you very much, _Rob.

This contributes a lot to my understanding of how compiling works. Sounds doable 😀

It's not so easy to understand, if you are missing some basics. Or maybe all of the basics.
Almost all of the literature and help files I found were expecting a much higher level of understanding code.

The first program I ever tried to compile myself had the following instructions:

"Installation: Simple cmake procedure."
And that was that 😁

It's quite a steep curve, but its doable.
Thanks again to all

For DOSBox there is a big difference between 32-bit and 64-bit builds.
The dynamic-x86 recompiler gives much better performance than the regular dynamic recompiler, but can only be used in 32-bit builds.

Success 😊

Just in case, another Debian noob reads this:

I had to:
apt install libsdl1.2-dev

Then I ran across the ....mt32... error discussed a few pages back during make. Installing Scummvm didn't fix it.

I had to install these two debs
libmt32emu-2.3.0.deb
libmt32emu-dev-2.3.0.deb
from here:
https://sourceforge.net/projects/munt/files/m … u-16.04/x86_64/

I'm not up to date on Dosbox matters. It looks like GOG has a new Dosbox version that has the `mount X -t overlay` command, redirecting all writes to their cloud save directory. Is this included in ECE?

Probably not, as I didn't add the code yet to the SVN, I planned to do it today, but my coding time ran out.
Of course, he could create a patch of it himself is he is in a hurry, but doubt that it is worth the effort, if I add it anyway...

Exactly, I'll wait for Qbixs official SVN release, so I can make a new vanilla and a ECE build again. We managed without this feature so far, a few days more won't kill anyone.

I'm very curious to see how this GOG-Cloud-Save change is implemented!

Ideally it will be absolutely generic and agnostic of GOG the company. That is, it will intercept filesystem writes and push them to a configurable HTTP server via standard POST API. Reads will also be intercepted and the HTTP server checked first before falling through to the local filesystem layer.

The actual server hostname / IP / credentials / and so on would be provided externally either via command line arguments or the config file. That way, DOSBox stays company-agnostic. This approach will allow anyone to run their own HTTP service and supply their own server details, so we're not bound to using GOG's services.

What's really interesting is it will allow people to share their save game libraries with others, by sharing their overlay server details. (yes, people could clobber those save games, so it would have to be backed up; or maybe the base set of save-games could be write-protected).

krcroft wrote:

I'm very curious to see how this GOG-Cloud-Save change is implemented! […]
Show full quote

I'm very curious to see how this GOG-Cloud-Save change is implemented!

Ideally it will be absolutely generic and agnostic of GOG the company. That is, it will intercept filesystem writes and push them to a configurable HTTP server via standard POST API. Reads will also be intercepted and the HTTP server checked first before falling through to the local filesystem layer.

The actual server hostname / IP / credentials / and so on would be provided externally either via command line arguments or the config file. That way, DOSBox stays company-agnostic. This approach will allow anyone to run their own HTTP service and supply their own server details, so we're not bound to using GOG's services.

What's really interesting is it will allow people to share their save game libraries with others, by sharing their overlay server details. (yes, people could clobber those save games, so it would have to be backed up; or maybe the base set of save-games could be write-protected).

You can view the source code by downloading one of the updated DOSBox based games from gog.
DOSBox doesn't handle any of the networking, it just places new/modified files in a separate directory. The "cloud" implementation is handled by the galaxy client.

jmarsh wrote:

You can view the source code by downloading one of the updated DOSBox based games from gog.
DOSBox doesn't handle any of the networking, it just places new/modified files in a separate directory. The "cloud" implementation is handled by the galaxy client.

Very nice! On Linux, I've been managing each game as a single Zstandard-compressed SquashFS archive plus an OverlayFS directory to handle writes, in a similar fashion. I use a common script to mount and launch the games. This DOSBox overlay feature will let me eliminate the Linux-provided OverlayFS feature.

There are also some DOSBox users who want to freeze their installed game directories in a pristine state, and feel that subsequent writes (save games, high-score files, and so on) act as pollution. This will let them direct all writes to a separate "pollution" directory that they can manage out-of-band.

Thanks for the info jmarsh!

Yep, the trickier points are dealing with files that are in the pristine folder, but deleted by the game and things like that, but that is all handled transparently as well.
Currently only creating new directories, renaming and removing them is missing, but that is being worked on as well.

krcroft wrote:

There are also some DOSBox users who want to freeze their installed game directories in a pristine state, and feel that subsequent writes (save games, high-score files, and so on) act as pollution. This will let them direct all writes to a separate "pollution" directory that they can manage out-of-band.

Thanks for the info jmarsh!

During the design, the "pristine" directory was treated as CD-ROM, so all code should be precisely doing what you are thinking off. (and in fact you can even have non-write access to the files, which should offer some interesting ways of setting up the game. In the non-overlay version, certain games do need write-access even when they don't write to it, but it was common in DOS to open files in read/write mode, even if you only read) (some sierra games do this, build engines games etc))

Yesterplay80,

Both the ECE screens seem a bit wonky in r4201. Not sure if it's intentional?
They are ok in r4198

I accidently uploaded a build where I messed around with the colors first, just download it again, should be ok now again.

Yes, it's now OK again. Thanks.

Any idea why (when using fullborderless/openglpp/aspect=true at 1920*1080) DOSBox ECE doesn't render the dos prompt window in 4:3? It's still 8:5 there. But if I start a 320x200 game, lsl 1 for an example, then the screen renders at 4:3 (4:3.125).

That window is a resolution of 640x400 scaled to a 1280x800 with your display

i don't have tested borderless mode for now and i'm using an old version of DOSBox ECE

edit: tested build 4202, and yes... in the spash screen i see that resolution of 640x400 scaled to a 1280x800, and it's wider... (this with both fullscreen and borderless)

no problems with 320x200 and 640x480 games, but this only with scaler=none; with other scalers all 320x200 games are doubled to 640x400 and scaled to 1280x800...

DOSBox 0.74-2 has not a doublescan feature (and this with all scalers), DOSBox ECE is using it...

Yeah, both my windowed/fullborderless DOS prompt is scaled to 1280x800 (i.e. upscaled from 640x400) which is a ratio of 8:5. My 'windowresolution' is set to 'desktop'. 'scaler' is set to 'none'.

The ECE readme mentions: "Whereas the standard PARs are themselves ratios of small integers, this mode will yield the exact aspect ratio, provided the output resolution is high enough for the game."

Is 1920x1080 too low a resolution to upscale (with aspect) 640x400 with the openglpp technique?

Issun wrote:

Yeah, both my windowed/fullborderless DOS prompt is scaled to 1280x800 (i.e. upscaled from 640x400) which is a ratio of 8:5. My 'windowresolution' is set to 'desktop'. 'scaler' is set to 'none'.

The ECE readme mentions: "Whereas the standard PARs are themselves ratios of small integers, this mode will yield the exact aspect ratio, provided the output resolution is high enough for the game."

Is 1920x1080 too low a resolution to upscale (with aspect) 640x400 with the openglpp technique?

Yes, is too low... but this is caused by doublescan; with output=surfacepp it works fine, but with that you can use only scaler=none

i'll test it soon with a different display (a 2k display)