GS Mode Selector: Development & Feedback

[dlanor]

I thought DH would of had the same effect as DW because for example, HDL runs at 512x448 so when run at 1080i, it has borders on all sides of the screen.

If I increase DW, the width is stretched much like you can manipulate the width on a PC monitor and I can eliminate the borders on the sides completely but as I said earlier, DH doesn't increase the size of the screen height at all, rather it shifts the screen up or down like the DY function. I'm not looking to completely eliminate the borders, rather I am looking to reduce them.

DH and DW do function in very similar ways, but the effect of the rez adaption algorithm confuses the issue here.

If you start changing DH or DW, for example you can pass a size where you reach another precize multiple of the rez requested by the game, and then the borders can vanish. But if you increased the value beyond the physical borders of the screen you instead lose visibility of some part of the game screen. And if you decreased the value to less than the visibile screen, then that will create a black border of its own.

There is no 'gradual stretching' of the picture scaling for small changes of either DH or DW, since the only scale adaption we can make is done by changing the MAGH and MAGV magnification factor integers. And since they are integers, fractional scaling is impossible.

It can't be a limitation of the GS chip at 1080i because Gran Turismo 4's 1080i mode fills MOST but albeit not all of the height of the screen, certainly more than the GS program.

That is because the game has a 'native' 1080i mode, meaning that the game is working directly with a frame buffer dimensioned for that purpose, and can fill as much or as little of it as it pleases. When both the game (or other main program) and the GS chip agree on using a specific rez, then that rez can always be used without any borders.

But in this project we are normally forced to deal with a framebuffer holding data suitable for direct display in 640x448 or thereabouts (640x512 for PAL), and the only way we can adapt that to 1080i or another enforced video mode is by integer multiplication. The 1920 widht of 1080i allows for perfect integral magnification of 640 pixels by the factor 3, so DH will be perfect. But 1080/448 is appx 2.41, while 1080/512 is appx 2.11, so the truncated integer factor is 2, using only 896 or 1024 of the 1080 lines, with the remainder being black borders.

Best regards: dlanor

[Vegeta]

The 1920 widht of 1080i allows for perfect integral magnification of 640 pixels by the factor 3, so DH will be perfect. But 1080/448 is appx 2.41, while 1080/512 is appx 2.11, so the truncated integer factor is 2, using only 896 or 1024 of the 1080 lines, with the remainder being black borders.

Best regards: dlanor

Yep, I understand that but as is, GSModeSelector looks to be displaying at 1920x448 for me when 1080i mode is selected so the top and bottom borders are HUGE.

Can a higher DEFAULT not be added into the source so 1080i mode defaults to setting the screen resolution at 1920x896 for a 640x448 resolution?

If GSM defaulted to 1920x896 which would result in minimal borders at the top and bottom, I wouldn't have bothered mentioning it in the first place as I know perfect scaling with no borders is not possible unless you compromise and manipulate the overscan settings on your TV.

The picture posted in an earlier post by urbigbro explains the size of the borders I am seeing at 1080i clearly:

[doctorxyz]

Hi,

Post #192 updated
http://www.psx-scene.com/forums/show...&postcount=192

That's all for today, folks!

BR,

[urbigbro]

Thanks docxyz! I'll test the latest release over the next few days.

I'm sure other devs will appreciate the documentation and commenting. (EP has already expressed an interest in this project.) The docs should make the learning process much quicker for new devs.

May I suggest one other thing to make it easier for developers, and testers alike to help out with this project.

Update the first post of the thread with the newest release (perhaps my preconfigured FMCB-uLE-GSM files too) and findings that are appropriate to do a general summary of what this project is about and what stage of development it is in.
It may even be beneficial to get the mods to change the thread title to more appropriately state what this project has turned into. GS Video mode selector or something similar, since it will now work for disc based games, and homebrew.

I'm really glad this project has progressed as far as it has. Many other devs will be able to reuse this code, much like they have done for dlanor's additions to uLE.

In a perfect world, ffgriever (or whoever ends up doing it) could merge the GS mode selection into the ESR, HD project, and PS1 emulator. Ragnarock may also be able to use this stuff in his NES, and SNES emulators, as well as the "PS2 Dashboard" program he's been working on.

Whatever amount of participation you can donate is appreciated.

[dlanor]

Yep, I understand that but as is, GSModeSelector looks to be displaying at 1920x448 for me when 1080i mode is selected so the top and bottom borders are HUGE.

That does sound wrong, but there are reasons.
You say 448 because it looks about that high to you, but it is probably 896, as the highest magnification factor that can be used for 448 is 2, without exceeding the 1080i limit.


Btw: Which precise version of the GSModeSelector program are you talking about ?

Can a higher DEFAULT not be added into the source so 1080i mode defaults to setting the screen resolution at 1920x896 for a 640x448 resolution?

I'm not sure how you mean that, but there is no way to stretch the 896 pixels to fill the screen. regardless of what we set the values too, that resolution can not be rendered to fill a 1080i screen without borders, when we are limited to integer factors.

if we increase the DH value to be larger than the number of visible rows in 1080i resolution, then we may get problems when a program sets a resolution that can be scaled to that 'fake' size by an integer factor. The adaption routine will then use that scale factor causing only a part of the intended screen to be visible.

We can't just use dummy values that might work for a single case, as that will get us into trouble for other cases.

But in a future application we could consider having per-game settings, which may then be as specific as you wish, since they only need to work with one game. But even that can never eliminate all the black borders. without also losing some game display area.

Assume we were to fake DH so as to trick the program into using a scale factor of 3, resulting in (and requiring a DH value of) 1344 raster lines, of which we would somehow have to get rid of 264, so as to have only 1080 displayed. This can not be done perfectly as negative values are not valid for DY, but we can at least reduce that to zero. Whichever way we do this centering, a total of 264 raster lines generated from framebuffer data will be lost, most of it at the bottom of the screen, and with a factor of 3 this represents 88 pixel rows. The standard DY value for 1080i is 48, which represents 16 pixels, so we end up losing 16 pixel rows at top and 72 pixel rows at the bottom, and the latter is likely to make many games unplayable.

A better method may be to simply use the features of your TV more efficiently. For example, my Panasonic has lots of settings for screen aspect ratio and zooming, and some of those are very good with some games in 'enforced' 1080i mode.

If GSM defaulted to 1920x896 which would result in minimal borders at the top and bottom, I wouldn't have bothered mentioning it in the first place as I know perfect scaling with no borders is not possible unless you compromise and manipulate the overscan settings on your TV.

The picture posted in an earlier post by urbigbro explains the size of the borders I am seeing at 1080i clearly:

If that picture really shows the full 1080 screen, then the 'game-used' part of that screen is definitely higher than 448, so it probably is 896 already. I find it hard to judge exactly where the physical screen borders are from that picture, except the bottom part which seems clear (I assume it is the TV control panel we see there, with a row of buttons). But in the screen area of that picture the area with the red background occupies a lot more than half the total height, so I don't see why you say that it is 448. It can't be.

The borders do look bigger than they should be, but not big enough to account for 632 raster lines.

Best regards: dlanor

[dlanor]

Hi,

Post #192 updated
http://www.psx-scene.com/forums/show...&postcount=192

That's all for today, folks!

I have now downloaded your v0.18, and will base future contributions on that then (or newer if your release more).

Best regards: dlanor

[urbigbro]

The picture posted in an earlier post by urbigbro explains the size of the borders I am seeing at 1080i clearly:

The images I posted were in regards to the grey borders that I see in 720p. Are those supposed to be there on purpose, or is it some kind of screen garbage? I only have that one display to test 720p on ATM, so maybe it's my monitor?

[Vegeta]

The images I posted were in regards to the grey borders that I see in 720p. Are those supposed to be there on purpose, or is it some kind of screen garbage? I only have that one display to test 720p on ATM, so maybe it's my monitor?

I know your image was taken with 720p resolution on a monitor but it was the only one I could use as an example of the way games were displaying in 1080i for me on my Plasma HDTV.

That does sound wrong, but there are reasons.
You say 448 because it looks about that high to you, but it is probably 896, as the highest magnification factor that can be used for 448 is 2, without exceeding the 1080i limit.


Btw: Which precise version of the GSModeSelector program are you talking about ?

I was talking about GSModeSelector v0.17/GSTest v1.01 but 0.18 is the same too. BTW, the picture used to be perfectly centered by default in GSTest v1.01 in 1080i and 720p but in GSTest v1.02 the picture isn't centered perfectly by default, it is shifted to the right and down a bit.

If that picture really shows the full 1080 screen, then the 'game-used' part of that screen is definitely higher than 448, so it probably is 896 already. I find it hard to judge exactly where the physical screen borders are from that picture, except the bottom part which seems clear (I assume it is the TV control panel we see there, with a row of buttons). But in the screen area of that picture the area with the red background occupies a lot more than half the total height, so I don't see why you say that it is 448. It can't be.

The borders do look bigger than they should be, but not big enough to account for 632 raster lines.

I did mention the resolution "looks to be displaying at 1920x448" but after drawing the resolution in paint, it is most certainly a figure inbetween 1920x448 and 1920x896 but it isn't 448 as that is too small.

See the attached image below. The black borders represent 896 height, the green borders represent a height of 448 and the red line is an approximation of where I believe the game area ends for me and the borders start so it is some way off 896 pixels but more than 448 pixels.

[zin0099]

wow i got ragnorak2040's nes to run in 480p but under the options menu make sure you have the interlace mode on!

tested with the new v18 version great release

[doctorxyz]

Update the first post of the thread with the newest release (perhaps my preconfigured FMCB-uLE-GSM files too) and findings that are appropriate to do a general summary of what this project is about and what stage of development it is in.
It may even be beneficial to get the mods to change the thread title to more appropriately state what this project has turned into. GS Video mode selector or something similar, since it will now work for disc based games, and homebrew.

It would be great. I will make it ASAP ok!