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...