Editing Talk:XMB Layouts

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 23: Line 23:
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]]<br>
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]]<br>


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 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 combo is... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB)


The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|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 samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|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<br>


  XMB layout references in eula_hcopy_plugin.sprx 4.88
  XMB layout references in eula_hcopy_plugin.sprx 4.88
Line 147: Line 143:
</syntaxhighlight>}}
</syntaxhighlight>}}


----
In total there are 11 attributes updated in between 4.88 and 4.89 in eula_hcopy_plugin.rco but some of them contains the same hex value (for optimization purposes, are references to the same line in the XMB layout files)
If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 6 references to the XMB layouts


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>
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<br>
All the unique 4.89 XMB "grid" layout references above, combined in a single list
In firmware 4.89 this rco is storing 4 values consecutivelly at lines 3399, 3400, 3401, 3402. And additionally is storing another 2 values at lines 4351 and 4353 (not consecutivelly, there is a gap in between them used by something else)
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=
----
*This exports seems to be used to get the position and sizes located in the "XMB layouts" .txt files
When comparing the (decrypted) 4.88 and 4.89 versions of eula_hcopy_plugin.sprx there are only 2 bytes that differs (that belongs to 2 values of 2 bytes length each)
**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=
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<br>
https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html
The 2 bytes updated in this sprx for 4.89 are the references to the XMB layouts, and both are a references to the same line number of the XMB layouts, so this sprx only stores a single value in the XMB layouts (located 3 lines before the values stored by the associated rco)<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
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)
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Template used on this page: