|
I'm beginning to understand users' frustration with video options
#350585 - 02/23/16 04:26 PM
|
|
|
So just as a basic sanity check, I decided to run Chelnov. It's an interesting use case - namely that it runs at 256x240, which means it has non-square pixels when displayed on its 4:3 monitor. I figured I would take a screenshot to get a good baseline.
I ran MAME with -window -video gdi -r 256x240, expecting to be given a window with a 256x240 client rectangle, and exact pixels displayed in there. What I got was this:
A 272x230 window with a 256x192 client rectangle.
That makes a certain amount of sense. By default, keepaspect is turned on, so it's trying to constrain Chelnov's non-4:3 resolution to a 4:3 resolution, so it selects 256x192 instead for the client rectangle size based on my -r 256x240.
However, when I try adding -nokeepaspect into the mix, all fuck breaks loose:
The window itself is 256x240. It looks like with -nokeepaspect, suddenly the resolution specified by -r is interpreted as the window size rather than the client rectangle size! What the hell?
It's interesting to note that SDL does not have this issue with resolutions, though it does spawn windows that are offscreen, which means you can't move them. This is with -nokeepaspect, I get a 256x240 client rectangle, as expected:
And if I specify -keepaspect, I get a 256x240 client rectangle, as requested by -r 256x240, but the image is downsized to 256x192 and letterboxed, as expected:
So, this pretty much backs up what R. Belmont has been saying, which is that SDL builds of MAME already get this behavior correct, and it's D3D and BGFX that are the odd ones out.
Anyway, back to the salt mines. Hopefully I can make Windows behave the same way as SDL, minus the offscreen window border.
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: MooglyGuy]
#350591 - 02/23/16 05:56 PM
|
|
|
> The window itself is 256x240. It looks like with -nokeepaspect, suddenly the
> resolution specified by -r is interpreted as the window size rather than the client
> rectangle size! What the hell?
That's certainly a problem but it's a separate issue, not the fullscreen case.
Chelnov will look ok in full screen mode even with D3D, provided you use an exact resolution of 256x240. This is because MAME reports 256x240 as its native resolution already.
The problem happens if a game has less active lines, say 224, like Toki. Now if you make it run at 256x240 full screen, D3D won't leave the required borders. SDL will, with -nounevenstretch.
Certainly SDL has the proper scaling code. My suggestion is to move the functionality in SDL into the core renderer, so all current and future backends can grab it from there. This is how I have it in GroovyMAME, so BGFX already has integer scaling out of the box.
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: Calamity]
#350592 - 02/23/16 06:03 PM
|
|
|
That's what I'm already doing. Aside from taking GroovyMAME code.
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: MooglyGuy]
#350598 - 02/23/16 06:56 PM
|
|
|
I dont think, that this is a MAME problem. It is a Windows OS problem. I have the same issues with at least two other programs, including my frontend.
Stupid thing from Windows is, that it adds the frame of the windows, including borders, icons, titlebar etc.
so if you specify a windows size, you would assume, you get exactly that, but you get a windows size that fits your specified size including the additional framing stuff from Windows OS. Very annoying for example if you do theme-ing, skinning of a program and you expect that the window is really 800x600 for example. In reality you end up with a smaller size, because of the framing of the window itself.
Hope you can follow, but i cant describe it better.
PS: i think the only solution, would be a complete borderless window, so that there are no elements that could skrew the intended size.
Edited by uman (02/23/16 07:05 PM)
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: uman]
#350600 - 02/23/16 07:36 PM
|
|
|
> I dont think, that this is a MAME problem. It is a Windows OS problem. I have the
> same issues with at least two other programs, including my frontend.
>
> Stupid thing from Windows is, that it adds the frame of the windows, including
> borders, icons, titlebar etc.
>
> so if you specify a windows size, you would assume, you get exactly that, but you get
> a windows size that fits your specified size including the additional framing stuff
> from Windows OS. Very annoying for example if you do theme-ing, skinning of a program
> and you expect that the window is really 800x600 for example. In reality you end up
> with a smaller size, because of the framing of the window itself.
>
> Hope you can follow, but i cant describe it better.
>
> PS: i think the only solution, would be a complete borderless window, so that there
> are no elements that could skrew the intended size.
Almost none of that is correct. Windows has an API for getting the total width and height added by window decorations, this is purely a bug in the Windows OSD code in MAME. If you have the same problem with other applications, that just means they're written badly.
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: MooglyGuy]
#350601 - 02/23/16 07:44 PM
|
|
|
> Almost none of that is correct. Windows has an API for getting the total width and
> height added by window decorations, this is purely a bug in the Windows OSD code in
> MAME. If you have the same problem with other applications, that just means they're
> written badly.
Either that, or the programs where written at a time, where such problems didnt exists  .
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9711
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: uman]
#350603 - 02/23/16 08:53 PM
|
|
|
> Either that, or the programs where written at a time, where such problems didnt
> exists .
That problem existed before Win32; it was also the case in Win16, which had identical APIs for getting the real client area.
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: Calamity]
#350605 - 02/23/16 09:35 PM
|
|
|
> > The window itself is 256x240. It looks like with -nokeepaspect, suddenly the
> > resolution specified by -r is interpreted as the window size rather than the client
> > rectangle size! What the hell?
>
> That's certainly a problem but it's a separate issue, not the fullscreen case.
>
> Chelnov will look ok in full screen mode even with D3D, provided you use an exact
> resolution of 256x240. This is because MAME reports 256x240 as its native resolution
> already.
>
> The problem happens if a game has less active lines, say 224, like Toki. Now if you
> make it run at 256x240 full screen, D3D won't leave the required borders. SDL will,
> with -nounevenstretch.
>
> Certainly SDL has the proper scaling code. My suggestion is to move the functionality
> in SDL into the core renderer, so all current and future backends can grab it from
> there. This is how I have it in GroovyMAME, so BGFX already has integer scaling out
> of the box.
Can you clarify one thing? You mention SDL behaving a given way with -nounevenstretch. Can you get me a screenshot of what the result would look like if you specified a resolution that wasn't an integer multiple of either the width or the height?
|
|
|
|
|
> Can you clarify one thing? You mention SDL behaving a given way with
> -nounevenstretch. Can you get me a screenshot of what the result would look like if
> you specified a resolution that wasn't an integer multiple of either the width or the
> height?
Only low resolution available in my laptop is 320x240. So I've chosen Golden Axe which is 320x224.
sdlmame64 goldnaxe -resolution 320x240 -switchres -nokeepaspect -nofilter -nounevenstretch
Notice MAME removes the borders when taking a snapshot with F12, so the resulting .png is 320x224. But I swear there are two nice black borders on my screen (obviously this resolution looks like crap on an LCD with all its internal scaling going on, but it's cristal clear on a CRT).
[ATTACHED IMAGE]
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: Calamity]
#350610 - 02/23/16 11:14 PM
|
|
|
> > Can you clarify one thing? You mention SDL behaving a given way with
> > -nounevenstretch. Can you get me a screenshot of what the result would look like if
> > you specified a resolution that wasn't an integer multiple of either the width or
> the
> > height?
>
> Only low resolution available in my laptop is 320x240. So I've chosen Golden Axe
> which is 320x224.
>
> sdlmame64 goldnaxe -resolution 320x240 -switchres -nokeepaspect -nofilter
> -nounevenstretch
>
> Notice MAME removes the borders when taking a snapshot with F12, so the resulting
> .png is 320x224. But I swear there are two nice black borders on my screen (obviously
> this resolution looks like crap on an LCD with all its internal scaling going on, but
> it's cristal clear on a CRT).
Does it look any different if you don't specify -nounevenstretch? If so, how?
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: Calamity]
#350611 - 02/23/16 11:22 PM
|
|
|
> > Can you clarify one thing? You mention SDL behaving a given way with
> > -nounevenstretch. Can you get me a screenshot of what the result would look like if
> > you specified a resolution that wasn't an integer multiple of either the width or
> the
> > height?
>
> Only low resolution available in my laptop is 320x240. So I've chosen Golden Axe
> which is 320x224.
>
> sdlmame64 goldnaxe -resolution 320x240 -switchres -nokeepaspect -nofilter
> -nounevenstretch
>
> Notice MAME removes the borders when taking a snapshot with F12, so the resulting
> .png is 320x224. But I swear there are two nice black borders on my screen (obviously
> this resolution looks like crap on an LCD with all its internal scaling going on, but
> it's cristal clear on a CRT).
Humor me, what happens if you run it with -resolution 800x600 -switchres -nokeepaspect -nofilter -nounevenstretch? And with -unevenstretch?
I'm asking so that I can re-create this behavior on Windows.
|
|
|
|
|
> Does it look any different if you don't specify -nounevenstretch? If so, how?
Yes. I've switched to windowed mode so I can capture the thing.
This is with unevenstretch, notice it's stretching the height to 240.
[ATTACHED IMAGE]
|
|
|
|
|
This is with nounevenstretch, borders are left as required.
[ATTACHED IMAGE]
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: Calamity]
#350615 - 02/23/16 11:27 PM
|
|
|
> This is with nounevenstretch, borders are left as required.
Would you be alright with me just selectively merging portions of GroovyMAME into the main source tree in order to get this going in the D3D and BGFX renderers?
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: MooglyGuy]
#350616 - 02/23/16 11:35 PM
|
|
|
> Would you be alright with me just selectively merging portions of GroovyMAME into the
> main source tree in order to get this going in the D3D and BGFX renderers?
Sure.
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: Calamity]
#350618 - 02/24/16 12:36 AM
|
|
|
> This is with nounevenstretch, borders are left as required.
What about with -unevenstretch, and what about with -r 800x600? I'm interested in what you get if you hit the PrtScr key and paste it into MS Paint, not what F12 gives.
|
|
|
|
|
> > This is with nounevenstretch, borders are left as required.
>
> What about with -unevenstretch, and what about with -r 800x600? I'm interested in
> what you get if you hit the PrtScr key and paste it into MS Paint, not what F12
> gives.
I can only PrtScr on windowed mode, otherwise all I get is the desktop background.
sdlmame64 goldnaxe -r 800x600 -switchres -nokeepaspect -nofilter -unevenstretch
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
|
|
|
|
sdlmame64 goldnaxe -r 800x600 -switchres -nokeepaspect -nofilter -nounevenstretch
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: Calamity]
#350624 - 02/24/16 02:16 AM
|
|
|
> sdlmame64 goldnaxe -r 800x600 -switchres -nokeepaspect -nofilter -nounevenstretch
Interesting. We're getting somewhere.
Can you please sync to the latest code in the MAME github repository, and tell me what the behavior is for this post and the other one now, using the Windows OSD, not the SDL OSD? On my machine, they both seem to display the same resolution when fullscreen regardless of -nounevenstretch, I just want to make sure you're getting the same behavior so I can start fixing it.
Also, please PM me if there's an easier way to get ahold of you than posting on here. Like, say, IRC or Skype.
|
|
|
|
Urgh.
[Re: Calamity]
#350631 - 02/24/16 07:36 AM
|
|
|
> > Would you be alright with me just selectively merging portions of GroovyMAME into
> the
> > main source tree in order to get this going in the D3D and BGFX renderers?
>
> Sure.
In that case, I'm going to put aside trying to fix -nounevenstretch in time for the release in a few hours. Once the release of 0.171 hits, you can update GroovyMAME for 0.171, and then we can look at merging GroovyMAME into the master branch.
|
|
|
|
Re: I'm beginning to understand users' frustration with video options
[Re: MooglyGuy]
#350634 - 02/24/16 10:36 AM
|
|
|
> Can you please sync to the latest code in the MAME github repository,
Sorry, it was late night here, just saw your post now.
> Also, please PM me if there's an easier way to get ahold of you than posting on here.
> Like, say, IRC or Skype.
I couldn't PM you the other day, seems to be disabled for your account here. You can use this email:
calamity15khz at gmail dot com
|
|
|
Index 
Threaded 
I'm beginning to understand users' frustration with video options
Reply
[Re: 
.
