stanwebber wrote on 2023-02-25, 15:45:

i have cmake, mingw and vs2005 build environments that can target win98, but compiling even the oldest ver 1 build of fluidsynth i could find on sourceforge was a no-go. it would require fairly recent build tools manipulated to target win98 which i don't know is even possible anymore.

until recently, there weren't even winxp or non-sse2 precompiled binaries of any fluidsynth builds. a little bird had to go and request them.

With the glib libraries I link to in the previous post, I could successfully use the fluidsynth library that is provided with DosboxECE. It may just be a targeted build for libglib that is needed.

I've done a little more playing around with it too. DirectDraw and OpenGL don't seem to work for me, just surface render. MT-32 and Fluidsynth both work using the older glib.

Edit: This post is referencing using DosboxECE on Windows 98 Second Edition.

fluidsynth is a black, black hole. i just wasted another afternoon trying to get v1.1.2/11 to compile under mingw and vs2005. for starters, glib-2.16 is the minimum required version which is too new for win98. that's not so much a problem as the dsound.h header it wants. i've tried both directx 8 & 9 sdk headers modified for mingw, but apparently they're not new enough or who knows. for a solely command-line utility, fluidsynth has some asinine requirements.

dosbox ece actually compiles just fine for win98 without fluidsynth. i think i got it successfully built under mingw with all the remaining patches intact. attached is a binary for anyone who wants to investigate. it's useless to me unless it has some form of gm wavetable patch.

edit: if you have mouse issues in the application window with the svn build, replace the external dll libraries with ones from the official 0.74-3 build.

Hello, I use Dosbox-ECE (latest version) to play Screamer 2 and when I launch it the sound is noisy.

At start I have error messages about jack server and alsa....

1DOSBox version ECE
2Copyright 2002-2021 DOSBox Team, published under GNU GPL.
3---
4CONFIG: Loading primary settings from config file dosbox-test.conf
5Memory sizes above 31 MB are NOT recommended.
6Stick with the default values unless you are absolutely certain.
7ALSA:Can't subscribe to MIDI port (65:0) nor (17:0)
8MT32: Control ROM file not found
9ALSA lib pcm_dsnoop.c:566:(snd_pcm_dsnoop_open) unable to open slave
10ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
11ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
12ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
13ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
14Cannot connect to server socket err = No such file or directory
15Cannot connect to server request channel
16jack server is not running or cannot be started
17JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
18JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
19Cannot connect to server socket err = No such file or directory
20Cannot connect to server request channel
21jack server is not running or cannot be started
22JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
23JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
24ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
25ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
26ALSA lib pcm_a52.c:1001:(_snd_pcm_a52_open) a52 is only for playback
27ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
28ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'
29ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
30ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'
31ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
32Cannot connect to server socket err = No such file or directory
33Cannot connect to server request channel
34jack server is not running or cannot be started
35JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
36JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
37MIDI:fluidsynth: no soundfont loaded
38MIDI: Opened device:fluidsynth
39fluidsynth: warning: Failed to set thread to high priority
40Glide:LFB access: read-write
41INFO: This app is looking for CD-ROM drives, but no path was specified
42INFO: Set the SDL12COMPAT_FAKE_CDROM_PATH environment variable to a directory
43INFO: of MP3 files named trackXX.mp3 where XX is a track number in two digits
44INFO: from 01 to 99
45Glide:Activated
46Glide:Resolution:640x480, LFB at 0x60000000 (physical) / 0x60000000 (linear)

I don't use jack server nor alsa but Pulseaudio.

If I disable midi, no more noisy sound.
I can not reproduce this issue with dosbox svn (compiled on my system).

my config:
OS: Manjaro 22.0.5 Sikaris
Kernel: x86_64 Linux 6.2.7-2-MANJARO
CPU: AMD Ryzen 9 5900HX with Radeon Graphics @ 16x 3.3GHz
GPU: AMD Radeon RX 6600M (navi23, LLVM 15.0.7, DRM 3.49, 6.2.7-2-MANJARO)
Video drivers: Mesa 22.3.5

legluondunet wrote on 2023-03-25, 13:50:

Hello, I use Dosbox-ECE (latest version) to play Screamer 2 and when I launch it the sound is noisy. […]
Show full quote

Hello, I use Dosbox-ECE (latest version) to play Screamer 2 and when I launch it the sound is noisy.

At start I have error messages about jack server and alsa....

Copy code to clipboard

1DOSBox version ECE
2Copyright 2002-2021 DOSBox Team, published under GNU GPL.
3---
4CONFIG: Loading primary settings from config file dosbox-test.conf

...

What are the contents of your dosbox-test.conf? (specifically the midi section) Pulsaudio is a mixer that outputs to ALSA. So it is technically used.

Totally guessing without context, but I'd bet he issue is around Fluidsynth. I have had similar issues before. But need to see your config file setup.

EDIT:
Further, check out section 4.1 below, it has helped me in the past.
https://wiki.archlinux.org/title/PulseAudio/Troubleshooting

Thanks, I will make some tests.
Another things:
It could be interesting to post dosbox-ece code and releases on Github.
I found this Github page but it is not updated since july 2022:
https://github.com/realnc/dosbox-ece
AppImage will be a very interesting package format too for Linux users.

legluondunet wrote on 2023-05-04, 13:11:

I found this Github page but it is not updated since july 2022:
https://github.com/realnc/dosbox-ece
AppImage will be a very interesting package format too for Linux users.

It's now updated to r4482.

Any plans for dx11+ support as a option yesterplay?

latest reshade binaries have a AutoHDR addon support at their forums but sadly they are vulkan and DX11+ only

End of life for DOSBox ECE
As you may have noticed, development of DOSBox got somewhat... slow in the recent past. And since DOSBox ECE is based on the SVN of the official DOSBox releases, of course there weren't (m)any new releases of that as well. I must admit, that I wasn't too sorry about the lack of updates. In the last years, the amount of free time shrank to almost nothing anyway and other builds emerged or got better, that IMHO made ECE pretty redundant.

So, as of now, I decided to stop releasing new builds of DOSBox ECE. Not without a tear in the eye, it was nice to have a somewhat popular build and to give something back to a great community! But as of now, I think we're all better off using the more up-to-date alternatives like DOSBox Staging, DOSBox-X or DOSBox Pure (if you're using Retroarch anyway).

Thanks for your support and feedback through the last seven years!

Thanks for your enormous effort of maintaining ECE through the years. As the first unofficial built to include my pixel-perfect patch, ECE helped make it available to more conneseurs of low-res pixel-art aesthetics, who were not satisfied with the blurry interpolation of the standard output modes.

Thanks, enjoy your retirement! I used your build few years ago because at the time I liked to have pixel perfect patch but I'm in DOSBox Staging camp now.

eM-!3 wrote on 2023-09-11, 15:15:

Thanks, enjoy your retirement! I used your build few years ago because at the time I liked to have pixel perfect patch but I'm in DOSBox Staging camp now.

As are probably most former ECE users now. 😉

Yesterplay80 wrote on 2023-09-11, 09:35:

End of life for DOSBox ECE As you may have noticed, development of DOSBox got somewhat... slow in the recent past. And since DOS […]
Show full quote

End of life for DOSBox ECE
As you may have noticed, development of DOSBox got somewhat... slow in the recent past. And since DOSBox ECE is based on the SVN of the official DOSBox releases, of course there weren't (m)any new releases of that as well. I must admit, that I wasn't too sorry about the lack of updates. In the last years, the amount of free time shrank to almost nothing anyway and other builds emerged or got better, that IMHO made ECE pretty redundant.

So, as of now, I decided to stop releasing new builds of DOSBox ECE. Not without a tear in the eye, it was nice to have a somewhat popular build and to give something back to a great community! But as of now, I think we're all better off using the more up-to-date alternatives like DOSBox Staging, DOSBox-X or DOSBox Pure (if you're using Retroarch anyway).

Thanks for your support and feedback through the last seven years!

Thank you for all you have done!

eM-!3 wrote on 2023-09-11, 15:15:

I used your build few years ago because at the time I liked to have pixel perfect patch but I'm in DOSBox Staging camp now.

They have burned pixel-perfect mode at the stake, replacing it with blurry vertical-only and horisontal-only interger scaling modes, so that the Staging project has no output mode with sharp and regular pixels anymore.

Ant_222 wrote on 2023-09-12, 08:30:

eM-!3 wrote on 2023-09-11, 15:15:

I used your build few years ago because at the time I liked to have pixel perfect patch but I'm in DOSBox Staging camp now.

They have burned pixel-perfect mode at the stake, replacing it with blurry vertical-only and horisontal-only interger scaling modes, so that the Staging project has no output mode with sharp and regular pixels anymore.

Is it possible to achieve the same result with pixel shaders? (there is one that i used, ported from https://tanalin.com/en/articles/integer-scaling/ )

KainXVIII wrote on 2023-09-12, 08:35:

Is it possible to achieve the same result with pixel shaders? (there is one that i used, ported from https://tanalin.com/en/articles/integer-scaling/ )

Hardly possible without some preparatory calculations on the CPU to find the best PAR approximation in terms of aspect-ratio error and usage of the screen estate. I should be glad to be wrong, though. DOSBox shaders not working on my old PC with Windows XP, I cannot test them now. Thanks for the link. If you have any screenshots of Marat's shaders in action, please share them so that I may make certain they are truly pixel-perfect.

Update: One problem with such abstract shaders is that they have insufficient information. They do not have the PAR (pixel aspect ratio) of the emulated videomode, not the values of the double-height and double-width flags in DOSBox. There are games, for example, that are formally 320x400, but are in fact 320x200, and scaler must treat 1:2 rectangles as entire pixels and never break them. The pixel-perfect mode had that logic in it.

It is extremely simple to write a vertex shader that will ensure the output window is scaled by integer multiples only.

I created such a shader a while ago: pixel_perfect.glsl. I'm not sure if it works with the latest SVN versions of DOSBox as I haven't tested it in a while.

The source looks good. Have you sample screenshots online demostrating the pixel-perfect upscaling of 5:6 PAR DOS games and programs (text-modes are a good test of pixel-perfect)?

tyrells wrote on 2023-09-12, 09:58:

I created such a shader a while ago: pixel_perfect.glsl. I'm not sure if it works with the latest SVN versions of DOSBox as I haven't tested it in a while.

Yeah, i meant your pixel perfect shader in previous post 😋

Ant_222 wrote on 2023-09-12, 08:30:

eM-!3 wrote on 2023-09-11, 15:15:

I used your build few years ago because at the time I liked to have pixel perfect patch but I'm in DOSBox Staging camp now.

They have burned pixel-perfect mode at the stake, replacing it with blurry vertical-only and horisontal-only interger scaling modes, so that the Staging project has no output mode with sharp and regular pixels anymore.

I know they went to war with pixel perfect on github but I stopped using it by myself when I switched to Staging. OpenGL output + sharp glshader is good enough for me. Anyway thanks for your great patch!