You are not logged in.
Compare the left window in these images:
[1:1] https://i.imgur.com/dTF1A7Y.png
[1.5:0.5] https://i.imgur.com/AqsFLFs.png
The second image appears much blurrier.
It seems the "main" window gets crushed down a pixel (measured window sizes using ShareX)
Is there any way to fix this?
Offline
I just nudged it around to fix the 1 pixel crush in the horizontal case you are using. The code is still bad, and I should not have merged it. The sub window size is nuts, it works out to a division by 3 so you don't get anything exact until you scale the overall window by a multiple of 3x.
Offline
Ah, interesting!
Does this mean the issue is now fixed in the most recent release? (my apologies if it was implied - not the best at getting implications)
Wait, nevermind - I just checked, and the most recent autocompile change mentions my issue exactly!
Thank you for the rapid action.
I've noticed some strange behavior in Dragon Quest IX when loading textboxes, but I'll create a separate topic for that if that interests you.
Last edited by Smerg_the_Dargon (2021-02-05 23:00:27)
Offline
There's still some fucky behavior, but the screen-crush is definitely gone.
Also, been meaning to ask - why no 1:0.5 (2:1) ratio? Do the values have to add up to 2 due to how it's coded?
Perhaps a "enter desired ratio" option?
Last edited by Smerg_the_Dargon (2021-02-05 23:19:09)
Offline
Wait, nope - bad news.
Screencrush is still there.
4x window with 1.5:0.5 ratio results in the main window being 1023 wide - disabling "Maintain Aspect Ratio" turned it to 1024, but with the obvious downside of stretching the second window.
4x window with 1.2:0.8 ratio results in the main window being 1022 wide - disabling "Maintain Aspect Ratio" turned it to 1023.
Last edited by Smerg_the_Dargon (2021-02-05 23:38:42)
Offline
The code is garbage. It can't be fixed, it won't be fixed. It is a total loss without rewriting. If I wanted to spend the time to fix it, I could spend half that time rewriting it. And If I wanted to spend even that much time doing it, I would have done it instead of merging someone else's broken code. Sorry. Give up.
The problem is that the window is sized in total ignorance of the requirements of sizing the sub-windows. It needs to be redone in terms of choosing sensible sizes for the sub windows (and I am not sure these ratios are ever sensible sizes) and then summing those to create the window size. It's working backwardsly now.
put a bug on github and I may fix it one day. or maybe not. who knows? You might write a report on the state of the art in windspro or whatever is that old desmume wrapper, x432r, melonds, retroarch, nocash, etc. to show what options they have and assess their pros and cons. One of the problems with this code is it was never thought through fully, I think. If it's so important, someone should think it properly. I don't see why it can't be expressed in terms of a simple sub window ratio (always 1.0 or less) and then have the main window always be 1.0 scale and the sub window be something smaller.
- why no 1:0.5 (2:1) ratio? Do the values have to add up to 2 due to how it's coded? <-- yes.
- Perhaps a "enter desired ratio" option? <-- because of above. And also because with fixed options there is at least the hope of all the cases being worked out by hand to result in numbers that don't suck. Unfortunately, 500% of the code involved in sizing windows and laying them out is garbage (that's right, there's 5 times as much as there should be, and it's 100% garbage)
Offline
Yeesh - I'd help if I could, but I don't have the slightest clue about coding such things.
Offline