Reading the github issue, it's understandable why it got removed.

If discussion on this functionality for this other project needs to occur do it elsewhere (preferably not vogons), this thread is for DOSBox ECE.

KainXVIII wrote on 2023-09-12, 12:45:

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

Both your screenshots are truly pixel-perfect, with 2x2 square pixels and no apsect-ratio correction. The original resolutions are 640x400 for the first and 640x480 for the second screenshot. The first one has PAR of 1.2 (5:6) and should aspect-corrected if the output resolution permits, which in you case it does not. I am glad the pixel-perfect shader works at least in this situation, but the reliance on the GPU for so simple a thing as pixel-perfect scaling seriously raises the requirements for a DOSBox machine... I should like to see the pixel-perfect shader at work with a 320x200 program on a 1650x1050 display, where it should figure out to use 4:5 scaling, because 5:6 will not fit.

DosFreak, I bet your pardon for replying—didn't see your post.

Thanks very much for ECE! I think it was the most widely used DOSBox variant in retro sim racing circles. I just read that it's development has come to an end, which is sad, but luckily there are alternatives. Question is though if Staging does everything that ECE did feature-wise.

so i haven't quite given up getting ece working under win9x. awhile back i tried compiling with mingw and got a working ece build, but could never get fluidsynth working. well, i found a libfluidsynth v1.1.6 dll with glib dependencies stripped out and it works under win98se!

so if you take the last couple ece releases (r4482, r4481) and replace the sdl, sdl_net libraries with those from the vanilla dosbox v0.74-3 release plus the no-glib libfluidsynth.dll you get a working win9x dosbox ece.

however, there's something wrong with the built-in mt32emu library compiled in the last few releases of dosbox ece. for some reason it uses way too many cpu cycles. my 1.7ghz athlon cpu strains and barely keeps up. i used the ece r4481 source and compiled in my own v2.7.0 mt32emu library and the resulting build uses a third less (maybe even half the) cycles. i don't know what is going on.

i'm thinking i still have to compile my own dosbox ece. libfluidsynth will be impossible with anything less than visual studio 2008. maybe i can transplant the headers and libraries back into mingw afterwards or figure out how to do it all in vs2008 for win9x.

morphinejh wrote on 2023-02-25, 14:44:

Well that's actually good news. And I have good news too. I got my Windows 98 box setup and ran into the same issues you did. I don't have an easy way to compile for Windows 98, but I know libglib has older binaries that do work on windows 98. I don't know the newest version that will work, but I know this version will work:
...
Hope it helps! More research coudl be done to find the absolute newest verison that would work. Or possibly a new build targeting Windows 98.

i tested all versions and glib v2.12-13 is the last release that will work under win98se.
https://download.gnome.org/binaries/win32/gli … lib-2.12.13.zip
https://gnuwin32.sourceforge.net/downlinks/li … onv-bin-zip.php

so if you replace the sdl, sdl_net libraries and the libglib, libgthread dlls plus add the renamed v1.9.2-1 iconv.dll you will also have a working dosbox ece under win9x. (same issue with mt32emu cpu usage still applies.)

i wonder if libfluidsynth v1.1.6 was still being used in r4482 or if it had been advanced past that long before. i'd much rather use a glib stripped fluidsynth, but v2 made quite a few advancements if it's been included in recent releases of dosbox ece. i believe the major motivation of fluidlite was getting rid of the complications of glib so good riddance...

here is my complete compilation of dosbox ece for win98. everything is compiled in mingw except for libfluidsynth v1.1.6 where i used mingw-w64 and then transferred the headers and libraries back to mingw. i tested the build in win98se with athlon 1.7ghz and pentium3 850mhz systems and as far as i can tell all the patches are working. i expect my build will probably work with later versions of win95 as well, but i haven't tested. opengl did not work on the pentium3, but i expect this was because the video card drivers on that system didn't support higher than opengl v1.2. mt32emu (munt) uses about a third less cycles than the official dosbox ece build and you'll need a system north of 1ghz for smooth playback.

Is there anyway to display the video mode information in the status window? Staging and X both do this by default and it's immensely helpful in debugging and setting video modes. Or if not in real time, then can I have all that resolution switching/setting info saved in a debug file or something?

Thanks

@stanwebber: Great work and thanks very much for also sharing the result! What's the performance like on the two systems you mentioned as your test beds. Does a trusty old P3 850 manage to run mid-90s SVGA DOS games or only older ones (up to which point roughly) and how does the Athlon 1.7 manage those? Btw I lately ran DOSBox Staging on a current Linux OS running on an old 2.3 GHz C2D with onboard Intel GMA4500 graphics and at least on that platform DOSBox OpenGL was so slow that you needed to disable it anyway.

General question: Normal DOSBox ECE will run on Windows XP, doesn't it?

@7F20: Having dealt with that Linux C2D system mentioned a few lines above this one I can tell you that a lot is/can already be logged into a DOSBox log-file. At least on DOSBox Staging that's the case but I'd expect other DOSBoxes to do the same.

villeneuve wrote on 2023-12-12, 13:56:

@stanwebber: Great work and thanks very much for also sharing the result! What's the performance like on the two systems you mentioned as your test beds. Does a trusty old P3 850 manage to run mid-90s SVGA DOS games or only older ones (up to which point roughly) and how does the Athlon 1.7 manage those? Btw I lately ran DOSBox Staging on a current Linux OS running on an old 2.3 GHz C2D with onboard Intel GMA4500 graphics and at least on that platform DOSBox OpenGL was so slow that you needed to disable it anyway.

General question: Normal DOSBox ECE will run on Windows XP, doesn't it?

the athlon 1.7ghz system has a radeon 9800 pro so it can handle pretty much anything into the xp era (plus i can run it at 5-2-2 ram timings). either my or sergm's win9x compilation of munt + dosbox pegs the cpu at about 66% (official ece 100%).

the p3 850mhz system has a rage mobility m1 so it does ok running mid 90's svga games with fluidsynth enabled so long as it is a modest sized soundfont. munt is a no-go which is disappointing as i think 800mhz was given as the min requirement (maybe for the xp & later build).

i also run dosbox-x on a mid-era c2d laptop, but it has an upgraded nvidia videocard so it runs fine (although ubuntu dropped the proprietary nvidia drivers covering my card from the latest kernels so i have to go third party)

normal dosbox ece runs on xp without any modification.

Thanks for your answers! I didn't imagine that Munt would be the most taxing part, I thought SVGA graphics would already stress such old CPUs too much.