Talk:XMB Layouts: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
m (moved to front)
No edit summary
Line 8: Line 8:
===Safety Notes===
===Safety Notes===
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
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 ?===
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|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<br>
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<br>
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<br>
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 <b>IS NOT AN ALPHABETICAL ORDER</b>, 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)<br>
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<br>
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)<br>
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

Revision as of 16:37, 14 May 2022

Discussion/Speculation

Other images

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

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 ?

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