Talk:RCOXML Objects

RCOXML format versions

• Objects supported by PSP, but with added attributes specific for PS3
  • Standard object attributes (6 attributes added)
  • MList (3 attributes added)
  • Text (3 attributes added)
  • Spin (2 attributes added)
  • ItemSpin (2 attributes added)
  • LList (2 attributes added)
  • IList (4 attributes added)
  • IItem (1 attribute added)

• Objects specific for PS3 (not supported by PSP)
  • ObjUnknown0x1B
  • CheckboxGroup
  • CheckboxItem
  • Meter
  • EditBox

• Objects not used in PS3 official firmware (ObjUnknown0x1B is an easter egg, implemented specifically for PS3 but not used in latest PS3 retail firmware)
  • ObjUnknown0xB
  • XItem
  • ModelObject
  • LItem
  • Icon
  • UButton
  • ObjUnknown0x1B

Float conversions

Some of the values in the tables in frontpage (in the red marked rows as speculative) was dumped by rcomage as type "unk" but are "floats", for this reason rcomage didnt made the float-to-decimal conversion and appears as a hexidecimal value with the endianess swapped (bytes reversed) and the starting zeroes removed

To make the decimal conversion you can use this web http://www.h-schmidt.net/FloatConverter/IEEE754.html

Example, a value 0xa0c0 was extracted by using the type "unk". After changing endianess manually the value is 0xc0a00000. And after the decimal conversion the result is -5

Screen resolution adaptative values

Some of the values (mostly positions and maybe scalation factors) of some important "rcoxml objects" inside .rco files has been replaced by a reference to the XMB Layouts files with the purpose of changing his values "on the fly" based in the screen resolution settings for the TV

The .rco format is inherited from PSP, but PSP only used 1 screen resolution so this feature of the .rco format was not used in PSP, is specific for PS3

Standard object attributes

Are used 5485 times in 4.76 PS3 firmware, most objects uses them so is the most important group of attributes and are critical to fully understand how all the other objects works. Also the way that is stored some of the "unknown" attribute values is the same used in other unknowns from other objects. in few words, by identifying this unknowns there will be a lot of other objects affected not only in the "standard attributes" but also in the "specific attributes"

• Are pointers to the grid tables !!!, see XMB Layouts. The firmware loads the rco, calculates the pointer to a line of the grid table, and loads the value from the grid table
• The value in the rco is composed by: "grid line reference" (first 2 bytes swapped, then converted to decimal) + "unknown flags" (last 2 bytes swapped). The "unknown flags" maybe are related with the presence (or not) of a alternative value in the factor tables
• The grid is a 3D scene defined by the X, Y, Z axis, the camera (TV screen frame) is located in the vertical of Z axis, the world coordinates is located in the center of the screen (0, 0, 0)
• In the proposed names below, the "group1" and "group2" are just temporal names because is partially unknown what represents (one of them is position, the other is not clear)
• rcomage is not able to extract the 2 values that composes each attribute separatedlly (it messes up both together, the "grid line reference" from the first 2 bytes, and the "unknown flags" from last 2 bytes), for this reason the better way to manage this data types with rcomage is as data type "unk" (for a raw value extraction)
  • standardUnknown17 should be renamed to something like...... gridRefgroup1X
  • standardUnknown18 should be renamed to something like...... gridRefgroup1Y
  • standardUnknown19 should be renamed to something like...... gridRefgroup1Z
  • standardUnknownInt20 should be renamed to something like... gridRefgroup2X
  • standardUnknownInt21 should be renamed to something like... gridRefgroup2Y
  • standardUnknown22 should be renamed to something like...... gridRefgroup2Z

Unknown17, Unknown18, Unknown19

The 3 are related, and stores the value in the same format (this format is also used by a lot of specific attributes of other unknowns), some examples:

standardUnknown17="0xf6010100" standardUnknown18="0xf7010100" standardUnknown19="0xf8010100"
standardUnknown17="0xf9010100" standardUnknown18="0xfa010100" standardUnknown19="0xfb010100"
standardUnknown17="0x80040100" standardUnknown18="0x81040100" standardUnknown19="0x82040100"
standardUnknown17="0x84040100" standardUnknown18="0x85040100" standardUnknown19="0x86040100"
standardUnknown17="0x120f0100" standardUnknown18="0x140f0100" standardUnknown19="0x6000100"
standardUnknown17="0xfc0e0000" standardUnknown18="0xfe0e0000" standardUnknown19="0x6000000"
standardUnknown17="0x4000100"  standardUnknown18="0x5000100"  standardUnknown19="0x6000100"

Is not very usuall to see the 3 used consecutivelly (most times the first or the last stores a 0x0000, 0x0001, 0x0100, or 0x0101), but are used this way several times inside firmware, and its values uses to increases in + 0x1000000 or + 0x2000000

Unknown20, Unknown21, Unknown22

Seems related too, but uses a different value format, some examples:

Attribute 20 and 21 of the examples below are not valid because was extracted as "int" !!!

standardUnknownInt20="0x1029a" standardUnknownInt21="0x1029b" standardUnknown22="0x100"
standardUnknownInt20="0x10cfa" standardUnknownInt21="0x10cfb" standardUnknown22="0x100"
standardUnknownInt20="0x10f38" standardUnknownInt21="0x10f39" standardUnknown22="0x100"
standardUnknownInt20="0x10b75" standardUnknownInt21="0x10b76" standardUnknown22="0x100"
standardUnknownInt20="0x10675" standardUnknownInt21="0x10676" standardUnknown22="0x100"
standardUnknownInt20="0x10679" standardUnknownInt21="0x1067a" standardUnknown22="0x100"
standardUnknownInt20="0x10683" standardUnknownInt21="0x10684" standardUnknown22="0x100"
standardUnknownInt20="0x1067f" standardUnknownInt21="0x10680" standardUnknown22="0x100"
standardUnknownInt20="0x1068b" standardUnknownInt21="0x1068c" standardUnknown22="0x100"
standardUnknownInt20="0x10687" standardUnknownInt21="0x10688" standardUnknown22="0x100"
standardUnknownInt20="0x1068b" standardUnknownInt21="0x1068c" standardUnknown22="0x100"
standardUnknownInt20="0x10007" standardUnknownInt21="0x10008" standardUnknown22="0x100"
standardUnknownInt20="0x10d94" standardUnknownInt21="0x10d95" standardUnknown22="0x100"
standardUnknownInt20="0x10d94" standardUnknownInt21="0x10d96" standardUnknown22="0x100"
standardUnknownInt20="0x10d9b" standardUnknownInt21="0x10d9c" standardUnknown22="0x100"
standardUnknownInt20="0x10d7d" standardUnknownInt21="0x10d7e" standardUnknown22="0x100"
standardUnknownInt20="0xef8"   standardUnknownInt21="0xef9"   standardUnknown22="0x840d0000"

• standardUnknown22 (used 5485 times) is related to the Z axis, with value:
  • "0x0000 0000" (5411 times) <---- no grid reference (first 2 bytes), the image is laying in the same plane than the world coordinates center (last 2 bytes)
  • "0x0000 0100" (73 times) <---- no grid reference (first 2 bytes), the image is displaced 1 pixel closer to the camera (last 2 bytes swaped), this trick is used frequently in other parts of the firmware (like in the script of coldboot.raf) when images are overlapped to assure this one is displayed on top of the others
  • "0x840d 0000" (1 time, inside hknw_plugin.rco) <--- the z axis displacement value is stored in the grid layout table (first 2 bytes swaped, converted to decimal, + 1 = line 3461)

Example from hknw_plugin.rco

Code Sample

---

The value format seems the same in all the 6 unknowns, because the 0x840d0000 is storing bytes in the order: xx0yzzzz (this pattern matches with lot of other unknown attributes, standard and specific)

The zero is a real zero and uses to appear in that position (when the pointer is an small number) because the first 2 bytes needs to be swapped like this: 0yxx

The zzzz seems separated, and usually stores only a 0x0000, 0x0001, 0x0100, or 0x0101 <--- this ones are the "unknown flags" maybe related with the factor table (and this examples are not accurate)

Grid references example

For more detailed info see the changelog of Talk:Custom_render_plugin.rco and XMB Layouts

• In firmware 4.50 custom_render_plugin.rco contains 3 plane objects using the standard attributed definitions:
  • Page object page_coldboot - is the old/classic coldboot from firmware 1.00 used when the console boots
    • Plane object scelogo - is an image of 512x32 pixels size. Uses grid references
  • Page object page_coldboot2 - is the new coldboot introduced in firmware 2.70
    • Plane object coldboot_ps3logo - is a placeholder for the coldboot.raf animation. Doesnt uses grid references
  • Page object page_gameboot - used when a game boots
    • Plane object ps3logo - is an image of 512x54 pixels size. Uses grid references

Code Sample

And this is the same, using more linefeeds and tabs, and ordered in groups for a better overview

Code Sample

As a resume:

• page_coldboot
  • scelogo
    • standardPosX="0" standardPosY="0" standardPosZ="0" <--------------------------------------------------------------- positions are empty !
    • standardWidth="0" standardHeight="0" standardDepth="0" <------------------------------------------------------------ sizes are empty !
    • standardUnknown17="0x98020000" standardUnknown18="0x99020000" standardUnknown19="0x0" <------- This ones are grid references, overrides the values for position
    • standardUnknown20="0x9a020100" standardUnknown21="0x9b020100" standardUnknown22="0x100" <---- This ones are grid references, overrides the values for sizes

• page_coldboot2
  • coldboot_ps3logo
    • standardPosX="0" standardPosY="0" standardPosZ="0" <--------------------------------------------------------------- positions are empty !
    • standardWidth="0" standardHeight="0" standardDepth="0" <------------------------------------------------------------ sizes are empty !
    • standardUnknown17="0x0" standardUnknown18="0x0" standardUnknown19="0x0" <------------------------------ This is reserved for a grid reference, but is doubtfull how this values are working
    • standardUnknown20="0x100" standardUnknown21="0x100" standardUnknown22="0x100" <--------------------- This is reserved for a grid reference, but is doubtfull how this values are working

• page_gameboot
  • ps3logo
    • standardPosX="0" standardPosY="0" standardPosZ="0" <--------------------------------------------------------------- positions are empty !
    • standardWidth="0" standardHeight="0" standardDepth="0" <------------------------------------------------------------ sizes are empty !
    • standardUnknown17="0x0" standardUnknown18="0x0" standardUnknown19="0x0" <------------------------------- This ones are grid references, overrides the values for position
    • standardUnknown20="0x9c020100" standardUnknown21="0x9d020100" standardUnknown22="0x100" <------ This ones are grid references, overrides the values for sizes

---

Before calculating the grid references is needed to convert the values manually to the correct format. Every one of the attributes used for grid references is composed by 2 values, the first one is the grid reference itself (first 2 bytes), and the second one is unknown (last 2 bytes). Is needed to cut the attribute at half and swap the bytes

• scelogo grid references
  • position
    • standardUnknown17="0x98020000" <----------- this is 0x0298 (grid reference) and 0x0000 (unknown)
    • standardUnknown18="0x99020000" <----------- this is 0x0299 (grid reference) and 0x0000 (unknown)
    • standardUnknown19="0x0" <---------------------- this is 0x0000 (grid reference ?) and 0x0000 (unknown)
  • size
    • standardUnknown20="0x9a020100" <----------- this is 0x029a (grid reference) and 0x0001 (unknown)
    • standardUnknown21="0x9b020100" <----------- this is 0x029b (grid reference) and 0x0001 (unknown)
    • standardUnknown22="0x100" <------------------- this is 0x0000 (grid reference ?) and 0x0001 (unknown)

• coldboot_ps3logo grid references
  • position
    • standardUnknown17="0x0" <---------------------- this is 0x0000 (grid reference ?) and 0x0000 (unknown)
    • standardUnknown18="0x0" <---------------------- this is 0x0000 (grid reference ?) and 0x0000 (unknown)
    • standardUnknown19="0x0" <---------------------- this is 0x0000 (grid reference ?) and 0x0000 (unknown)
  • size
    • standardUnknown20="0x100" <------------------- this is 0x0000 (grid reference ?) and 0x0001 (unknown)
    • standardUnknown21="0x100" <------------------- this is 0x0000 (grid reference ?) and 0x0001 (unknown)
    • standardUnknown22="0x100" <------------------- this is 0x0000 (grid reference ?) and 0x0001 (unknown)

• ps3logo grid references
  • position
    • standardUnknown17="0x0" <---------------------- this is 0x0000 (grid reference ?) and 0x0000 (unknown)
    • standardUnknown18="0x0" <---------------------- this is 0x0000 (grid reference ?) and 0x0000 (unknown)
    • standardUnknown19="0x0" <---------------------- this is 0x0000 (grid reference ?) and 0x0000 (unknown)
  • size
    • standardUnknown20="0x9c020100" <----------- this is 0x029c (grid reference) and 0x0001 (unknown)
    • standardUnknown21="0x9d020100" <----------- this is 0x029d (grid reference) and 0x0001 (unknown)
    • standardUnknown22="0x100" <------------------- this is 0x0000 (grid reference ?) and 0x0001 (unknown)

---

Now to get the correct value from the grid references is needed to look at the XMB Layouts files from the same firmware !!!

The grid reference value needs to be converted to decimal, and added a +1 (because it seems inside the .txt file the lines are counted starting with zero, so first line is number 0)

• scelogo grid references
  • position
    • standardUnknown17="0x98020000" <----------- the first 2 bytes 0x0298 swapped and converted to decimal = 664 + 1 = line 665 of XMB Layouts files
    • standardUnknown18="0x99020000" <----------- the first 2 bytes 0x0299 swapped and converted to decimal = 665 + 1 = line 666 of XMB Layouts files
    • standardUnknown19="0x0" <---------------------- the first 2 bytes 0x0000 swapped and converted to decimal = 0
  • size
    • standardUnknown20="0x9a020100" <----------- the first 2 bytes 0x029a swapped and converted to decimal = 666 + 1 = line 667 of XMB Layouts files
    • standardUnknown21="0x9b020100" <----------- the first 2 bytes 0x029b swapped and converted to decimal = 667 + 1 = line 668 of XMB Layouts files
    • standardUnknown22="0x100" <------------------- the first 2 bytes 0x0000 swapped and converted to decimal = 0

• ps3logo grid references
  • position
    • standardUnknown17="0x0" <---------------------- the first 2 bytes 0x0000 swapped and converted to decimal = 0
    • standardUnknown18="0x0" <---------------------- the first 2 bytes 0x0000 swapped and converted to decimal = 0
    • standardUnknown19="0x0" <---------------------- the first 2 bytes 0x0000 swapped and converted to decimal = 0
  • size
    • standardUnknown20="0x9c020100" <----------- the first 2 bytes 0x029c swapped and converted to decimal = 668 + 1 = line 669 of XMB Layouts files
    • standardUnknown21="0x9d020100" <----------- the first 2 bytes 0x029d swapped and converted to decimal = 669 + 1 = line 670 of XMB Layouts files
    • standardUnknown22="0x100" <------------------- the first 2 bytes 0x0000 swapped and converted to decimal = 0

XMB Layout grid tables

Line number	layout_grid_table_272.txt	layout_grid_table_480.txt	layout_grid_table_720.txt	layout_grid_table_1080.txt
1	0	0	0	0
2	1	1	1	1
665	177	133	266	400
666	0	0	0	0
667	455	455	682	1024
668	28	28	42	64
669	533	533	800	1200
670	56	56	85	128

Now replacing the values from layout_grid_table_1080.txt to see how are displayed in a HD screen:

• page_coldboot
  • scelogo for 1080p resolution
    • position (center of the screen, displaced 400 pixels right)
      • X=400
      • Y=0
      • Z=0
    • size (the original image scelogo.gim is 512x32 pixels, but is displayed at double his size 1024x64)
      • X=1024
      • Y=64
      • Z=0

• page_gameboot
  • ps3logo for 1080p resolution
    • position (center of the screen)
      • X=0
      • Y=0
      • Z=0
    • size
      • X=1200 (the original image ps3logo.gim is 512x54 pixels, but displayed at 1200x128)
      • Y=128
      • Z=0

Load video

YouTube

YouTube might collect personal data. Privacy Policy

ContinueDismiss