Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
There's not a lot of hard information out there, so I made a few guesses. If anyone has better, I'd love to hear it, because I couldn't find it anywhere. Fact: PSX GPU has a 53.203 MHz reference clock Source: http://www.mediafire.com/?zbp2bhb4y117xp7 Fact: PSX GPU has 240 and 480 line heights, and 256/320/384/512/640 line widths Source: http://www.horningabout.com/jimb/psx/gpu.txt Fact: The NTSC square pixel clock (single height) is 12,306,394Hz. Source: http://lipas.uwasa.fi/~f76998/video/conversion/ Guess: Dot clocks are integer dividers off the reference clock. Justification: It would be simple and easy to implement. Guess: Dot clock dividers were chosen to give screen aspect ratios of approximately 4:3 with the usual vertical overscan (approximately 448 of 480 lines visible). Justification: There'd be no reason to have lots of overscanned horizontal pixels; developers wouldn't be able to use them. A large underscan would also mean useless black pillarboxes on most TVs. If you accept all of these assumptions, the results are easy to calculate:
Base CLK = 53.203MHz

W   Divider PAR (240p)  DAR (H=224)
256    10     1.157       1.322
320     8     0.925       1.322
384     7     0.810       1.388
512     5     0.578       1.322
640     4     0.463       1.322
For 480i resolutions, you just double the pixel AR. Then you use that pixel AR with whatever actual width/height the engine requested to get the display AR. Example: 256x240 has AR=1.234 Note that the extra width of the 384 resolution (5% more than the others) can easily be observed in practice. There's additional evidence supporting these dividers in the PS2: It has access to the same video resolutions, and the MAGH register values correspond to these dividers exactly. Without more understanding of how the clock select works though, it's not proof of anything.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Wouldn't it be easier for encoders to just dump at 640x480, knowing that a game can switch graphics modes at any time? Especially if the result is going to be YV12. (width stretched to 640, height doubled if not interlaced, then padded to 480 if necessary)
Publisher
Joined: 4/23/2009
Posts: 1283
great research natt! Though I don't know how to apply to our current method. creaothceann, we are doing a lot of YUV444 recently, so the color loss is less now.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Yeah but YT doesn't, afaik. :)
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
great research natt! Though I don't know how to apply to our current method. creaothceann, we are doing a lot of YUV444 recently, so the color loss is less now.
Well, I think the current method is a good one; the "primary resolution" of the game is chosen as the resolution to encode to, with other resolutions being squeezed to fit. There would just be different aspect ratios used in some cases. For example, I just downloaded the encode for Symphony of the Night (Richter Path), and it's at 256x240 (the resolution that most of the game runs at, but is given a display AR tag of 1.333. My data would indicate that a display AR tag of 1.234 would better resemble how it played on the original system. (As a bonus, it seems to agree better with the clock face a few rooms before shaft, looks like a circle now).
Publisher
Joined: 4/23/2009
Posts: 1283
Ah, I see what you mean now.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Another usage example: http://tasvideos.org/forum/viewtopic.php?p=273784#273784 So with 4 resolutions 640x480 ("disc switch" screens, etc) 368x216 (menu) 320x224 (normal gameplay) 320x216 (battle) To fit everything with no downsizing, the final encode has to be at least 640x480. If you encode at 640x480 and use DAR = 1.234, you get the following processes: 640x480->640x480 (leave as is) 320x224->640x448 (point resize 2x) 320x216->640x432 (point resize 2x) 368x216->644x216 (1.75x (width), 2x (height), crop 4 pixels width) On the other hand, if you want to do a square pixel encode this is one possible way to do it: 1184x960, square pixels 640x480->1184x960 (1.85x w, 2x h) 320x224->1184x896 (3.7x w, 4x h) 320x216->1184x864 (3.7x w, 4x h) 368x216->1191.4x864 (3.2375w, 4x h, crop 7.4 pixels width)