VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 1020 of 1164, by RodanLewarx

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 1021 of 1164, by MT_

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

Reply 1023 of 1164, by Yesterplay80

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

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

Reply 1024 of 1164, by tyrells

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

Reply 1025 of 1164, by MT_

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

Last edited by MT_ on 2020-03-23, 22:56. Edited 2 times in total.

Reply 1026 of 1164, by MT_

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

Reply 1027 of 1164, by Yesterplay80

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

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

Reply 1028 of 1164, by _Rob

User metadata
Rank Member
Rank
Member

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

Reply 1029 of 1164, by tyrells

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

Reply 1030 of 1164, by Serious Callers Only

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

Reply 1031 of 1164, by tyrells

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

Reply 1032 of 1164, by csico

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 1033 of 1164, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 1036 of 1164, by Yesterplay80

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

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