Talk:RCOXML Objects

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

• The 6 attributes specific for PS3 are references to the XMB Layouts files. The firmware loads the rco, calculates a reference 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)
• 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)