Views: 336,183 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 01-21-19 11:47 PM

0 users reading "Sub-par" results when using hi-dpi on Windows | 1 bot

Main - Compatibility / Testing - "Sub-par" results when using hi-dpi on Windows New reply

Rin Tohsaka
Posted on 07-14-18 05:30 PM Link | #630
I have my HTPC set to 200% DPI scaling on Windows 7 SP1, and it turns out that melonDS will still have screen filtering even if I disable the setting in melonDS.

(click to view full-size)

Even worse though is that, if I enlarge melonDS's program window a bit, the scaling will look really bad for things like text even if the program window is something quite high-res relative to the DS's native resolution such as 562x843.

(click to view full-size)

I believe that there's actually two steps of scaling occurring whereby the 200% DPI scaling is completely unknown to melonDS, so it treats a game window of 512x768 the same way that it would treat 256x384. Therefore, when enlarging the program window a bit to something like 562x843, melonDS actually sees it as 281x422 and scales that without filtering, and then after that an additional 200% filtered scaling is applied. Therefore, it's no wonder that things like text look so crappy as melonDS is really only scaling by 1.098x rather than the expected 2.195x.

Now normally you could work-around such issues by using the "disable DPI scaling" option in Windows which, while it'd make everything tiny, should make everything "just work". However, using that with melonDS then results in the following disaster.

(click to view full-size)

And the real kicker is that melonDS treats the touch screen as being in the black area, so you have to basically guess where to touch.

Also, resizing the program window doesn't fix the issue either (though I can at least confirm that disabling the DPI scaling does seem to work around the "two-step scaling with filtering" issue mentioned above).

(click to view full-size)

Posted on 07-14-18 05:38 PM (rev. 2 of 07-14-18 05:38 PM) Link | #631
that's pretty much it. melonDS is not hiDPI aware, so the window contents are being drawn at the regular resolution and shittily upscaled+filtered by Windows (you can notice the menubar is getting filtered too).

I have to wonder what the hell the 'disable hiDPI scaling' setting is doing that leads to that result, too.

see, that's why I just stopped using hiDPI on my machine despite having a compatible screen-- it's not worth the trouble given how bad Windows is at it. I don't see how the 'disable hiDPI' setting could lead to such a fucking trainwreck, and yet, they did it. Linux was better but still not worth it.

might work on it eventually, but... yeah. making melonDS hiDPI aware would help, but then I'd have to take it into account everywhere. or maybe I can just make libui handle it transparently.

oh well.


Rin Tohsaka
(post deleted) #632

Rin Tohsaka
Posted on 07-14-18 08:41 PM (rev. 5 of 07-14-18 08:46 PM) Link | #633
EDIT: Apologies for the delete & re-post, but I didn't want to double-post either, so I kind of "merged" both the previous post as well as what would have been a new post into a single post.

Unfortunately for me the computer in question is an HTPC connected to a 39" 1080p TV that is typically viewed from about 3 meters/10 feet away, so having my desktop at 1080p without DPI scaling would be horribly impractical (this is in fact the same HTPC I alluded to in the comments of your most recent melonDS blogpost that I wanted to use for psuedo split-screen).

Yes I could lower the actual resolution like I used to do when it was using a ~11 year old Intel iGPU that was too slow to handle 1080p fullscreen video playback smoothly in a browser (even if the actual video was only 360p), but that situation of somewhat blurry text due to the upscaling isn't exactly something I'd be keen to go back to, especially since I'm now using a Radeon 5850 and therefore the performance issues with 1080p fullscreen video playback are completely solved even with actual 1080p video.

Anyway, wouldn't an easy better-than-nothing kind of "cheaty" solution be to simply have melonDS report to the OS that the program is hi-dpi aware but then actually do absolutely nothing at all, thereby resulting in a completely unscaled window? I believe this is what current versions of non-MP XnView do as well as what older versions of VLC and MPC-HC did as well.

Sure the text in the interface will be tiny, but that's arguably better than the alternative considering that 99.99% of the time you'll be looking at the game window, not the interface.

Oh and BTW, there seems to be a forum bug with avatars in that it will slightly downsize your avatar if it's 200px wide, but this doesn't occur if you use 199px wide instead (however this issue doesn't seem to occur with avatars that are 200px in height only).

Main - Compatibility / Testing - "Sub-par" results when using hi-dpi on Windows New reply

Page rendered in 0.015 seconds. (2048KB of memory used)
MySQL - queries: 29, rows: 82/82, time: 0.010 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.