Talk:XMB Layouts: Difference between revisions
| (9 intermediate revisions by the same user not shown) | |||
| Line 150: | Line 150: | ||
From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule<br> | From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule<br> | ||
All the unique XMB "grid" references above, combined in a single list | All the unique 4.89 XMB "grid" layout references above, combined in a single list | ||
Line 3374 // Loaded by eula_cddb_plugin.sprx | Line 3374 // Loaded by eula_cddb_plugin.sprx | ||
Line 3375 // Loaded by eula_cddb_plugin.sprx | Line 3375 // Loaded by eula_cddb_plugin.sprx | ||
| Line 172: | Line 172: | ||
Line 4351 // Loaded by eula_hcopy_plugin.rco | Line 4351 // Loaded by eula_hcopy_plugin.rco | ||
Line 4353 // Loaded by eula_hcopy_plugin.rco | Line 4353 // Loaded by eula_hcopy_plugin.rco | ||
*eula_net_plugin.rco doesnt contains any reference to the XMB layouts, and eula_net_plugin.sprx contains 10 values located over line 4255 of the XMB grid layout files | |||
=VSH exports= | |||
*This exports seems to be used to get the position and sizes located in the "XMB layouts" .txt files | |||
**paf::PhWidget::GetLayoutPos(int &, int &, int &, vec4 &)const | |||
**paf::PhWidget::GetLayoutPosValue(void) | |||
**paf::PhWidget::GetLayoutSize(int &, int &, int &, vec4 &)const | |||
**paf::PhWidget::GetLayoutSizeValue(void) | |||
*This ones to set them | |||
**paf::PhWidget::SetLayoutPos(int, int, int, vec4) | |||
**paf::PhWidget::SetLayoutSize(int, int, int, vec4) | |||
*And this ones to redraw them | |||
**paf::PhWidget::UpdateLayoutPos(void) | |||
**paf::PhWidget::UpdateLayoutSize(void) | |||
=Video Output Settings= | |||
https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html | |||
The screen at step 7 of the "PlayStation 3 User's Guide" shows all this posible strings (copyed from inside sysconf_plugin.rco) | |||
<source lang="xml"> | |||
<Text name="msg_480p">480p</Text> | |||
<Text name="msg_576p">576p</Text> | |||
<Text name="msg_720p">720p</Text> | |||
<Text name="msg_1080i">1080i</Text> | |||
<Text name="msg_1080p">1080p</Text> | |||
<Text name="msg_720p_3d">720p (3D)</Text> | |||
<Text name="msg_1080i_3d">1080i (3D)</Text> | |||
<Text name="msg_1080p_3d">1080p (3D)</Text> | |||
<Text name="msg_720p_dual_view">720p (SimulView™)</Text> | |||
<Text name="msg_sd_ntsc">Standard (NTSC)</Text> | |||
<Text name="msg_sd_pal">Standard (PAL)</Text> | |||
<Text name="msg_select_all_resolution">Select all resolutions that are supported by your TV.</Text> | |||
</source> | |||
The description "Standard (NTSC)" and "Standard (PAL)" coud be confusing for someone (me included), but this paragraph from the user's guide indicates '''Standard (NTSC) is 480i''', and '''Standard (PAL) is 576i''' | |||
The video resolution is selected in order of priority as follows: 1080p > 1080i > 720p > 480p/576p > Standard (NTSC:480i/PAL:576i). | |||
So for clarification purposes this strings from inside sysconf_plugin.rco could be customized as: | |||
<source lang="xml"> | |||
<Text name="msg_sd_ntsc">480i (Standard NTSC)</Text> | |||
<Text name="msg_sd_pal">576i (Standard PAL)</Text> | |||
</source> | |||
==Coldboot script logic== | |||
Inside the coldboot.raf there is a [[Coldboot.raf#Script | script]] that detects the current display resolution, and based on it applyes some transformations (scale and position) to the coldboot logos. In it can be seen how the PS3 XMB groups the ED and SD resolutions together<br> | |||
The other video modes with a width different than 720 pixels doesnt falls into this "if-else" statements | |||
*The screen resolution detection logic starts with the statement <code>if (System.resolution->0 == 720)</code>. It seems this includes all this video modes: | |||
**576p and 576i (4:3 aspect ratio) '''720'''x576 (PAL anamorphic) | |||
**480p and 480i (3:2 aspect ratio) '''720'''×480 (NTSC anamorphic) | |||
*After that, the next logic stament is <code>if (camera.aspect == 4.0 / 3.0)</code>, this includes only: | |||
**576p and 576i ('''4:3''' aspect ratio) '''720'''x576 (PAL anamorphic) | |||
*Else is: | |||
**480p and 480i ('''3:2''' aspect ratio) '''720'''×480 (NTSC anamorphic) | |||
Latest revision as of 02:51, 11 March 2023
Discussion/Speculation[edit source]
Other images[edit source]
The "XMB cross" also known as "XMB cursor". Is a position located always in the same place, defined in lines 258 and 259 of layout_factor_table_1080.txt. By changing the values to -750 and 200 the result is the whole XMB is displaced to the left-top corner https://www.youtube.com/watch?v=Tet5QwvGvgg
-395 35
Safety Notes[edit source]
When making tests with this files keep in mind the safest ones are the modes your TV doesnt uses by default and/or remoteplay layouts because after a reboot the PS3 doesnt loads them (only loaded when enabling remote play from XMB, not at boot time)... also keep in mind that the other layouts should be common with the "recovery menu" and "service mode" display modes... and you can change your TV resolution in the options in XMB settings column, then return to default resolution with a button combo at boot time
Who is the owner ?[edit source]
The values stored inside the layout.txt files are loaded by the rco files, every rco file could have tenths of references to load several values from the layout.txt files, and usually (but not always) this values are stored consecutivelly inside the layout.txt files. As example custom_render_plugin.rco from firmwares 4.80~4.89 is storing 6 values located consecutivelly at line numbers 665, 666, 667, 668, 669, 670. And the firmware 4.89 was added 7 new values located at lines 2580, 2581, 2582, 2583, 2584, 2585, 2586 of the layout_grid.txt files
In other words... every rco stores his values consecutivelly in the layout.txt files, but this process is not fully confirmed because it depends of the "optimizations" used by the sony compiler enviroment, the point is... if there are several RCOXML Objects inside the rco that requires to store the same value, then the compiler "should" store it a single time in the layout.txt files and force all the RCOXML Objects to load the same value from the same line in the layout.txt files. This would be optimal to minimize the size of the layout.txt files (and as far i remember sony does it sometimes) but we are not sure how stricts they was with his own rules and if there are other exceptions or rules used in this optimization. As another example... this optimization could be made not only with a single rco file but with all them together (this way the layout.txt files should contain only "unique" values, without any repetition). As far i remember sony is not doing it but is technically posible
One way or the other (with optimizations or without them)... we can see the order of the values of the list depends of the order of the rco files configured in the official sony compiler enviroment
It seems the compiler have a list with the names of the rco files that are going to be compiled, and the location of his values stored in the layout.txt files depends of that list. The rco file order of that list is completly unknown but IS NOT AN ALPHABETICAL ORDER, as example the file audioplayer_plugin.rco from 4.89 (the first rco in alphabeticall order loading values from the layout.txt files) is storing his values around line numbers 1500 (and custom_render_plugin.rco at line numbers 665)
The only good thing of the rco changes made in 4.89 (being optimistic), is one of the rco files was updated (probably was added a couple of RCOXML Objects, so his size in bytes increased a bit) and that objects required to store 7 new values at line 2580 of the layout_grid.txt files causing a displacement of +7 units in all the layout.txt references inside all the other rco files (the RCOXML attributes labeled in this wiki as "overrideSomething") that was storing his values over line 2580 (the displacement) in the layout.txt files
We are 99.9% sure that all the other rco files that was updated in 4.89 was a consequence of that displacement in the layout.txt files (the hex values that indicates a line from the layout.txt files was added +7 units)
In other words, all the rco files updated in 4.89 are storing his values over line 2580 of the layout.txt files (and the other rco files not updated are storing his values before line 2580 in the layout.txt files), thats a rought identification of his location inside the layout.txt files but better this than nothing
XMB layout references inside SPRX files[edit source]
In between firmwares 4.88 and 4.89 sony made some minor changes to the XMB that required to update the source code of a couple of sprx files and the content of his associated rco files to add a couple of RCOXML Objects in them. The new RCOXML objects added for 4.89 required to store 7 new values at line 2580 (from a total of 4602 lines) in the XMB layout files. The new values added at an intermediate position of the XMB layout files caused a displacement of +7 units in all the references to the values located after line 2580 of the layout files. As a consequence of that displacement it was needed to update 76 sprx files and 43 rco files to increase in +7 units the XMB layout references inside them. See: 4.89 Changelog
The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the RCOXML Objects
The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner combos are... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB)... and... eula_cddb_plugin.sprx (29 KB) / eula_cddb_plugin.rco (125 KB)
The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the RCOXML Object name (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files)
The references to the XMB layouts in the xml file generated by rcomage are in little endian, to convert them to "human readable" needs to be splitted in 2 chunks of 2 bytes each, first chunk is the "grid" and second chunk is the "factor". In this sample it can be seen how all the references to the "grid" was increased in +7 units
In the "human readable" conversion for rco values im adding a +1 because in code the first line of a .txt file is line 0, but in a text editor the first line is 1... so im guessing is also neeed to do this +1 addition in the values from the sprx
XMB layout references in eula_hcopy_plugin.sprx 4.88 offset:0x1C7E = 0x0D3C <--- line number 3389 ? offset:0x2EFA = 0x0D3C <--- line number 3389 ?
XMB layout references in eula_hcopy_plugin.rco 4.88 0x3f0d0100 <--- line number 3392 0x400d0100 <--- line number 3393 0x410d0100 <--- line number 3394 0x420d0100 <--- line number 3395 0xf7100100 <--- line number 4344 0xf9100100 <--- line number 4346
<IList name="list_eula_start" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Button name="button_eula_start_ok" positionOverrideY="0x420d0100"> <IList name="list_sync_trophy" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Button name="button_sync_trophy_yes" positionOverrideX="0xf7100100" positionOverrideY="0x420d0100"> <Button name="button_sync_trophy_no" positionOverrideX="0xf9100100" positionOverrideY="0x420d0100">
XMB layout references in eula_hcopy_plugin.sprx 4.89 offset:0x1C7E = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x2EFA = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
XMB layout references in eula_hcopy_plugin.rco 4.89 0x460d0100 <--- line number 3399 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x470d0100 <--- line number 3400 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x480d0100 <--- line number 3401 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x490d0100 <--- line number 3402 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0xfe100100 <--- line number 4351 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x110100 <----- line number 4353 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
<IList name="list_eula_start" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Button name="button_eula_start_ok" positionOverrideY="0x490d0100"> <IList name="list_sync_trophy" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Button name="button_sync_trophy_yes" positionOverrideX="0xfe100100" positionOverrideY="0x490d0100"> <Button name="button_sync_trophy_no" positionOverrideX="0x110100" positionOverrideY="0x490d0100">
XMB layout references in eula_cddb_plugin.sprx 4.88 offset:0x3E5A = 0x0D3E <--- line number 3391 ? offset:0x421A = 0x0D3C <--- line number 3389 ? offset:0x5F66 = 0x0D27 <--- line number 3368 ? offset:0x5FB6 = 0x0D27 <--- line number 3368 ? offset:0x6206 = 0x0D26 <--- line number 3367 ? offset:0x624E = 0x0D26 <--- line number 3367 ? offset:0x630A = 0x0D26 <--- line number 3367 ? offset:0x634E = 0x0D26 <--- line number 3367 ? offset:0x9B92 = 0x0D26 <--- line number 3367 ? offset:0x9C0A = 0x0D26 <--- line number 3367 ? offset:0x9C82 = 0x0D26 <--- line number 3367 ? offset:0xADF2 = 0x0D3C <--- line number 3389 ?
XMB layout references in eula_cddb_plugin.rco 4.88 0x280d0100 <--- line number 3369 0x290d0100 <--- line number 3370 0x2a0d0100 <--- line number 3371 0x2b0d0100 <--- line number 3372 0x2c0d0100 <--- line number 3373 0x350d0100 <--- line number 3382 0x360d0100 <--- line number 3383 0x3f0d0100 <--- line number 3392 0x400d0100 <--- line number 3393 0x410d0100 <--- line number 3394 0x420d0100 <--- line number 3395
<Plane name="plane_eula_licensing_wizard_arrow_back" positionOverrideX="0x280d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_back" positionOverrideY="0x2a0d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <Plane name="plane_eula_licensing_wizard_arrow_next" positionOverrideX="0x290d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_next" positionOverrideY="0x2a0d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <IList name="licensing_inspection_list" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Text name="licensing_option_choice_title" sizeOverrideX="0x350d0100" sizeOverrideY="0x360d0100"> <IList name="list_long_mongon_view" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Button name="button_long_mongon_view" positionOverrideY="0x420d0100">
XMB layout references in eula_cddb_plugin.sprx 4.89 offset:0x3E5A = 0x0D45 <--- line number 3398 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x421A = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x5F66 = 0x0D2E <--- line number 3375 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x5FB6 = 0x0D2E <--- line number 3375 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x6206 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x624E = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x630A = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x634E = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x9B92 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x9C0A = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x9C82 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0xADF2 = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
XMB layout references in eula_cddb_plugin.rco 4.89 0x2f0d0100 <--- line number 3376 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x300d0100 <--- line number 3377 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x310d0100 <--- line number 3378 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x320d0100 <--- line number 3379 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x330d0100 <--- line number 3380 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x3c0d0100 <--- line number 3389 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x3d0d0100 <--- line number 3390 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x460d0100 <--- line number 3399 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x470d0100 <--- line number 3400 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x480d0100 <--- line number 3401 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x490d0100 <--- line number 3402 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
<Plane name="plane_eula_licensing_wizard_arrow_back" positionOverrideX="0x2f0d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_back" positionOverrideY="0x310d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <Plane name="plane_eula_licensing_wizard_arrow_next" positionOverrideX="0x300d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_next" positionOverrideY="0x310d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <IList name="licensing_inspection_list" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Text name="licensing_option_choice_title" sizeOverrideX="0x3c0d0100" sizeOverrideY="0x3d0d0100"> <IList name="list_long_mongon_view" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Button name="button_long_mongon_view" positionOverrideY="0x490d0100">
From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule
All the unique 4.89 XMB "grid" layout references above, combined in a single list
Line 3374 // Loaded by eula_cddb_plugin.sprx Line 3375 // Loaded by eula_cddb_plugin.sprx Line 3376 // Loaded by eula_cddb_plugin.rco Line 3377 // Loaded by eula_cddb_plugin.rco Line 3378 // Loaded by eula_cddb_plugin.rco Line 3379 // Loaded by eula_cddb_plugin.rco Line 3380 // Loaded by eula_cddb_plugin.rco Line 3389 // Loaded by eula_cddb_plugin.rco Line 3390 // Loaded by eula_cddb_plugin.rco Line 3396 // Loaded by eula_cddb_plugin.sprx and eula_hcopy_plugin.sprx Line 3398 // Loaded by eula_cddb_plugin.sprx Line 3399 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco Line 3400 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco Line 3401 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco Line 3402 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco Line 4351 // Loaded by eula_hcopy_plugin.rco Line 4353 // Loaded by eula_hcopy_plugin.rco
- eula_net_plugin.rco doesnt contains any reference to the XMB layouts, and eula_net_plugin.sprx contains 10 values located over line 4255 of the XMB grid layout files
VSH exports[edit source]
- This exports seems to be used to get the position and sizes located in the "XMB layouts" .txt files
- paf::PhWidget::GetLayoutPos(int &, int &, int &, vec4 &)const
- paf::PhWidget::GetLayoutPosValue(void)
- paf::PhWidget::GetLayoutSize(int &, int &, int &, vec4 &)const
- paf::PhWidget::GetLayoutSizeValue(void)
- This ones to set them
- paf::PhWidget::SetLayoutPos(int, int, int, vec4)
- paf::PhWidget::SetLayoutSize(int, int, int, vec4)
- And this ones to redraw them
- paf::PhWidget::UpdateLayoutPos(void)
- paf::PhWidget::UpdateLayoutSize(void)
Video Output Settings[edit source]
https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html
The screen at step 7 of the "PlayStation 3 User's Guide" shows all this posible strings (copyed from inside sysconf_plugin.rco)
<Text name="msg_480p">480p</Text>
<Text name="msg_576p">576p</Text>
<Text name="msg_720p">720p</Text>
<Text name="msg_1080i">1080i</Text>
<Text name="msg_1080p">1080p</Text>
<Text name="msg_720p_3d">720p (3D)</Text>
<Text name="msg_1080i_3d">1080i (3D)</Text>
<Text name="msg_1080p_3d">1080p (3D)</Text>
<Text name="msg_720p_dual_view">720p (SimulView™)</Text>
<Text name="msg_sd_ntsc">Standard (NTSC)</Text>
<Text name="msg_sd_pal">Standard (PAL)</Text>
<Text name="msg_select_all_resolution">Select all resolutions that are supported by your TV.</Text>
The description "Standard (NTSC)" and "Standard (PAL)" coud be confusing for someone (me included), but this paragraph from the user's guide indicates Standard (NTSC) is 480i, and Standard (PAL) is 576i
The video resolution is selected in order of priority as follows: 1080p > 1080i > 720p > 480p/576p > Standard (NTSC:480i/PAL:576i).
So for clarification purposes this strings from inside sysconf_plugin.rco could be customized as:
<Text name="msg_sd_ntsc">480i (Standard NTSC)</Text>
<Text name="msg_sd_pal">576i (Standard PAL)</Text>
Coldboot script logic[edit source]
Inside the coldboot.raf there is a script that detects the current display resolution, and based on it applyes some transformations (scale and position) to the coldboot logos. In it can be seen how the PS3 XMB groups the ED and SD resolutions together
The other video modes with a width different than 720 pixels doesnt falls into this "if-else" statements
- The screen resolution detection logic starts with the statement
if (System.resolution->0 == 720). It seems this includes all this video modes:- 576p and 576i (4:3 aspect ratio) 720x576 (PAL anamorphic)
- 480p and 480i (3:2 aspect ratio) 720×480 (NTSC anamorphic)
- After that, the next logic stament is
if (camera.aspect == 4.0 / 3.0), this includes only:- 576p and 576i (4:3 aspect ratio) 720x576 (PAL anamorphic)
- Else is:
- 480p and 480i (3:2 aspect ratio) 720×480 (NTSC anamorphic)