Editing Resource Container (RCO)
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 202: | Line 202: | ||
*And '''MainTree-ObjectTree-Page''' (because the animation needs to be linked to an object by using a reference, otherway rcomage will return an error when trying to compile it) | *And '''MainTree-ObjectTree-Page''' (because the animation needs to be linked to an object by using a reference, otherway rcomage will return an error when trying to compile it) | ||
}} | }} | ||
==String tables== | |||
This area stores the text strings used by the TOC entries, is composed by 3 tables in this order: | |||
*'''text_string_table''' (to store localized language texts from TextTree entries) | |||
*'''label_string_table''' (to store the labels of all the entries that uses labels) | |||
*'''event_string_table''' (to store the values of the attributes used by some entries, either "native" or "script" events) | |||
*Strings are null terminated (ends in 0x00) | |||
*Strings are aligned to 4 bytes boundary (padding at the end of every string when needed) | |||
==Pointer tables== | ==Pointer tables== | ||
Line 216: | Line 226: | ||
*The other "trees" children that doesnt uses a pointer table are: MainTree (is not needed because its children are the other "trees"), ScriptTree (because doesnt have children), and FontTree because ?????<!--i cant imagine why but there must be a good reason--> | *The other "trees" children that doesnt uses a pointer table are: MainTree (is not needed because its children are the other "trees"), ScriptTree (because doesnt have children), and FontTree because ?????<!--i cant imagine why but there must be a good reason--> | ||
*The existence of this area with pointers seems to be related with the fact that is posible to use a whole file compression (by setting it in the header at offset 0x0C) that compresses the TOC. Also when loading the .RCO file in the RAM of the console probably is "cropped" in parts, the TOC is decompresed and kept in a memory area with the other TOC's from the other RCO files (for fast selective access to the .RCO contents, and for performance) and is posible to read the relative offsets directlly from the TOC's and deprecate the absolute offsets from the pointers tables<!--or something like that, if someone can explain it please help rewriting this--> | *The existence of this area with pointers seems to be related with the fact that is posible to use a whole file compression (by setting it in the header at offset 0x0C) that compresses the TOC. Also when loading the .RCO file in the RAM of the console probably is "cropped" in parts, the TOC is decompresed and kept in a memory area with the other TOC's from the other RCO files (for fast selective access to the .RCO contents, and for performance) and is posible to read the relative offsets directlly from the TOC's and deprecate the absolute offsets from the pointers tables<!--or something like that, if someone can explain it please help rewriting this--> | ||
==Data tables== | ==Data tables== |