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.
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.Quote:
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.
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