Arbitrary Horizontal Resolution for Cropping in on GBI 360p Optimized Modes

[ケイ | Cae]

The Line2x 240×360 and Line3x 240×360 modes seem to add black bars to the left and right of the image so that the horizontal output resolution is always 1280 (in 2x) or 1920 (in 3x). I’m sure the reason for this is to achieve easier display compatibility by generating something as close as possible to a standard 720p or 1080p signal. This creates a slight problem for me, however, as I’d like to make the actual game image as large as I can by cropping out the unused lines, even at the cost of some slight interpolation (added by the display’s upscale). Adjusting V.active and V.backporch works just as I’d hope for the vertical axis, but because these modes add black bars to reach a horizontal of 1280 or 1920, the result on my monitor is a skinny aspect ratio (the monitor is 16:9 and will scale anything wider than 16:9 to fill the screen on both axes, but skinnier aspect ratios can be displayed in a square-pixel aspect ratio).

I would like to be able to optionally force the horizontal resolution output in the 360p optimized modes to match the H.active value times 4 (for line2x) or times 6 (for line3x), similar to how the 240p Line2x and Line4x optimized modes work. With the settings currently available on the OSSC, the only way I can crop in on the GBI’s 360p image while maintaining the correct aspect ratio is to use one of the generic modes, which actually compares quite favorably to the optimized modes in this instance, but is not entirely ideal since the rightmost column of pixels appears to be half as wide as it should be, which the optimized modes can correct for with a properly set sampling phase. I’d just like to be able to do that without shrinking or distorting the image relative to the quasi-“optimized” generic sampling I have dialed in.

[Author]

Posts

[ケイ | Cae]

The Line2x 240×360 and Line3x 240×360 modes seem to add black bars to the left and right of the image so that the horizontal output resolution is always 1280 (in 2x) or 1920 (in 3x). I’m sure the reason for this is to achieve easier display compatibility by generating something as close as possible to a standard 720p or 1080p signal. This creates a slight problem for me, however, as I’d like to make the actual game image as large as I can by cropping out the unused lines, even at the cost of some slight interpolation (added by the display’s upscale). Adjusting V.active and V.backporch works just as I’d hope for the vertical axis, but because these modes add black bars to reach a horizontal of 1280 or 1920, the result on my monitor is a skinny aspect ratio (the monitor is 16:9 and will scale anything wider than 16:9 to fill the screen on both axes, but skinnier aspect ratios can be displayed in a square-pixel aspect ratio).

I would like to be able to optionally force the horizontal resolution output in the 360p optimized modes to match the H.active value times 4 (for line2x) or times 6 (for line3x), similar to how the 240p Line2x and Line4x optimized modes work. With the settings currently available on the OSSC, the only way I can crop in on the GBI’s 360p image while maintaining the correct aspect ratio is to use one of the generic modes, which actually compares quite favorably to the optimized modes in this instance, but is not entirely ideal since the rightmost column of pixels appears to be half as wide as it should be, which the optimized modes can correct for with a properly set sampling phase. I’d just like to be able to do that without shrinking or distorting the image relative to the quasi-“optimized” generic sampling I have dialed in.

[Author]

Posts