On my own HDTV set it is not possible for "FFX Int" to completely fill out the screen in any video mode. Not even in the original NTSC mode without using GSM at all. And in NTSC mode with and without GSM the picture is identical (as it should be) except that GSM allows me to recenter the picture, which is all I use GSM for with FFX.
Originally Posted by Cory
And in the real HDTV modes we get weird side effects of some kind from some GS register control specific to this game, preventing full control.
Some people actually think it does look good in that video mode, but I agree with you that the borders produced in that mode are too large.
According to the chart of compatible games, FFX was reported as "looks great in 1080i!" So I would imagine its possible.
But unlike what you seem to think this is not because the size or scale is miscalculated, but simply because the gamecode by Square-Enix also fiddles with the GS registers in such a way that we do not have full control.
To some extent such effects are unavoidable, due to the integer factor limit.
To me the problem seems more about the positioning, rather than adjusting the size. As I said every time I increase the resolution it increases the top and left padding. When I try to lower it, the picture resolution gets lower too. And it seems to be an endless cycle.
NB: Some of the effects described below only partly relate to FFX, since it also affects those effects in other ways, not normal for other games.
If a game needs a logical resolution 448 pixels high (standard for all NTSC games) then it should fit perfectly within a physical screen of 448p. This means that in any physical mode with physical height of 895 lines or less the scale is forced to 1, leaving a physical border of phys_height-448 which is distributed evenly using half each at top and bottom.
But when the physical height set reaches 896, it is finally possible to use the next integer factor of 2 without losing any logical pixels outside the displayable range. So within a physical screen 896 pixels high an NTSC screen should be perfectly scaled by a factor of 2, but as we continue to raise the resolution we are again forced to distribute the excess phys_height-896 lines as top and bottom borders. We should again get a perfect quotient at 1344 pixels height, except that this is outside the range for normal HDTV modes.
So for ALL modes GSM is limited to using vertical factors of only 1 or 2 for such games.
For low-rez games using 224 pixels more factors are available in the range 1 through r.
And of course the latter are still limited to the integers 1, 2, 3, 4. No fractions are possible.
Similar rules apply to the horizontal axis, except that the variation are greater as the basic unit for horizontal work is not a pixel, but a Vck unit, whose relationship to pixel width varies for different video modes. In normal PAL/NTSC there are 4 Vck units per pixel, and for higher resolutions and HSync rates the number goes down (in integer units of course).
Both DX and DW use Vck units, and the real width in pixels represented by DW is therefore (DW+1)/(MAGH+1) . In case you didn't know it, MAGH and MAGV are both coded as the real factor minus one, while DH and DW are both coded as the real size minus one, because those are the forms in which the GS chip requires the numbers.
That is only because the preset GS values for both PAL and NTSC modes were chosen so as to produce good centering according to PAL and NTSC standards.
Wouldn't it be possible for the image to auto center on the screen? I would think so. Since it does by default without this hack anyways.
For the video modes set by GSM it is the responsibility of GSM to ensure centering, which it attempts to do by placing the start of the useful picture such that the unused border areas are dictributed equally for top VS bottom and for left VS right edges. But that is of course relative to the base offsets for DX and DY that you chose in the GSM GUI.
Sure, why not ? But I'm going to reply myself anyway.
Would like to hear xyz's input on this.
That would give you an understanding only of the vast possibilies and freedom in design using modern software for those areas. But no understanding of the hardware limitations of a specific graphic synthesizer chip implementation like the GS.
Its like trying to explain brain surgery to someone with limited medical background. I have no experience with coding for PS2 hacks and mod, though I do graphic design and web development coding. So I have some understanding.
Let me rephrase that in a more definite way. I know for a fact that many things I would like this hardware to be able to do are in fact impossible.
The only thing that you seem to not understand is anything is possible.
A statement like "anything is possible" can only be true in a very generic way, assuming full freedom in what means to choose for accomplishing those results. And that is exactly what we do not have in designing software for specific hardware. Here we are limited to the available hardware components and the abilities (both intended and such as are available by unplanned methods) which they have potential for as used by programmable software.
And unfortunately that is VERY far from 'anything is possible'...
In a way you might say so, but then the 'way' must also include the possibility of complete replacement of the limiting hardware for something else. And then we are no longer talking about PS2 programming.
Its just a matter of finding a way.
No, I disagree, both on your evaluation of my 'approach' and as to its consequences. But to gain technological advancement people frequently have to abandon old hardware in favour of new hardware without the inherent limitations of the older. And that is exactly what has happened as a major part of technological development, since the dawn of time.
If everyone took this approach then technology would still be very primitive. ;)
Given a specific hardware only a limited set of improvements can be made in how you use it, and going beyond those limits requires that the hardware itself be replaced or improved. And improvement of the PS2 hardware is obviously not a practical approach. (Theoretically possible, but not practical.)
So I don't see how these principles can be used for making better software for the PS2, as abandoning the hardware that now limits us would mean that we are no longer making it for the PS2.
Do you realize how bold a statement you just made ?
If your editing the games resolution yes. But how your hack works and how it wouldn't effect resources at all is by using magnification.
You just said that complete rescaling of logical screen data to fit any physical size screen can be done without costing any RAM or CPU time, even though I have already told you that the GS chip can ONLY do this if the magnification factor is a whole integer.
And how pray tell am I to do that then ?
All you need to do is magnify to a size that fits the screen.
Consider for a moment just the case you wanted earlier, of a 448 pixel logical game screen perfectly filling a 1080i picture height. (Doesn't matter if we assume full height or the appx 1030 I really get on my HDTV.) How do we do this by telling the GS chip to multiply the height with an integer factor, which is all we know how to do...
No. The bitfields we currently use for that in some GS registers are only interpreted as integer factors. There is no way to enter a fraction anywhere.
Same way you do it now.
I agree that the menu screen is messy, due to trying to cram too much information into it. To remedy that we really should add some info popups instead.
I would just re-look at your current systems controls. They seem to be confusing and don't work that well.
And I also agree that the gamepad response could be better, though we have a problem with this in that it needs to work right with many different video interrupt rates, which complicates matters. (Suitable button press debouncing etc.)
I'm not mad at all, just slightly exasperated by your refusal to take any limitations seriously. But you need to believe me when I say that in the real world, dealing with real equipment , it is just not true that 'anything is possible'. All equipment has real limitations, and if we fail to understand those limitations we also fail to control that equipment in optimal ways.
No need to get mad.
Then tell me not just that it is so, but how it is so.
Just because you don't know how to do it doesn't mean it isn't possible. It clearly is.
No, you're not, though I believe you are sincere in thinking so.
Since all I'm suggesting is using the same concept your currently using and optimizing it to just work better.
When you tell me to scale 448p so that it perfectly fills a 1080i screen, which normally has a visible range anywhere between 1020-1080 (depending on brand, model and trimming), what you are really asking me to do is to somehow scale the picture by a factor anywhere in the range from appx 2.27 through appx 2.41, which clearly requires fractional scaling of a kind the GS chip does not to our knowledge support.
The register bit fields where we currently encode the magnification factors are pure integer fields without any room for fractional parts. So if any method is possible at all for achieving fractional scaling, it certainly does NOT use the same registers we use today.
I naturally think I do understand, but let's go through it again then...
I'm starting to doubt you understand what I am suggesting.
Yes, I got that already.
WHAT IM NOT SUGGESTING: Editing the resolution that the game out puts.
No in-game resources that is.
WHAT I AM SUGGESTING: Using a easier to use system of magnification like the current system you are using. The game is still outputting the same resolution, no extra resources used what-so-ever.
But the magnification itself can only be done resource-free for integer factors, as I have explained repeatedly (apparently without success in convincing you).
I don't think I was being rude.
No need to get rude.
It is you who refuse to believe that I am speaking the truth when I repeatedly inform you of a technical limitation that the GS chip most definitely has, in allowing only integer factors for the magnification bitfields (both MAGH and MAGV) in the DISPLAY1 and DISPLAY2 registers. In fact a lot of people would consider such refusal to believe in a quoted technical specification to be rather rude in itself, implying that I would have some reason to lie about it.
If/when someone finds out how to do fractional GS scaling, no one will be happier about that than I, but if at all possible it certainly can not be done by any small modification of our present methods, as they are integer-only.
Once again just because YOU don't know how to do something doesn't mean it cannot be done.
And the only chances I see for fractional scaling myself apply only to the horizontal axis where two potential possibilities exist, still unexplored. One is the possibility of modifying the base frequency of the Video clock (the Vck mentioned above) through some control register, which would effectively change all video timing (but with possible HSync complications). And the other is the widescreen control that some games clearly can use without affecting vertical timing. This could allow limited fractional scaling by 4/3 or 3/4, and despite its limitations, that too could be useful for some cases. (Better than no fractions at all anyway.)
Now your memory seems to be going...;)
Must be my imagination. Thought my television had a zoom mode that zooms in vertically by 20%. Guess it was my imagination. :)
It was I who adviced you a few days ago that you should check to see if the zoom modes of your TV might not improve things a bit. Which I suppose it might, as zooming in by 20% could give excellent results for a picture where the 'lost' 20% are unwanted border areas...
But that is outside of the scope of GSM programming, as we have no control over what zoom options each TV set may have, which differs both among brands and among models.
I'm familiar with the saying, but that is another one which is true only if we assume no limitations in the ways that we seek.
Where there's a will, there's a way.
But in seeking a satisfactory solution for specific use of a specific piece of hardware, our solutions must take into account its limitations.
Best regards: dlanor