Mint 19.3 and I was using sudo apt-get install libsdl12:i386 or something like that, and you were right, it was a 32 bit dependency issue and I got the wrong SDL. Just downloaded that right one and now it wants libpng, so I'll keep on hunting these down. Thanks again!

Yesterplay80 wrote on 2020-02-21, 15:42:

Srandista wrote on 2020-02-21, 15:05:

What was the last version with Pixel perfect scaling? r4301?

Yup.

Hi, Yesterplay80. Given that for many users like me, pixel-perfect scaling is the most/only interesting feature of DOSBox ECE compared with the regular official DOSBox, it would probably make sense to add a direct link to the latest build of DOSBox ECE that had pixel-perfect scaling, to the page of DOSBox ECE (dosboxece.yesterplay.net/en/ ). Thanks.

Just go to his page and click the "archive" link for earlier builds.

MT_ wrote on 2020-03-06, 12:09:

Hi, Yesterplay80. Given that for many users like me, pixel-perfect scaling is the most/only interesting feature of DOSBox ECE compared with the regular official DOSBox, it would probably make sense to add a direct link to the latest build of DOSBox ECE that had pixel-perfect scaling, to the page of DOSBox ECE (dosboxece.yesterplay.net/en/ ). Thanks.

Actually, that's not too bad an idea, I updated the page accordingly.

jmarsh wrote on 2020-02-11, 15:35:

If you want pixel perfect all you need to do is use a default fragment shader with a vertex shader that warps the vertices to integer multiples of the input size. The framebuffer is already cleared to black so no need to worry about discarding fragments etc.

I have spent some time this weekend creating a shader version of the pixel perfect scaling algorithm described here: https://tanalin.com/en/articles/integer-scaling/.

A demo of the shader can be seen here: https://www.shadertoy.com/view/3dsyW7

It shouldn't be difficult to convert this to a format supported by DOSBox, so I will try spend some time doing that this week.

Yesterplay80 wrote on 2020-03-07, 08:49:

MT_ wrote on 2020-03-06, 12:09:

Hi, Yesterplay80. Given that for many users like me, pixel-perfect scaling is the most/only interesting feature of DOSBox ECE compared with the regular official DOSBox, it would probably make sense to add a direct link to the latest build of DOSBox ECE that had pixel-perfect scaling, to the page of DOSBox ECE (dosboxece.yesterplay.net/en/ ). Thanks.

Actually, that's not too bad an idea, I updated the page accordingly.

Thanks. For what it’s worth, looks like the Linux source-code link points to the same file as the Windows source-code link.

By the way, why is source code different for Windows and Linux in the first place? Looks like the set of files is exactly the same. Are there differences except for line-endings’ style? If it’s just about line endings, it would be enough to have just the Unix-style (LF) version, Windows developers now use this style too, and even the modern version of Notepad supports Unix line endings.

tyrells wrote on 2020-03-23, 15:49:

I have spent some time this weekend creating a shader version of the pixel perfect scaling algorithm described here: https://tanalin.com/en/articles/integer-scaling/.

A demo of the shader can be seen here: https://www.shadertoy.com/view/3dsyW7

It shouldn't be difficult to convert this to a format supported by DOSBox, so I will try spend some time doing that this week.

Nice. For what it’s worth, there is also the IntegerScaling library providing sort of reference implementations by myself (I am the author of the algorithm itself) in four languages: C++, Rust, JS, PHP.

MT_ wrote on 2020-03-23, 22:53:

By the way, why is source code different for Windows and Linux in the first place? Looks like the set of files is exactly the same.

The Voodoo patch for Linux differs just slightly from the one for Windows. And it requires a small change to the gl.h header file.

I have a problem with screenshots in DOSBox ECE r4334, when using the CTRL-F5 screenshot function, it generates a zero byte file. I don't have this problem with vanilla DOSBox or other DOSBox forks, but then all the other builds are 64-bit, so that may have something to do with it.

This is on Fedora 31 64-bit and I'm using your pre-compiled 32-bit binary from "DOSBox ECE r4334 (Linux).7z"

Looking through the logs, I found this
libpng warning: Application was compiled with png.h from libpng-1.6.37
libpng warning: Application is running with png.c from libpng-1.2.57
libpng error: Incompatible libpng version in application and library

Checking what 32bit libs I have installed:
$ rpm -qa|grep libpng|grep i686
libpng-1.6.37-2.fc31.i686
libpng12-1.2.57-10.fc31.i686

So it seems it uses the older lib while the newer one is also present.

$ rpm -ql libpng-1.6.37-2.fc31.i686
/usr/lib/.build-id
/usr/lib/.build-id/c4
/usr/lib/.build-id/c4/cb5fa1892e95939fb14d7d06d7b3a14c6d3f63
/usr/lib/libpng16.so.16
/usr/lib/libpng16.so.16.37.0
/usr/share/licenses/libpng
/usr/share/licenses/libpng/LICENSE
/usr/share/man/man5/png.5.gz

$ rpm -ql libpng12-1.2.57-10.fc31.i686
/usr/lib/.build-id
/usr/lib/.build-id/47
/usr/lib/.build-id/47/73de14df65fb0cb23a20937d6bae01336a0c84
/usr/lib/libpng12.so.0
/usr/lib/libpng12.so.0.57.0
/usr/share/doc/libpng12
/usr/share/doc/libpng12/CHANGES
/usr/share/doc/libpng12/README
/usr/share/doc/libpng12/TODO
/usr/share/doc/libpng12/libpng-1.2.57.txt
/usr/share/licenses/libpng12
/usr/share/licenses/libpng12/LICENSE

$ ls -l /usr/lib/libpng1*
lrwxrwxrwx 1 root root 18 Jul 26 2019 /usr/lib/libpng12.so.0 -> libpng12.so.0.57.0
-rwxr-xr-x 1 root root 189160 Jul 26 2019 /usr/lib/libpng12.so.0.57.0
lrwxrwxrwx 1 root root 19 Jul 26 2019 /usr/lib/libpng16.so.16 -> libpng16.so.16.37.0
-rwxr-xr-x 1 root root 255680 Jul 26 2019 /usr/lib/libpng16.so.16.37.0

tyrells wrote on 2020-03-23, 15:49:

I have spent some time this weekend creating a shader version of the pixel perfect scaling algorithm described here: https://tan […]
Show full quote

jmarsh wrote on 2020-02-11, 15:35:

If you want pixel perfect all you need to do is use a default fragment shader with a vertex shader that warps the vertices to integer multiples of the input size. The framebuffer is already cleared to black so no need to worry about discarding fragments etc.

I have spent some time this weekend creating a shader version of the pixel perfect scaling algorithm described here: https://tanalin.com/en/articles/integer-scaling/.

A demo of the shader can be seen here: https://www.shadertoy.com/view/3dsyW7

It shouldn't be difficult to convert this to a format supported by DOSBox, so I will try spend some time doing that this week.

I have fixed a few bugs in the original version of this shader and have ported it to DOSBox SVN. The pixel perfect shader (as well as a version of pixellate from libretro) can be found here: https://github.com/tyrells/dosbox-svn-shaders. I would appreciate any comments or feedback.

tyrells wrote on 2020-03-27, 04:31:

I have fixed a few bugs in the original version of this shader and have ported it to DOSBox SVN. The pixel perfect shader (as well as a version of pixellate from libretro) can be found here: https://github.com/tyrells/dosbox-svn-shaders. I would appreciate any comments or feedback.

Cool. Do you mind if i use it on my ppa? I'd probably place them on a directory that is not home dependent (people move or delete those files, and then they'd have to 'reinstall' so it's better to place them on a read only dir on installation) so i'd prefer to make a small patch to svn (applied automatically) to make dosbox fallback to it after home and current exec dir for glshaders.

I was thinking of pixel perfect but i didn't like it touches upstream code, so something that is completely modular and separate like this is much better. The advantage of using launchpad for this is that when the github updates, it triggers a build for the ppa. The disadvantage is if something breaks the build - but this can't, because it's completely runtime.

I'd honestly prefer using libretro nowadays but i have some requirements they don't satisfy (mt32, voodoo, the 8gb hd patch, a Copy-on-write VFS layer or at least a way to *invoke* the one i have before starting games on the core, using my conf files onions instead of ineffectually starting execs, deleting some trash after running the core i place on the linux ramdisk for windows 95/98).

Serious Callers Only wrote on 2020-04-02, 02:41:

Cool. Do you mind if i use it on my ppa? I'd probably place them on a directory that is not home dependent (people move or delet […]
Show full quote

tyrells wrote on 2020-03-27, 04:31:

I have fixed a few bugs in the original version of this shader and have ported it to DOSBox SVN. The pixel perfect shader (as well as a version of pixellate from libretro) can be found here: https://github.com/tyrells/dosbox-svn-shaders. I would appreciate any comments or feedback.

Cool. Do you mind if i use it on my ppa? I'd probably place them on a directory that is not home dependent (people move or delete those files, and then they'd have to 'reinstall' so it's better to place them on a read only dir on installation) so i'd prefer to make a small patch to svn (applied automatically) to make dosbox fallback to it after home and current exec dir for glshaders.

I was thinking of pixel perfect but i didn't like it touches upstream code, so something that is completely modular and separate like this is much better. The advantage of using launchpad for this is that when the github updates, it triggers a build for the ppa. The disadvantage is if something breaks the build - but this can't, because it's completely runtime.

I'd honestly prefer using libretro nowadays but i have some requirements they don't satisfy (mt32, voodoo, the 8gb hd patch, a Copy-on-write VFS layer or at least a way to *invoke* the one i have before starting games on the core, using my conf files onions instead of ineffectually starting execs, deleting some trash after running the core i place on the linux ramdisk for windows 95/98).

@Serious Callers Only, please feel free to include it. You way also want to look at doing a small patch to remove the aspect ratio adjustment that is currently being done when creating the surface, as this tends to reduce the available screen area that is usable by the shader. Though this would also prevent the code being as modular as you were describing.

I believe the code for this is in sdlmain.cpp in the GFX_SetupSurfaceScaled function, where the height and width of sdl.clip are adjusted, but I haven't had a chance to test this properly yet.

Hello everyone!

I have found something strange in dosbox-EXE (acutally it is the same in the original dosbox)
I am wondering if it is a bug or a feature that I do not know of.

Phenomenon:
I boot up the dosbox and type for example:
config -set "mididevice = fluidsynth"

It accepts the command without any problem.
However if I set a path let's say
path c:\games

After running the same command gets an error message:
config -set "mididevice = fluidsynth"
Illegal command: config.

Does it a normal behavior?

The config command is stored on Z:\. If you change the path variable and remove Z:\ then 'config' cannot be found.

@DosFreak: Thank you, that makes sense. So I just need to add Z:\ to the path and I am good to go.

Is the latest version of DOSBOX ECE 32 bit, or 64? I remember seeing HUGE gains in game performance (frame rate) when I switched from 64 bit to 32 bit DOSBOX.

igermi wrote on 2020-04-18, 00:17:

Is the latest version of DOSBOX ECE 32 bit, or 64? I remember seeing HUGE gains in game performance (frame rate) when I switched from 64 bit to 32 bit DOSBOX.

ECE is and always was 32 bit, as is the official one.

I think the lower perf on x86-64 was corrected with the new 64-bit dynamic core?

Yes, it's actually marginally faster as long as he builds it with DYNAMIC_X86 and not DYNREC

Is yesterplay 's blog okay? Http certificate expired or something ?