Talk:RCOXML Objects

RCOXML format versions

The last 5 objects (ObjUnknown0x1B, CheckboxGroup, CheckboxItem, Meter, EditBox) are specific for PS3 (not supported by PSP)

Objects not used in PS3 official firmware

Some of them maybe supported (especially ObjUnknown0xB that was implemented specifically for PS3)

[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)