DosFreak wrote:My response to the article:
If DOSBox only supported D3D9+ and Windows 10, The latest MacOS for Metal, and OpenGL 3 on the lates […]
Show full quote
leileilol wrote:On the backend-side, now SDL2 is getting a SDL1.2 wrapper (SDL1.2 API -> SDL2)
https://www.patreon.com/posts/project-sdl12-25321792
DOSBox's resistance to the "upgrade" is what mainly inspired it though 🤣 but also the old rotting Loki ports.
My response to the article:
If DOSBox only supported D3D9+ and Windows 10, The latest MacOS for Metal, and OpenGL 3 on the latest ver of Linux then there wouldn't be any issue but DOSBox can run on alot more than that (Awesome!) but SDL2 cannot. Obviously that can't go on forever or can it?! but the nice thing is the code is there so we can have DOSBox with SDL 1.2 and DOSBox with SDL2 so not sure why people are crying so much except of course for there being no official ver of DOSBox with SDL2 as of yet. The SDL2 devs shouldn't have been so lazy in the first place. I wonder how long SDL2 will support Windows XP? Wouldn't it be ridiculous if you couldn't run DOSBox on that? 90% of the Internet: "Nah, that shit is old just throw it in the trash"
"One of the other benefits in modernizing applications is that old, software-rendered games now get pushed to the GPU."
About that... I've had issues with SDL2 programs that don't render compared to their SDL1.2 versions so that's not necessarily a positive.. Video driver issue most certainly but nothing I can do about it.
Still waiting for the bitching and moaning about not being able to run Windows XP inside DOSBox. I'm sure that's coming.
Or 64-bit binaries since some platforms (eg MacOS X, Win10)
Considering that there's been SDL2 builds of DOSBOX for years ( DosBox-0.74-ES (SDL2) ), the resistance to updating, or at least making build switches for it seems equally as lazy. With SDL 2.0.9 they finally solved a problem that was created out of the SDL dev's own laziness, render batching ( https://www.phoronix.com/scan.php?page=news_i … Batching-System ) . That was seven months ago. Previous builds of DOSBOX 0.74 with SDL2 function fine under 4K monitors but suffer under SDL 1.2 because of changes that hit cpu-bound limits in software rendering. (see ECE build's pp patch.) I don't think render batching would speed anything up with DOSBOX because all emulators that I'm aware of treat the emulated "screen" as a software surface anyway, and that's a small source of render lag. So it might be worth benchmarking those patches again.
A 1.2 wrapper for 2, just creates an additional source of latency. The smart thing that they should have done in the first place would have been to rip the bandaid off, and put the build switches in SDL to support or not support the 1.2 API and depreciated things like the real CD audio/playback controls. That way if a dev really wants to support an old feature that new machines do not have, they have to build the SDL2 library with that functionality. Rather than the reverse situation where software built against 1.2 is suffering from severe bitrot, and playing on HiDPI screens requires tinkering with application compatibility and GPU driver settings.
DOSBOX should not feature bloat into supporting hardware that is best addressed with Virtualbox/VMWare/QEMU/XEN. Hell, it really should not have been enabled to run any version of Windows at all. Win 3.1/3.11/95/95OSR2/98/98SE/ME should have been addressed by the WINE project. Really it's the 3DFX support in an unofficial patch that drives Win95 demand. Anything else that works is a bonus. In fact you can leverage DOSBOX with the Fluidsynth support to add a "software synth" as "hardware" to the Win95 environment, and not have the processing penality you would if you installed something like s-yxg50 in it. since you could have FluidSynth use a patch bank that is larger than system ram.