sandungas
Developer
How is that ?
- Thread starter sandungas
- Start date
sandungas
Developer
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
--------------------------------------------
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
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
--------------------------------------------
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
Danxx444
Member
Wow is a lot for a small file ... do you plan to add this on the Coldboot (PS logo) rco that you are doing?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 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
--------------------------------------------
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
sandungas
Developer
Is using it actually, take a look at the lines when it does the <Fade> effects. they are using accelMode="0x3"
I gave them the value 3 because... official firmware uses them sometimes in the coldboot and gameboot animations, but i dont know what does the value 3
This is something you should change to 2 or 1 and see which one fits better to mimick the PS4 coldboot
sandungas
Developer
accelMode=4 is a valid value too, used in the official anim_gameboot animation of PS3 firmwares
sandungas
Developer
In the .zip there are 2 DLL files, have you tryed to copy them next to rcomage.exe ?
This dll's are optionals because some windows versions doesnt needs them, so not sure if is related
Cypher_CG89
Senior Member
Yep.. I get sick of it so I have made a txt file with all the comom commands I use for each image with their correct gim settings so I can just copy and paste them in or I just spam the TAB key with the PNG/and or GIM in the GimConv folder for the file names so svae typing them out....
CodeBlocks is good for making app GUI's if you ever want to look into trying it yourself at some point... I don't quite understand the programming/syntax yet for all the input/output's for the fields...
sandungas
Developer
The contents of rcomage-dev-v1.1.2.7z are official (untouched). This version was published by zinga burga as experimental to fix a bug reported by me. The bug was solved in it but it never was published as stable, and to be honest my experience trying to help zinga burga to improve rcomage was a bit frustrating, he is a polite person but he had no interest in working in it
The problem in rcomage-dev-v1.1.2 is it was compiled "dinamically"... this means is dependant of .dll libraries from your operating system
Most/all the other rcomage versions are compiled "statically"... this means the .dll libraries are inside the .exe
https://medium.com/@StueyGK/static-libraries-vs-dynamic-libraries-af78f0b5f1e4
And yeah, there are several reasons why i dediced to publish this as a "puzzle"... is because im rellying in the official binaries (so incase there is a bug in them, is not my fault... in other words im 100% confident i am not breaking them)... also because as something conceptual... lets say im "building on top" of it (so is very easy to see what i did, for all final users or for anyone interested in updating rcomage)
The problem in rcomage-dev-v1.1.2 is it was compiled "dinamically"... this means is dependant of .dll libraries from your operating system
Most/all the other rcomage versions are compiled "statically"... this means the .dll libraries are inside the .exe
https://medium.com/@StueyGK/static-libraries-vs-dynamic-libraries-af78f0b5f1e4
And yeah, there are several reasons why i dediced to publish this as a "puzzle"... is because im rellying in the official binaries (so incase there is a bug in them, is not my fault... in other words im 100% confident i am not breaking them)... also because as something conceptual... lets say im "building on top" of it (so is very easy to see what i did, for all final users or for anyone interested in updating rcomage)
I understand I guess, but 99.9% of users of an application like this just want to dump/compile an rco. They are not looking to see the history of its development or to be able to compare older crapper version with more recent more fixed version, and if there is even 0.1% who want to do that I would be surprised. They can probably find original 1.1.2 on the net somewhere in that case, and I don't see any downside to having dlls in correct folder.
sandungas
Developer
I dont want to change the MD5 of the official rcomage-dev-v1.1.2.7z sorry, this is why the DLL's are separated
It was not my purpose to have the DLL's separated, but zinga burga did it this way and it become an additional annoyance for the way i used to re-release it
The other alternative was to dont include the DLL's at all... but in this case you would be with the same problem you had (or worst because you would have to fgure by yourself that you need them and to search for them)
It was not my purpose to have the DLL's separated, but zinga burga did it this way and it become an additional annoyance for the way i used to re-release it
The other alternative was to dont include the DLL's at all... but in this case you would be with the same problem you had (or worst because you would have to fgure by yourself that you need them and to search for them)
sandungas
Developer
The attribute "sound" is just speculation, is something i realized while looking at rco format, but the speculation have a solid base
The theory starts like this, take a look at this table
Every row of the table have an hexadecimal value that is his TYPE (first byte)
Every column of the table have an hexadecimal value that is his ID (second byte)
https://www.psdevwiki.com/ps3/Template:RCO_TOC_entry_types
The names we see in the xml generated by rcomage doesnt exists inside the rco structure... all that names are converted to hexadecimal, in the same way that can be seen in that table, as example...
If i say 0x0908... this means <AnimTree> + <fireEvent>
The 09 is the TYPE (that belongs to <AnimTree>) and the 08 is the ID (of the <FireEvent>)
That order was given by the programmers that developed the rco format, and by looking at it it can be seen which features was developed first, the order is this:
0x01 MainTree
0x02 ScriptTree
0x03 TextTree
0x04 ImageTree
0x05 ModelTree
0x06 SoundTree
0x07 FontTree
0x08 ObjectTree
0x09 AnimTree
All this is identifyed, no doubt about it
Now take a look at this other table, this is used by the attributes that stores a reference
https://www.psdevwiki.com/ps3/Template:RCO_TOC_reference_types
0x04020000 image
0x04030000 model
0x04040000 unknown <------------------- !!!!!!!!!!!!
0x04050000 font
0x04060000 unknown
0x04070000 object2
0x04080000 anim
0x04090000 object
See the pattern ?, both tables are following the same order
What goes after... image ---> model ---> HERE ? ---> font
The reference type 0x04040000 seems to be specific for sounds (it allows to load a sound from <SoundTree>)... sadly never was used in the .RCO files from official PSP/PS3 firmwares
The sounds in PSP and PS3 firmwares are "triggered" by a prx/sprx... but it seems to be because the prx/sprx is generating that structure "on real time"... in the same way there are many rco files that have "missing" parts and the prx/sprx creates them on runtime
In other words, it seems the RCO format supports it, is designed for it
Sony never used it, and rcomage doesnt have any code to deal with it
The sounds in PSP and PS3 firmwares are "triggered" by a prx/sprx... but it seems to be because the prx/sprx is generating that structure "on real time"... in the same way there are many rco files that have "missing" parts and the prx/sprx creates them on runtime
In other words, it seems the RCO format supports it, is designed for it
Sony never used it, and rcomage doesnt have any code to deal with it
Last edited:
This entry must be referenced somewhere in a file if support exists. I guess its possible that it does not exist any more.
For example, you remember the icon_fixed_width/height references we found in pre retail xmls, I found those referenced in older explore plugin like 1.50 OFW, no longer in explore plugin anymor, so no support for that xml entry any more.
Then how do we test adding sound entries, does rcomage have support for 0x04040000 or is there any way to test this even with hex?
Off topic kind of. Is it possible that "debug" is one of the other unknowns? I ask because in the gaia sprx it uses "debug" in the same way that it uses "anim" .
For example, you remember the icon_fixed_width/height references we found in pre retail xmls, I found those referenced in older explore plugin like 1.50 OFW, no longer in explore plugin anymor, so no support for that xml entry any more.
Then how do we test adding sound entries, does rcomage have support for 0x04040000 or is there any way to test this even with hex?
Off topic kind of. Is it possible that "debug" is one of the other unknowns? I ask because in the gaia sprx it uses "debug" in the same way that it uses "anim" .
sandungas
Developer
All this rco files from PS3 firmware contains sounds
https://www.psdevwiki.com/ps3/RCOXML_ofw_sounds
We know the sprx associated with them are loading the sounds, and they should do it "by reference"
That reference types is a "must have" since the first day they starting designing the rco format, there is a reference type for every "Tree" we see in the xml generated by rcomage <ImageTree>, <SoundTree> etc...
Are needed to access the "Tree" content, is the only way to create a "link" with the "Trees"
For sounds we cant see how is made in the xml, it seems to be because is made in the .sprx
---------------------------
All the reference types have the same exact lenght, rcomage doesnt understands the sounds reference types, but is posible to compile an rco with rcomage using a different reference type (other suported by rcomage), then do a lot of hexediting and calculations to find the position and replace the reference type
Actually, is only needed to patch 1 byte... the huge pain is to find that byte
Edit: and few more bytes to patch the text string
The unknown reference type 0x04060000 ?... no, this reference type is longer to explain and is a bit special, but it works like the other reference types
They only contains the ID that indicates the "Tree", and a offset where is stored a text string (with things like... "image:tex_icon" ...or... "anim:anim_gameboot", etc...)
The gaia.qrc seems to have some debug handlers or interfaces, yes is interesting but i guess not much useful because incase of finding some hack or trick related with it we are going to be limited to use it while playing the gaia animation
@sandungas seems like the textFontSizeY only works in the psp
in the ps3 it has no effect but, seems like it is controlled by textOverrideUnk56 (it is not multiplying any value since i messed with the other textUnks and had no changes)
Here are some values that i used
0x15000100
0x14000100 Bigger than 0x15000100
0x16000100 Smaller than 0x15000100
0x17000100 Smaller than 0x160000100
0x18000100 Bigger than 0x17000010 and cuts the text
0x19000100 Smaller than 0x18000010 , bigger than the others and cuts the text
0x20000100 Seems like the same size of 0x19000100 and cuts the text
0x21000100 It doesnt show? and bugs the infos, and after side panels too, icon labels , impose screen
Maybe there is a text size tables, because it looks different thant the layouts overrides
Here what it looks like
So i didnt get how it works
I'm testing the text sizes because i will try to archieve
ps4 like save/load page
so i will need bigger texts
i throwed some random values in many textUnks but no effect only this one
in the ps3 it has no effect but, seems like it is controlled by textOverrideUnk56 (it is not multiplying any value since i messed with the other textUnks and had no changes)
Here are some values that i used
0x15000100
0x14000100 Bigger than 0x15000100
0x16000100 Smaller than 0x15000100
0x17000100 Smaller than 0x160000100
0x18000100 Bigger than 0x17000010 and cuts the text
0x19000100 Smaller than 0x18000010 , bigger than the others and cuts the text
0x20000100 Seems like the same size of 0x19000100 and cuts the text
0x21000100 It doesnt show? and bugs the infos, and after side panels too, icon labels , impose screen
Maybe there is a text size tables, because it looks different thant the layouts overrides
Here what it looks like
So i didnt get how it works
I'm testing the text sizes because i will try to archieve
ps4 like save/load page
so i will need bigger texts
i throwed some random values in many textUnks but no effect only this one
Last edited:
sandungas
Developer
Nice finding 
I will take a better look tomorrow, but by now i can tell you some hints
Usually the override attributes that are together belongs to coordinates and are X,Y,Z either for positions or sizes... but in this case could not be that way, textOverrideUnk56, textOverrideUnk57, and textOverrideUnk58 could not be related with each other
In lot of programs when dealing with text sizes (or font sizes) there is no need to tell the sizeX, sizeY, and sizeZ... you just need to tell the sizeY because sizeX is adjusted automatically (because the width of each character is specifyed in the font file) and sizeZ doesnt matters. Maybe this is one of that cases, you are changing sizeY but the other unknowns next to it could be something different
All the override attributes are specific for PS3 (the PSP doesnt even understands them). The purpose of them is to modify some of the other attributes in that same object that existed for PSP, most specifically the ones related with sizes or positions. So the actual attribute named textOverrideUnk56 could be modifying the other attribute named textFontSizeY. If this is true then the attribute named textOverrideUnk56 should be renamed to textOverrideFontSizeY
-------------------------
If you want to play around a bit with other unknown attributes related with text, try this ones (this is copyed from objectattribdef-ps3.ini)
I think are related with the "glow" effect. You know, like in PSP, actually there are used a lot in PS3 with the value 1 for colors (because the glow is always white), and 0 for positions (because the glow is perfectly aligned with the font)
I think they needs to be renamed like this (and the data type of the first 3 needs to be changed to "float")
But you know... to test this you need to use an official text that have the glow already enabled... and it needs to be a text you know very well
This way you can change his color, and his position a bit to disalign it... then in XMB with the dualshock you select the text to see if the glow effect have changed
I will take a better look tomorrow, but by now i can tell you some hints
Usually the override attributes that are together belongs to coordinates and are X,Y,Z either for positions or sizes... but in this case could not be that way, textOverrideUnk56, textOverrideUnk57, and textOverrideUnk58 could not be related with each other
In lot of programs when dealing with text sizes (or font sizes) there is no need to tell the sizeX, sizeY, and sizeZ... you just need to tell the sizeY because sizeX is adjusted automatically (because the width of each character is specifyed in the font file) and sizeZ doesnt matters. Maybe this is one of that cases, you are changing sizeY but the other unknowns next to it could be something different
All the override attributes are specific for PS3 (the PSP doesnt even understands them). The purpose of them is to modify some of the other attributes in that same object that existed for PSP, most specifically the ones related with sizes or positions. So the actual attribute named textOverrideUnk56 could be modifying the other attribute named textFontSizeY. If this is true then the attribute named textOverrideUnk56 should be renamed to textOverrideFontSizeY
-------------------------
If you want to play around a bit with other unknown attributes related with text, try this ones (this is copyed from objectattribdef-ps3.ini)
Code:
textUnk48 = unk
textUnk49 = unk
textUnk50 = unk
textUnkFloat51 = float
textUnkFloat52 = float
textUnkFloat53 = float
textUnkFloat54 = floatI think are related with the "glow" effect. You know, like in PSP, actually there are used a lot in PS3 with the value 1 for colors (because the glow is always white), and 0 for positions (because the glow is perfectly aligned with the font)
I think they needs to be renamed like this (and the data type of the first 3 needs to be changed to "float")
Code:
textGlowOffsetX = float
textGlowOffsetY = float
textGlowOffsetZ = float
textGlowColorScaleR = float
textGlowColorScaleG = float
textGlowColorScaleB = float
textGlowColorScaleA = floatBut you know... to test this you need to use an official text that have the glow already enabled... and it needs to be a text you know very well
This way you can change his color, and his position a bit to disalign it... then in XMB with the dualshock you select the text to see if the glow effect have changed
sandungas
Developer
Im taking a look at a radom rco (impose_plugin.rco) and it seems most of the <Text> objects uses this values:
Code:
textFontSizeY="10" textOverrideUnk56="0x14000000" textOverrideUnk57="0x3000000"To me it looks the firmware is loading the textFontSizeY="10", otherway there is no reason for that value to be there... but i dont know is a bit confusing
Im posting here the value of textOverrideUnk57="0x3000000" just to show that is loading a 0... but doesnt seems to be related with the text heights... anyway is doing something
And the overrides are loading this values (from the file layout_grid_table1080.txt), 0x14000100 is line 21 in the .txt (and the other values next up to line 28)
0x3000000 = 0 pixels (for 1080p resolution)
0x14000100 = 23 pixels (for 1080p resolution)
0x15000010 = 21 pixels (for 1080p resolution)
0x16000100 = 19 pixels (for 1080p resolution)
0x17000100 = 18 pixels (for 1080p resolution)
0x18000100 = 187 pixels (for 1080p resolution)
0x19000100 = 113 pixels (for 1080p resolution)
0x20000100 = 60 pixels (for 1080p resolution)
0x21000100 = 187 pixels (for 1080p resolution)
Edit:
probably this ones are going to fit better with the sizes you want
0x12000100 = 32 pixels (for 1080p resolution)
0x13000010 = 26 pixels (for 1080p resolution)
Last edited:
