Reply 40 of 67, by kjliew
Dominus wrote on 2021-07-18, 12:08:Can you elaborate how that problem manifests itself? I don't quite understand...
Step #1 Get a game called Dune 2: Building of a Dynasty (1992) by Westwood Studio
Step #2 Use an expensive 27" 4K/8K panel (... quietly weep) so *Display Scaling* becomes inevitable unless one was genetically modified to have the eye sight of eagle. Or, use a MacBook with retina screen. (... quietly weep)
Step #3 Play the game in *windowed*. Scale the window however one likes, with windowresolution or scaler={whatever}3x
Step #4 Have fun with the Game!
Dominus wrote on 2021-07-18, 12:08:IMO, my OpenGL fix is better if the hardcoded scaling value can be obtained programmatically.
but it's already in SDL git so this needs to be fixed instead of doing it per program, IMO. Maybe voice in in the bug report https://github.com/libsdl-org/SDL-1.2/issues/839 ?
That's why it's called SDL git. 😉 There is no per-program fix in DOSBox. It is an inherent problem when one just scaled display without mouse motion in-sync. Apparently, DOSBox already has some logics to keep display and mouse motion in-sync with its own scaling when SDL didn't mess up. That's why my OpenGL fix worked. If SDL is doing transparent scaling, then it must deal with both display and mouse motion.