RCOmage psdevwiki MOD

PS3 [Research] RCOmage psdevwiki MOD v20180916

Download
Overview Extra info Updates (1) History Discussion
Let me quote you here:
DeViL303 said:
BTW, I think the wiki is wrong where it says

From what i learned when doing this bounce effect its the other way around.
  • 0x1 - starts slow, ends fast
  • 0x4 - starts fasts, ends slow
See the SNES video above and look at the bounce speeds and then compare that to the animation script, I have it starting fast and ending slow on the way up, and starting slow ending fast on the way down. took me ages to figure that out tbh to make it look half realistic.

A simple bounce is actually way more complicated than I thought when I started that animation, I thought just up down up down at first.. but no.. :)
Click to expand...
And myself from this same thread:
https://www.psx-place.com/threads/research-rcomage-psdevwiki-mod.17958/page-2#post-209079

sandungas said:
Im thinking in renaming the accelMode to easingMode

Accelmode is more intuitive and is the original name used by rcomage since years ago, but today i realized the name "ease" is more technical, im not sure if sony used the codename "ease" for it (with some prefix or suffix) when they wrote this RCO functions, but nowadays the name "ease" seems to be an standard, at least in some web programming languages like CSS

Is a long story, but im going to explain how it works roughly
Inside a RAF format file (used by coldboot.raf and the background.raf of dynamic PS3 themes) there is a program written in javascript, in it you can use all the animations types that exists in RCO format, like moving an image, rotate it, resize it, change his colors... and also allows for some more features like using maths operations, logical operators like if-else, for loops, etc...
In some of the functions there is an optional parameter used to represent a bezier curve with full freedom to select the values of it, bezier curves are tipically used with speed/time and accelerations

Take a look at this web service, they have a cool tool to create bezier curves that will help you to understand his usage better
https://cubic-bezier.com
And how are implemented in CSS in this web https://www.w3.org/TR/css-easing-1/
Not needed to read everything, just scroll down a bit, keep an eye at this image, and the name of this feature, is named easing
curve-keywords.svg


--------------------------------------------
In the RCO animations there is a value to choose the easing from a predefined selection of bezier curves
Basically, all this values have been found in OFW, so are valid, i dont know which one is each, but i guess is going to be something like this:

accelMode=0 (linear)
accelMode=1 (ease-in)
accelMode=2 (ease-out)
accelMode=3 (ease-in-out)

FYI @Danxx444 @LuanTeles @DeViL303 @Cypher_CG89
Click to expand...
Maybe you can identify each from that images with bezier curves, the way how is represented could be a bit confusing, and his curvatures could be different in PS3 RCOXML code
But is very usual to use this kind of bezier curves in graphic libraries, as far i remember opengl does it this way, and the xmb is based on it
 
Here is a quick animation I made showing the 5 different acceleration modes.


From top to bottom:
1st = accelMode="0x0" = constant speed
2nd = accelMode="0x1" = starts slow ends fast
3rd = accelMode="0x2" = first half fast, second half slow?
4th = accelMode="0x3" = starts slow, middle fast, ends slow
5th = accelMode="0x4" = starts fast ends slow

Code: 
<MoveTo object="object:ball_0" time="2000" accelMode="0x0" positionX="800" positionY="500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_1" time="2000" accelMode="0x1" positionX="800" positionY="250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_2" time="2000" accelMode="0x2" positionX="800" positionY="0" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_3" time="2000" accelMode="0x3" positionX="800" positionY="-250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_4" time="2000" accelMode="0x4" positionX="800" positionY="-500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<Delay time="2500" />
<MoveTo object="object:ball_0" time="2000" accelMode="0x0" positionX="-800" positionY="500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_1" time="2000" accelMode="0x1" positionX="-800" positionY="250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_2" time="2000" accelMode="0x2" positionX="-800" positionY="0" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_3" time="2000" accelMode="0x3" positionX="-800" positionY="-250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_4" time="2000" accelMode="0x4" positionX="-800" positionY="-500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<Delay time="2500" />
 
Last edited:
DeViL303 said:
Here is a quick animation I made showing the 5 different acceleration modes.


From top to bottom:
1st = accelMode="0x0" = constant speed
2nd = accelMode="0x1" = starts slow ends fast
3rd = accelMode="0x2" = first half fast, second half slow?
4th = accelMode="0x3" = starts slow, middle fast, ends slow
5th = accelMode="0x4" = starts fast ends slow

Code: 
<MoveTo object="object:ball_0" time="2000" accelMode="0x0" positionX="800" positionY="500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_1" time="2000" accelMode="0x1" positionX="800" positionY="250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_2" time="2000" accelMode="0x2" positionX="800" positionY="0" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_3" time="2000" accelMode="0x3" positionX="800" positionY="-250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_4" time="2000" accelMode="0x4" positionX="800" positionY="-500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<Delay time="2500" />
<MoveTo object="object:ball_0" time="2000" accelMode="0x0" positionX="-800" positionY="500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_1" time="2000" accelMode="0x1" positionX="-800" positionY="250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_2" time="2000" accelMode="0x2" positionX="-800" positionY="0" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_3" time="2000" accelMode="0x3" positionX="-800" positionY="-250" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<MoveTo object="object:ball_4" time="2000" accelMode="0x4" positionX="-800" positionY="-500" positionZ="0" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" />
<Delay time="2500" />
Click to expand...
Lulz, best test i ever seen, i need to watch the video several times and play around a bit with the web i mentioned (that allows to configure the values used in the bezier curves)
If at some point i feel like i understand it well i will make a "cheatsheet" image with the curves and the values for you and others to review it
 
It seems are the same "easing" functions from CSS
"linear easing" is the basic one (supported by PS3), the others are "cubic bezier easing functions" (supported by PS3 except the one that allows to configure the values of the curves), and CSS support some more named "step easing functions" (not supported by PS3 / unknown)

Im mentioning this because some of the cubic bezier easing functions have the values of the curves "hardcoded" for PS3 (and CSS uses some values as default that in some way are hardcoded too)
Well... i was trying to imagine that values hardcoded in the PS3 firmware (with the help of the web https://cubic-bezier.com and your video), have a precission of 2 decimals and are in between 0 and 1 (so values like 0.45 are valid for all fields)
But thats pretty much imposible just by looking at the video... i was trying to get an approximation thought, and trying to identifying a bit the values so i could do some "rounding" to represent the curves in a bit more intuitive way
But meh... i just realized the best i can do is to use that same values used as defaults by CSS, are this ones:
Code: 
A cubic Bézier easing function has the following syntax (using notation from [CSS3VAL]):
<cubic-bezier-easing-function> = ease | ease-in | ease-out | ease-in-out | cubic-bezier(<number>, <number>, <number>, <number>)
The meaning of each value is as follows:
ease
    Equivalent to cubic-bezier(0.25, 0.1, 0.25, 1).
ease-in
    Equivalent to cubic-bezier(0.42, 0, 1, 1).
ease-out
    Equivalent to cubic-bezier(0, 0, 0.58, 1).
ease-in-out
    Equivalent to cubic-bezier(0.42, 0, 0.58, 1).

Are also the default values used when you enter in the web https://cubic-bezier.com i got the direct links:
Deleted comment with mistakes, see below
 
Last edited:
I think this one is fine, now im adding the values because one of them is not following the CSS standards, i added the suffix "sce" to it, sony uses to do it, they starts following some standard but eventually they needs to add something new and they names it sce01
LEwfCwx.jpg

And this are the links where i took the screenshots:
accelMode="0x0" linear https://cubic-bezier.com/#0,0,1,1
accelMode="0x1" ease-in https://cubic-bezier.com/#.42,0,1,1
accelMode="0x2" ease-sce https://cubic-bezier.com/#0,.25,.58,.58
accelMode="0x3" ease-in-out https://cubic-bezier.com/#.42,0,.58,1
accelMode="0x4" ease-out https://cubic-bezier.com/#0,0,.58,1
 
Last edited:
@LuanTeles i think you found an unknown attribute in this experiment... at least partially
https://www.psx-place.com/threads/4...the-firmware-update.37203/page-12#post-332848

LuanTeles said:
wboard_plugin: The rss text is blinking. (Edit fixed by basic_plugins.sprx)
Click to expand...
I guess what was blinking was the glow effect at the background of the text, right ?
Well... thats for sure an effect that belongs to a <Text> RCOXML Object (or a <Editbox> that is pretty much like a <Text> on steroids)
Take a look at that table in wiki for the <text> objects and the attributes marked in red, at the end there are 3 attributes labeled as "overrideSomething", because are loading stuff from the layout.txt files but his purpose is unknown

The textOverrideUnk56 is the font size, as we was discussing before in this same thread
And the textOverrideUnk57 probably is the glow size, it seems you enabled it by mistake :encouragement:

Let me explain what i think it happened in your experiment, the new wboard_plugin.sprx from 4.89 contains at least one <text> object that is trying to load stuff from the layout.txt files (that have a displacement of 7 lines)... and when you "downgraded" the layout.txt to 4.88 (without the dsiplacement of 7 lines) the <text> object inside the wboard_plugin.sprx is loading the value from a different line

By default... most of attributes named textOverrideUnk57 uses the value 0x3000000 (this loads the line number 4 from the "grid" that contains a zero, and multiplyes by line 1 from the "factor", that contains another zero)... in other words... in most of the texts the glow is disabled

But it seems you enabled it when you forced textOverrideUnk57 to load a random line from the factor.txt files :encouragement:
The value in that line seems to be the glow size, 0 seems to be disabled, and i guess any other values is a radius in pixels

Can you make an easy test to confirm it ?, yesterday i was doing a list of how are mapped a few "font sizes" in the layout.txt files
This values are a bit generic (compatibles with all firmware versions) because are located in very low positions of the layout.txt files (line 19 up to line 24 so probably never was disturbed by any displacement)
Code: 
0x12000100 = 32 pixels font size (loaded from line 19 of the layout_grid_table_1080.txt from 4.70~4.88)
0x13000100 = 26 pixels font size (loaded from line 20 of the layout_grid_table_1080.txt from 4.70~4.88)
0x14000100 = 23 pixels font size (loaded from line 21 of the layout_grid_table_1080.txt from 4.70~4.88)
0x15000100 = 21 pixels font size (loaded from line 22 of the layout_grid_table_1080.txt from 4.70~4.88)
0x16000100 = 19 pixels font size (loaded from line 23 of the layout_grid_table_1080.txt from 4.70~4.88)
0x17000100 = 18 pixels font size (loaded from line 24 of the layout_grid_table_1080.txt from 4.70~4.88)

The experiment consist in replacing any apparence of:
Code: 
textOverrideUnk57="0x3000000"
By
Code: 
textOverrideUnk57="0x17000100"
If this theory is correct it should enable a glow of 18 pixels for that specific <text> object
Choose any <text> object you want from any rco file... better do it with a known text you are used to it to be sure if the blinking glow effect is correctly enabled


---------------
BONUS:
If it works, try to do the same test with textOverrideUnk58 (this could be the text shadow size... in black color)
 
Last edited:
sandungas said:
@LuanTeles i think you found an unknown attribute in this experiment... at least partially
https://www.psx-place.com/threads/4...the-firmware-update.37203/page-12#post-332848


I guess what was blinking was the glow effect at the background of the text, right ?
Well... thats for sure an effect that belongs to a <Text> RCOXML Object (or a <Editbox> that is pretty much like a <Text> on steroids)
Take a look at that table in wiki for the <text> objects and the attributes marked in red, at the end there are 3 attributes labeled as "overrideSomething", because are loading stuff from the layout.txt files but his purpose is unknown

The textOverrideUnk56 is the font size, as we was discussing before in this same thread
And the textOverrideUnk57 probably is the glow size, it seems you enabled it by mistake :encouragement:

Let me explain what i think it happened in your experiment, the new wboard_plugin.sprx from 4.89 contains at least one <text> object that is trying to load stuff from the layout.txt files (that have a displacement of 7 lines)... and when you "downgraded" the layout.txt to 4.88 (without the dsiplacement of 7 lines) the <text> object inside the wboard_plugin.sprx is loading the value from a different line

By default... most of attributes named textOverrideUnk57 uses the value 0x3000000 (this loads the line number 4 from the "grid" that contains a zero, and multiplyes by line 1 from the "factor", that contains another zero)... in other words... in most of the texts the glow is disabled

But it seems you enabled it when you forced textOverrideUnk57 to load a random line from the factor.txt files :encouragement:
The value in that line seems to be the glow size, 0 seems to be disabled, and i guess any other values is a radius in pixels

Can you make an easy test to confirm it ?, yesterday i was doing a list of how are mapped a few "font sizes" in the layout.txt files
This values are a bit generic (compatibles with all firmware versions) because are located in very low positions of the layout.txt files (line 19 up to line 24 so probably never was disturbed by any displacement)
Code: 
0x12000100 = 32 pixels font size (loaded from line 19 of the layout_grid_table_1080.txt from 4.70~4.88)
0x13000100 = 26 pixels font size (loaded from line 20 of the layout_grid_table_1080.txt from 4.70~4.88)
0x14000100 = 23 pixels font size (loaded from line 21 of the layout_grid_table_1080.txt from 4.70~4.88)
0x15000100 = 21 pixels font size (loaded from line 22 of the layout_grid_table_1080.txt from 4.70~4.88)
0x16000100 = 19 pixels font size (loaded from line 23 of the layout_grid_table_1080.txt from 4.70~4.88)
0x17000100 = 18 pixels font size (loaded from line 24 of the layout_grid_table_1080.txt from 4.70~4.88)

The experiment consist in replacing any apparence of:
Code: 
textOverrideUnk57="0x3000000"
By
Code: 
textOverrideUnk57="0x17000100"
If this theory is correct it should enable a glow of 18 pixels for that specific <text> object
Choose any <text> object you want from any rco file... better do it with a known text you are used to it to be sure if the blinking glow effect is correctly enabled


---------------
BONUS:
If it works, try to do the same test with textOverrideUnk58 (this could be the text shadow size... in black color)
Click to expand...

@sandungas I'm afraid the problem I have is not related to rco but to xml encoded inside vsh.self

See below what I meant when I said "blink effect", the texts are no longer scrolling even using 4.88 sprx and rcos, it's definitely encoded in vsh.self (the only one I didn't change for obvious reasons)

I also think that the web browser pointer/remote play (premo) overrides are also hard-coded inside vsh.self as they are the only bugs I couldn't solve by replacing sprx/rcos.

Edit: I tried sys/external from 4.88 and same thing, sys/internal semi bricked it.
 
Last edited:
@sandungas do you have any suggestion about updating my rcos to be compatible with 4.89?

From what i see here, i'll need to update more than 1000 rcos because I have several mod in the same rco, for instance

I have 15 clock mod, 8 system sounds, 12 button styles (this one i also had to make impose and premo to match it) all of them are in the same rco (system plugin)

So i had to made 15x8x12 (1440 rcos) that's why I'm looking for a way to use 4.88 files in 4.89 but this seems impossible due to the bugs already described.

i need to make it also compatible with 4,84 REX as we don't have any other alternative to it.

When i was making lines.rco variants with different particules styles, I used a macro recorder to play my moves to replace the files and compile them, but it wasn't very accurate, sometimes the cursor didn't play some clicks and it ruined the whole macro.

Edit: Using macros will not help in this case, because each type o mod in the system_plugin uses a different xml, for sounds (some i use 2 channels others 1 channel, due to limite size), different clock animations, different button animations, damn i don't know that to do.
 
Last edited:
@sandungas

If we only have a program like the psp's CFT TOOL GUI, would be perfect

I think you know this tool, it creates/extracts/compiles the ctf themes and also covert old rcos/sprx to newer firmwares by updating its overrides.
 
LuanTeles said:
@sandungas I'm afraid the problem I have is not related to rco but to xml encoded inside vsh.self

See below what I meant when I said "blink effect", the texts are no longer scrolling even using 4.88 sprx and rcos, it's definitely encoded in vsh.self (the only one I didn't change for obvious reasons)

I also think that the web browser pointer/remote play (premo) overrides are also hard-coded inside vsh.self as they are the only bugs I couldn't solve by replacing sprx/rcos.

Edit: I tried sys/external from 4.88 and same thing, sys/internal semi bricked it.
Click to expand...
What a shame, i thought it was the text glow effects (inherited from PSP rco format), but improved with the "override" feature specifically implemented for PS3
Basically... after thinking in what you said... i thought the glow effect was switched ON/OFF simply by his size (you know, size=0=disabled, and any other value different than zero enabled)... and considering the overrides are used to modify the sizes dinamically it made sense that it could be made that way

But the effect in your video is something i could not imagine, lol, yeah is like if the texts was blinking, i guess is because XMB is displaying them in 2 steps, first are displayed statically and after a few miliseconds starts scrolling (and the scrolling is what is failing)

That bar is codenamed "infobar", and the object definition is inside system_plugin.rco. It have 2 text messages, and i guess the text in your video is the second one (named "infotext2"). But the rco code is static, and the attribute responsible to load the text doesnt displays anything, is pretty much like this:
Code: 
<Text name="infotext2" ............... textMessage="nothing"></Text>
As you know... the sprx can change this attribute "on the fly" (to display any text), actually, system_plugin.sprx have an interface to expose this control to any other sprx (as far i understand is ID=16 of interface 1)

I know, this is not solving your problem (and maybe i made some mistake in this explanation), but i dont know how to solve it
Other that that... i have to return to the idea that maybe that effect was caused by an unexpected value loaded from the layout.txt files (maybe there is some attribute to controll the text scrolling speed ?, dunno)... in that case what you could try is to change the value of all the unknown attributes of that <text> effet (use the values i suggested in my previous post, are very convenient for experiments)
Additionally... you could try to play around with the attribute named "textFontMode", there are some examples in wiki of valid values used in OFW. Basically the value is like 4 "flags" together (every byte is a flag) where the only posible value is a 0 or a 1. To enable everything (in theory) you can use "0x01010101"
 
LuanTeles said:
I also think that the web browser pointer/remote play (premo) overrides are also hard-coded inside vsh.self as they are the only bugs I couldn't solve by replacing sprx/rcos.

Edit: I tried sys/external from 4.88 and same thing, sys/internal semi bricked it.
Click to expand...
Im not sure if vsh.self does it, but the other day after thinking in the results of your tests it was obvious for me that the sprx are storing some values inside the layout.txt files
Not sure if i mentioned it before, but in your test it was obvious because you had the rco files (al them) matching with the layout.txt files versions (so all positions, sizes, and scale factors of the rco's was loaded correctly). The only thing that was not matching was the sprx's, the code inside the sprx's was working but some of them was loading incorrect values from the layout.txt files because that dsiplacement of +7 lines
LuanTeles said:
@sandungas do you have any suggestion about updating my rcos to be compatible with 4.89?

From what i see here, i'll need to update more than 1000 rcos because I have several mod in the same rco, for instance

I have 15 clock mod, 8 system sounds, 12 button styles (this one i also had to make impose and premo to match it) all of them are in the same rco (system plugin)

So i had to made 15x8x12 (1440 rcos) that's why I'm looking for a way to use 4.88 files in 4.89 but this seems impossible due to the bugs already described.

i need to make it also compatible with 4,84 REX as we don't have any other alternative to it.

When i was making lines.rco variants with different particules styles, I used a macro recorder to play my moves to replace the files and compile them, but it wasn't very accurate, sometimes the cursor didn't play some clicks and it ruined the whole macro.

Edit: Using macros will not help in this case, because each type o mod in the system_plugin uses a different xml, for sounds (some i use 2 channels others 1 channel, due to limite size), different clock animations, different button animations, damn i don't know that to do.
Click to expand...
The root of the problem is we should consider the layout.txt files as a dependency of the rco files. The layout.txt is a single entity (well, are 2 for "grid" and "factor", but the fact that are splitted in 2 .txt files doesnt matters, becaue is a single thing used by all the rco files).. so the rco files (all them) should be considered another single entity
You know... sometimes we can take an rco from an old firmware version and use in a new firmware version and maybe it works, but is very hard to know if all the values from the layout.txt for that rco are loaded fine, but in this update from OFW 4.88 to OFW 4.89 sony created that displacement of +7 in the layout.txt files (not intentionally) that broke compatibility with a lot of old rco mods (basically, we have 43 rco's incompatibles with previous versions)

Im not sure what i would do if i where you with the 4K/PRO mods, in my oppinion is better to get updated to the new changes, keep in mind the rco's of the new CFW/HEN versions are going to be based on 4.89
If you "downgrade" too many files when your 4K/PRO mod is installed you are going to have lot of user reports of rco incompatibilities from people that installs new rco mods compatibles with the "standard" 4.89 files
There are lot of rco's that has not been updated in between 4.88 OFW and 4.89 OFW btw, you dont need to worrry about this ones... the problem are the other 43 that was updated

Keeping compatibility in your 4K/PRO with both rebug 4.84 and the new 4.89 firmwares at the same time is imposible... unless you take the road of "downgrading" files to 4.84, but by reading your reports it doesnt seems that downgrading files is going to be so easy and/or clean
 
The way how the XMB layouts works in relationship with the rco files has been always the kind of thing tricky to understand, in the last days i been messing around with them and i just made an small (but successful) experiment to find how they works in the sprx files. I published it in wiki because is a big wall of text with samples, please take a look at it
This is like the advanced level because is about sprx (newcomers better take a previous read at the main page, there are other samples of the gameboot and coldboot)... but i think is a good sample for all because it shows how to convert the values to "human readable" format in both, rco and sprx
XMB layout references inside SPRX files

I dont want to write another wall of text here, but some points...
-To me seems to be confirmed the sprx files stores values in the XMB layout.txt files
-It seems the sprx (first) and the associated rco (next) sometimes stores his values together in the XMB layout.txt files
-This same comparison can be made with the other "combos" of sprx/rco files that was updated for 4.89 to identify the references to the XMB layout.txt files inside the sprx
-In the last days i had doubts if the new XMB layout references added for 4.89 was "flushed", but it seems the displacemet is a constant of +7 for all them, so there is no "flushing"
-The XMB layout reference inside the sprx structure is not simply an isolated hex value. In theory is one of the attributes of a whole RCOXML Object that should be located next to it, following a hierarchy, etc... the way how this structure in generated by the sprx is unknown, more research is needed
 
Last edited:
There is no more need to brute force to determine the type. A small batch file that will determine the type and write it to list.txt:
Code: 
@echo off
setlocal enabledelayedexpansion
set pt=.\Rcomage\
set tl=0x44 0x02

for %%i in (.\rcofile\*.rco) do (
if not exist %%~pi%%~ni md %%~pi%%~ni
if not exist %%~pi%%~ni\txt md %%~pi%%~ni\txt
if not exist %%~pi%%~ni\img md %%~pi%%~ni\img
%pt%rcomage.exe dump %%i %%~dpi%%~ni.xml --RESDIR %%~dpi%%~ni --text txt --images img
set im=%%~dpi%%~ni\img
)
if exist %im%\list.txt del /Q %im%\list.txt

for %%f in (%im%\*.gim) do (
for /f "usebackq" %%a in (`%pt%sfk hexdump -pure -nofile -rawname -offlen %tl% %%f`) do set np=%%a
if !np!==0000 set opt=-ps3rgba5650
if !np!==0001 set opt=-ps3rgba5551
if !np!==0002 set opt=-ps3rgba4444
if !np!==0003 set opt=-ps3rgba8888
if !np!==0004 set opt=-ps3index4
if !np!==0005 set opt=-ps3index8
if !np!==0006 set opt=-ps3index16
if !np!==0007 set opt=-ps3index32
if !np!==0008 set opt=-ps3dxt1
if !np!==0009 set opt=-ps3dxt3
if !np!==000A set opt=-ps3dxt5
if !np!==0108 set opt=-ps3dxt1ext
if !np!==0109 set opt=-ps3dxt3ext
if !np!==010A set opt=-ps3dxt5ext
echo %%~nf !opt! >> %im%\list.txt
.\GimConv\GimConv.exe %%f -o %im%\%%~nf.png
del /Q %%f
)
:end

wiki Gim
 
Last edited:
Pretty cool @in1975 :encouragement:

Worths to be mentioned that there is a flag in the GIM header structure that indicates the "image_format" (one from the list of your batch)... but i prefer to perform the PNG--->GIM conversion and compare it with the original, because a GIM is not only the "image_format" setting, there are tenths of optional features an we need to be sure we are doing exactly the same than sony did when they created that specific gim
 
in1975 said:
There is no more need to brute force to determine the type. A small batch file that will determine the type and write it to list.txt:
Code: 
@echo off
setlocal enabledelayedexpansion
set pt=.\Rcomage\
set tl=0x44 0x02

for %%i in (.\rcofile\*.rco) do (
if not exist %%~pi%%~ni md %%~pi%%~ni
if not exist %%~pi%%~ni\txt md %%~pi%%~ni\txt
if not exist %%~pi%%~ni\img md %%~pi%%~ni\img
%pt%rcomage.exe dump %%i %%~dpi%%~ni.xml --RESDIR %%~dpi%%~ni --text txt --images img
set im=%%~dpi%%~ni\img
)
if exist %im%\list.txt del /Q %im%\list.txt

for %%f in (%im%\*.gim) do (
for /f "usebackq" %%a in (`%pt%sfk hexdump -pure -nofile -rawname -offlen %tl% %%f`) do set np=%%a
if !np!==0000 set opt=-ps3rgba5650
if !np!==0001 set opt=-ps3rgba5551
if !np!==0002 set opt=-ps3rgba4444
if !np!==0003 set opt=-ps3rgba8888
if !np!==0004 set opt=-ps3index4
if !np!==0005 set opt=-ps3index8
if !np!==0006 set opt=-ps3index16
if !np!==0007 set opt=-ps3index32
if !np!==0008 set opt=-ps3dxt1
if !np!==0009 set opt=-ps3dxt3
if !np!==000A set opt=-ps3dxt5
if !np!==0108 set opt=-ps3dxt1ext
if !np!==0109 set opt=-ps3dxt3ext
if !np!==010A set opt=-ps3dxt5ext
echo %%~nf !opt! >> %im%\list.txt
.\GimConv\GimConv.exe %%f -o %im%\%%~nf.png
del /Q %%f
)
:end

wiki Gim
Click to expand...
Awesome, so it was that easy all along, after 10 years of people struggling with different GIM formats. wow.
 
sandungas said:
Pretty cool @in1975 :encouragement:
here are tenths of optional features an we need to be sure we are doing exactly the same than sony did when they created that specific gim
Click to expand...

With this, I tried to parse rco, convert from gim to png, then build it back, converting from png to gim (using a script) with the specified options, and the new rco was with the same md5 as the old one, which indicates that the method works.
 
in1975 said:
With this, I tried to parse rco, convert from gim to png, then build it back, converting from png to gim (using a script) with the specified options, and the new rco was with the same md5 as the old one, which indicates that the method works.
Click to expand...
Right, but this procedure only works with the "lossless" image formats

-psprgba5650 <--- lossless
-psprgba5551 <--- lossless
-psprgba4444 <--- lossless
-psprgba8888 <--- lossless
-pspindex4 <--- lossless
-pspindex8 <--- lossless
-ps3rgba5650 <--- lossless
-ps3rgba5551 <--- lossless
-ps3rgba4444 <--- lossless
-ps3rgba8888 <--- lossless
-ps3index4 <--- lossy (as far i remember)
-ps3index8 <--- lossy (as far i remember)
-ps3index16 <--- lossy (as far i remember)
-ps3index32 <--- lossy (as far i remember)
-ps3dxt1 <--- lossy
-ps3dxt3 <--- lossy
-ps3dxt5 <--- lossy
-ps3dxt1ext <--- lossy
-ps3dxt3ext <--- lossy
-ps3dxt5ext <--- lossy

In other words... if the original GIM was made using one of the dxt formats and you convert it in a sequence GIM --->PNG --->GIM his hash is not going to match
The reason of this annoyance is because everytime you create a GIM with the dxt settings the pixel data is processed by an algorythm to optimize it (so the pixel data changes), and as a consequence we lose quality

This is why is so important in the bruteforce process explained here to do the conversions directly from GIM---to--> GIM
https://www.psdevwiki.com/ps3/GimConv#How_to_identify_GIM_settings
In a GIM to GIM conversion is preserved the original pixel data. In other words... is the only failproof way to perform the hash check at the ending of the bruteforce process

sandungas said:
*Notes* (about fileinfo and GimConv versions)
In the previous command example the option "--update_fileinfo" copyes the fileinfo area from the input "original.gim" and adds it to the output "try2.gim" BUT NOT ENTIRELLY !
At the end of the fileinfo area there is a text string with the name and version of the tool that generated the GIM (the tool name is always "GimConv", and the version uses to be "1.20e" but not always), this string inside the fileinfo area is updated when you do a GIM-to-GIM conversion
The problem is the only public GimConv.exe available is "GimConv 1.20h", so if the original RCO was made by "GimConv 1.20e" and you make a GIM-to-GIM conversion by using "GimConv 1.20h" the hash comparison (original GIM vs rebuild GIM) will not match because 1 byte of difference (e VS h)

To solve this problem and to be able to automatize the bruteforce identification procedures i created several GimConv.exe files with the version patched

There are lot of GIM files in PS3 retail firmwares made with GimConv 1.20e (and a timestamp of 2006 but are included up to retail 4.82 firmware because never was updated or replaced), so initially is better to use "GimConv 1.20e" always
If you are doing some research in older firmwares try with the other versions, specially GimConvC.exe because some GIM files in PS3 pre-retail firmwares was made with "GimConv 1.20c"
If you are having problems with this, or you are not getting an exact match when doing a hash comparison, open the original GIM files in a hexeditor and scroll down to the end of the file to see the GimConv versions sony used originally
For more detailed info about GIM structure see: psdevwiki
Click to expand...

And this is the other detail that could "break" the hash checks (original VS rebuilt) in the bruteforce made in your script
The point is... at the footer of some GIM files there is an (optional) text string that indicates the exact gimconv.exe version used by sony to create the original GIM... and in general all that GIM files are very old (that footer was something they was doing in old firmwares, and the rcomage.exe versions used in them are different than the standard GimConv 1.20h

This is why i included in this release several versions of rcomage.exe with patches to change this text... you know... the goal again is to achieve a perfect hash match at the ending of the bruteforce process
Your script is not going to catch this special GIM files... you need to add another "for" loop to create another set of GIM files with the other gimconv.exe versions i released
Either that... of read the original footer of the GIM file (to find if it have that string with the version), and patch your GIM files to make his versions to match with the version of the original GIM before checking his hashes
 
Last edited:
sandungas said:
Right, but this procedure only works with the "lossless" image formats
In other words... if the original GIM was made using one of the dxt formats and you convert it in a sequence GIM --->PNG --->GIM his hash is not going to match
Click to expand...
let's take the sysconf_plugin.rco file as an example. Almost all files are in ps3rgba8888 format, exception:
  • tex_arrow_anim -ps3dxt1 0x08 - dxt1 (no alpha)
  • tex_arrow_anim_shadow -ps3dxt1 0x08 - dxt1 (no alpha)
  • tex_sce_logo -ps3dxt3 0x09 - dxt3 (sharp alpha)
With the help of these 2 bat files, I have it unpacked and converted with the same md5
 
You must log in or register to reply here.

Similar threads

Back
Top