PS3 RCOMAGE Mod 1.9 - Proper & Automated GIM to PNG conversion, Dump & Compile Files.

[template]

I think i know why it happened, a lot of the .sprx (or maybe all them, not sure) have the structure of <ObjectTree> from the .rco hardcoded inside the .sprx
In plain words... the .sprx is going to search inside the .rco for the objects under <ObjectTree> in his original positions
We can add objects (always at bottom to dont displace the officials) but we cant reorder, delete, or rename the officials

What broke the rco in that test was deleting the <plane> objects... is needed to keep them... but we can make then to load a dummy from <ImageTree>
And we can replace in the <plane> the value responsible to load the <Image> from <ImageTree> so it will be displayed as a polygon (without image)
And we can "hide" the polygon created by the <plane> too by changing the "color" (the value of alpha channel)

I managed to do what i wanted!
There were problems with the configuration offered by RCOMAGE. I took pictures that PS3 PRO MOD offers to get as close as possible to its .rco while keeping the original appearance as much as possible

Thank you for the precious information that you gave me because i still didn't know much about it

 

[sandungas]

As you can see we are moving in a swampy area
We know there is some kind of restriction, but we dont know how it works... so we dont know how to bypass that restriction

It seems @LuanTeles was doing a bunch of different things, reducing image sizes, replacing them by dummies, and not sure if some special reordering under <ImageTree> too
Probably he tryed tenths of combinations and eventually he got a "bingo", but i dont know if he found some rule we can follow, as far i remember he never explained the details of what he did

 

[LuanTeles]

Removing the shadows freeze when a simple press on the PS button

You can't remove an existing image on the rco, if you need to remove it or have an extra space on it, just fill it with a dummy 1x1 transparent dot.

the rcos are little tricky i don't understand then yet, like impose.rco it crashes the system if the rco size goes past 58kb ( as i remember), but sometimes it will show blank images at 48kb sometimes it will crash at 50Kb. ( this case i summarized some existing texts strings)

it is like @sandungas said it is test and error, almost all rcos i compile and test it about 50times till i get everything working properly;

Every rco follows different rules.

The most problematic one is sysconf_plugin, the original is 2.48Mb (not exactly, i don't remember right now) and i added a bunch of animations on it, it got way smaller than 2.48MB but in this case the crash is due to many texts strings, so a workaround was to delete some old and unused text strings, even doing this i couldn't get the space i was seeking for;

The best one to work with is the explorer_plugin_full.rco i added about 1000texts strings in each language and a lot of images, it works just fine

 

[template]

As you can see we are moving in a swampy area
We know there is some kind of restriction, but we dont know how it works... so we dont know how to bypass that restriction

It seems @LuanTeles was doing a bunch of different things, reducing image sizes, replacing them by dummies, and not sure if some special reordering under <ImageTree> too
Probably he tryed tenths of combinations and eventually he got a "bingo", but i dont know if he found some rule we can follow, as far i remember he never explained the details of what he did

You can't remove an existing image on the rco, if you need to remove it or have an extra space on it, just fill it with a dummy 1x1 transparent dot.

the rcos are little tricky i don't understand then yet, like impose.rco it crashes the system if the rco size goes past 58kb ( as i remember), but sometimes it will show blank images at 48kb sometimes it will crash at 50Kb. ( this case i summarized some existing texts strings)

it is like @sandungas said it is test and error, almost all rcos i compile and test it about 50times till i get everything working properly;

Every rco follows different rules.

The most problematic one is sysconf_plugin, the original is 2.48Mb (not exactly, i don't remember right now) and i added a bunch of animations on it, it got way smaller then 2.48MB but in this case the crash is due to many texts strings, so a workaround was to delete some old and unused text strings, even doing this i couldn't get the space i was seeking for;

The best one to work with is the explorer_plugin_full.rco i added about 1000texts strings in each language and a lot of images, it works just fine

Okay thank you, thank you for this valuable information

 

[sandungas]

You can't remove an existing image on the rco, if you need to remove it or have an extra space on it, just fill it with a dummy 1x1 transparent dot.

the rcos are little tricky i don't understand then yet, like impose.rco it crashes the system if the rco size goes past 58kb ( as i remember), but sometimes it will show blank images at 48kb sometimes it will crash at 50Kb. ( this case i summarized some existing texts strings)

it is like @sandungas said it is test and error, almost all rcos i compile and test it about 50times till i get everything working properly;

Every rco follows different rules.

The most problematic one is sysconf_plugin, the original is 2.48Mb (not exactly, i don't remember right now) and i added a bunch of animations on it, it got way smaller then 2.48MB but in this case the crash is due to many texts strings, so a workaround was to delete some old and unused text strings, even doing this i couldn't get the space i was seeking for;

The best one to work with is the explorer_plugin_full.rco i added about 1000texts strings in each language and a lot of images, it works just fine

Inside the RCO structure there are 3 tables to store strings btw
One of them is dedicated to store the language texts (and is using a bit weird structure), other stores the labels (like <plane name="label"), and the other is for the events (like OnCursorLeft="event:native/something")
What i dont know is if the size restriction you are having applyes to all them in group, individually, or to more things

Additionally there are more tables, one of them is dedicated to store images, and it could have a max size restriction too
But what doesnt makes sense is if the image table have a size restriction them the "damaged" images should be either all them... or only the last ones of the table (located in positions that exceeds the restriction hardcoded in the .sprx)
But what happens when we reorder them under <ImageTree> looks random... the damaged ones are not the last of the list

 

[sandungas]

For the record... when i mentioned the idea of "interleaving" dummy images in between the real images of <ImageTree> i was thinking in this theory...

What im going to say is very related with programming and i dont really know the details of how it works... but as something conceptual... the images you copy to RAM needs to follow some rules because the RAM management is very strict and the graphic libraries are designed for efficience, if you do something wrong the graphic libraries cant load the image
You need to imagine the RAM like one of that old magnetic tapes (or like an array), and the images needs to be located next to the others like if we was playing tetris... (the goal is to dont create "gaps" in between them)

The problem we was discussing in the PS3 could happen because when we reorder the contents of the <ImageTree> we are creating that "gaps"... and the gap is breaking the image located next to it
Lets say... if i locate image 24 in a wrong position then im creating a gap at his right, and the image25 located at the right of the gap is broken
So... the problem is in image24... but image24 is displayed fine... and image25 is displayed wrong
So... when we look at the XMB we see image25 is broken... and intuitivelly we think image25 is the culprit... but the problem is not really in image25

I know there is some people in this forum that are used to this special management of images in PS3 RAM, maybe they can explain it (or tell me my theory is wrong)

Spoiler

Also, the RAM management in a console have special "antihack" safety meassures that doesnt exists in PC