Talk:RCOXML Objects

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)

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

Objects used to build menues

Probably shares some attributes and follows an strict hierarchy of parent/children:

XMenu
XMList

XList
XItem

MList
MItem

LList
LItem

IList
IItem

• Superbrainstorming based on smoke

what about this ?, matches prety fine with how are grouped. Main menu separated because is an special object created specifically for top XMB menu, and the others grouped in pairs for "list" and "item". Also matches how are ordered in rcomage. All this attributes appears consecutivelly in groups of two, at top... XMList and XList... then MList MItem... then ObjUnknown0xB and XItem... then LList and LItem... then IList and IItem. Note how XMList doesnt seems to have an XMItem

XMenu

XMList
ObjUnknown0xB <------ is XMItem ?

XList
XItem

MList
MItem

LList
LItem

IList
IItem

If this is true and ObjUnknown0xB is actually XMItem it seems is posible to deduce the attributes because the other "item" objects uses pretty similar attributes, to verify it are needed some/lot of tests by copying the attributes from the other items and creating a 100% custom object for the experiment also a good understanding of all the other rcoxml code, so is hard to know, im not skilled/brave to build this frankenstein but i think the theory is good enought--Sandungas (talk) 08:16, 8 December 2015 (UTC)