I've downloaded your v0.23d beta release and will check it out later and go through all the source changes. But I'm not sure yet when I can be done with this, so I can't promise a release package today.
As for now I'll only comment on one of your changes:
We've had this in the program before, so it does work, but the main reason why it works is that very few programs ever use DISPLAY1 and DISPLAY2 for different purposes at the same time (which is the real reason why both registers exist).Quote:
- Every time one DISPLAYx is trapped, both ones (DISPLAY2 and DISPLAY1) are written.
However, for those cases where the registers are used as Sony intended, our screen adaption method might not apply at all. (Like when using DISPLAY2 to overlay a smaller image on top of the one generated by DISPLAY1). So the point may be moot, with both methods being equally incorrect for those cases.
The main reason why I removed this doubled register patching before, was so as to maintain a one-to-one relationship between the register patching attempted by the game program and the register patching performed by our program. So we may change a value before using it for a register, but we always send it to the same register, and not to any other. But with your method we will take a value intended for one register, and not only modify it but also write it to another register.
This will definitely force DISPLAY1 and DISPLAY2 positioning and scaling to be identical, which is not how they are really intended to be used. Both the scaling and positioning are intended to be separate, to allow advanced methods of overlay mixing.
But like I said above, much of the point is moot anyway, since our scaling method has no choice but to assume that each DISPLAYx rectangle represents the entire screen (right or wrong) so we always scale it to fill the available resolution as well as possible.
This difference in our assumed usage of these registers to always represent a full screen and Sony's intended usage of also using it for smaller overlays is probably responsible for some of the cases of oddly scaled objects on screen, though there are other reasons too.
The above is not intended to argue either for or against the 'doubled' register patching, but merely to remind you of some further complexities of DISPLAYx register usage that we have ignored so far. (Some of which it would be very hard for us to deal properly with...)
You can find some of the details on this subject in the CRTC chapter of the GSUSER PDF, and make sure not to miss page 83, which is one of the crucial pages without a bookmark of its own, so you have to scroll into it. This shows how the outputs from the two rectangle circuits are mixed into the final output.
Best regards: dlanor