PS3 [Attempt] Restoring XMB UI of Firmware 1.00 - 2.70 to 4.84+

[sandungas]

it went like this:
View attachment 19956

Awesome, this was unexpected, in the previous rco (with the black background) i realized about my mistake inmediatly when you posted the screenshot, the problem is the image i was trying to use had the black background

But this time i cant imagine what is happening, after reading your post i only dedicated a couple of minutes to review what i did trying to find a mistake, i have extracted the images back and forth GIM to PNG, checked GIM settings, and everything looks fine, so i dont know what to say by now
Im really interested in fnding wtf is happening with this image... i guess in the next days (or in the next hours, lol) i could explain why we are having this problem

Just for curiosity sake... this image is very special, the PS3 firmware only have 2 or 3 images like this (there is another with an horizontal arrow)
The special thing of this images is that is composed by "frames", all frames together stocked vertically
The responsible of "cropping" that frames is a .sprx and displays them in a sequence, like the frames of a video

BUT ! in the rco code there is not any known object able of doing this, in other words, is something pretty cool but we cant use it just modifying rco files because there is no known way to create them :'(

The only thing we can do is to modify the image with the frames, and we need to be very careful of keeping the official width/height because the .sprx needs to "crop" it "on the fly" and we dont know if the code is going to be able to crop correctly other images resized up or down
In other words... we are replacing an image composed by frames, and the frame size and total size of our custom image needs to be exactly the same "justincase"

... I just checked FW 2.17's explore_plugin_full.rco to see if the tex_playing icon was the same as the loading icon in the corner of the screen and ..... to our surprise it's the same as we currently have ... nothing has changed. But I understand that what you are doing is just a test, I think adding it to where it belonged will be perfect as it was meant to be a loading icon in the corner of the screen.

Well, i dont have a complete list of all the images that needs to be changed and where are located
Im used to some of them, specially this animations made with frames, always called my attention, so i knew the "waterdrop" animation existed, and i think at some point sony was using that "waterdrop" animation in the top-right corner

So... the other day i mentioned it to you, because i thought you could tell me more details about where it was used in old firmwares
Then we started with the frankenstein laboratory and one thing went to the other... but right now im not sure if what i was doing taking the old "busy" animation for the new "playing" animation is a good idea
Maybe there are other images like that in 4.84, im not complety sure
If someone can make a list or knows about other images like this (composed by frames), just tell

 

[Danxx444]

Awesome, this was unexpected, in the previous rco (with the black background) i realized about my mistake inmediatly when you posted the screenshot, the problem is the image i was trying to use had the black background

But this time i cant imagine what is happening, after reading your post i only dedicated a couple of minutes to review what i did trying to find a mistake, i have extracted the images back and forth GIM to PNG, checked GIM settings, and everything looks fine, so i dont know what to say by now
Im really interested in fnding wtf is happening with this image... i guess in the next days (or in the next hours, lol) i could explain why we are having this problem

Just for curiosity sake... this image is very special, the PS3 firmware only have 2 or 3 images like this (there is another with an horizontal arrow)
The special thing of this images is that is composed by "frames", all frames together stocked vertically
The responsible of "cropping" that frames is a .sprx and displays them in a sequence, like the frames of a video

BUT ! in the rco code there is not any known object able of doing this, in other words, is something pretty cool but we cant use it just modifying rco files because there is no known way to create them :'(

The only thing we can do is to modify the image with the frames, and we need to be very careful of keeping the official width/height because the .sprx needs to "crop" it "on the fly" and we dont know if the code is going to be able to crop correctly other images resized up or down
In other words... we are replacing an image composed by frames, and the frame size and total size of our custom image needs to be exactly the same "justincase"


Well, i dont have a complete list of all the images that needs to be changed and where are located
Im used to some of them, specially this animations made with frames, always called my attention, so i knew the "waterdrop" animation existed, and i think at some point sony was using that "waterdrop" animation in the top-right corner

So... the other day i mentioned it to you, because i thought you could tell me more details about where it was used in old firmwares
Then we started with the frankestein laboratory and one thing went to the other... but right now im not sure if what i was doing taking the old "busy" animation for the new "playing" animation is a good idea
Maybe there are other images like that in 4.84, im not complety sure
If someone can make a list or knows about other images like this (composed by frames), just tell

I never thought an image per frame would take so much work ... even though her animation is pretty cool. But today you made great progress, made it work and that's a big step.

 

[sandungas]

I never thought an image per frame would take so much work ... even though her animation is pretty cool. But today you made great progress, made it work and that's a big step.

For them probably is not an additional work, i always thought they have an "XMB emulator" for PC, with a toolbox at the right where can be seen all the names of objects, attributes, connections with the sprxs and lot of things like that
Is the only way to "build" an XMB really because is a huge mess (and that tool should be a mess too)
That tool existed since the PSX

For an animation like this, in his "xmb toolbox" should appear info like this:
frames = 30
frame size = 30x30 pixels
frames per second = 60
total time = infinite
etc... together with the standard attributes for position, size, and scalers for colors (to change the color of the image by code), etc....

Is the same kind of things that can be made with rco code... is just we dont know any "object" able to do it
So... it seems when they does one of this animations the "xmb toolbox" stores the info about it hardcoded inside the .sprx



-------------------
I imagined the problem in the previous rco with the "playing" image partiallly in black is related with indexed colors... or better said it could be the problem and the solution, not sure yet, i need to dedicate it some time to check it very well but im confident we can display it well

 

[Danxx444]

For them probably is not an additional work, i always thought they have an "XMB emulator" for PC, with a toolbox at the right where can be seen all the names of objects, attributes, connections with the sprxs and lot of things like that
Is the only way to "build" an XMB really because is a huge mess (and that tool should be a mess too)
That tool existed since the PSX

For an animation like this, in his "xmb toolbox" should appear info like this:
frames = 30
frame size = 30x30 pixels
frames per second = 60
total time = infinite
etc... together with the standard attributes for position, size, and scalers for colors (to change the color of the image by code), etc....

Is the same kind of things that can be made with rco code... is just we dont know any "object" able to do it
So... it seems when they does one of this animations the "xmb toolbox" stores the info about it hardcoded inside the .sprx



-------------------
I imagined the problem in the previous rco with the "playing" image partiallly in black is related with indexed colors... or better said it could be the problem and the solution, not sure yet, i need to dedicate it some time to check it very well but im confident we can display it well

Now i'm checking all rco's to find how many images per second there are working on the system ... i'm also sorting them out and attaching here later ... if you want to analyze.

 

[Danxx444]

@sandungas, in my search for frame images ... I extract all the rco's ... but this time from FW 2.51 ... they made a small change to the tex_busy image (the "3d" image of the clock) they removed The black background, it looks like if you use this one, will solve this black background problem.

 

[sandungas]

@sandungas, in my search for frame images ... I extract all the rco's ... but this time from FW 2.51 ... they made a small change to the tex_busy image (the "3d" image of the clock) they removed The black background, it looks like if you use this one, will solve this black background problem.

Hmmm, good finding, yes, it seems at that time they was doing changes in the "tex_busy", they changed it in between 2.17 and 2.51... and it seems the changes they did are related with transparent pixels

By now i dont want to use that image "blindly"... i want to find the reason why my previous test had problems with transparent pixels, also i need to check again the GIM settings and if the conversion to PNG is having some kind of problem with indexed colors
Dunno, is a personal challengue i guess... im used to all this and this is becoming a mistery in itself


*Edit:
btw, you are still using the problematic rcomage that have a limitation of max size 512 when doing the conversion from GIM to PNG :P
That images scaled down to 512 pixels are useless... if you rebuild the rco with them they will have pixelation or other problems

 

[Danxx444]

Hmmm, good finding, yes, it seems at that time they was doing changes in the "tex_busy", they changed it in between 2.17 and 2.51... and it seems the changes they did are related with transparent pixels

By now i dont want to use that image "blindly"... i want to find the reason why my previous test had problems with transparent pixels, also i need to check again the GIM settings and if the conversion to PNG is having some kind of problem with indexed colors
Dunno, is a personal challengue i guess... im used to all this and this is becoming a mistery in itself


*Edit:
btw, you are still using the problematic rcomage that have a limitation of max size 512 when doing the conversion from GIM to PNG :P
That images scaled down to 512 pixels are useless... if you rebuild the rco with them they will have pixelation or other problems

I hope you can solve your personal challenge .. I'm with you. I don't know if it really is rcomage (can be) I'm using rcomage_psdvwiki v1.1.2, maybe it's my PC, I don't know, I also have rcomage v1.8 and v1.9 ... but what I do most use is v1.1 2.

 

[Danxx444]

For them probably is not an additional work, i always thought they have an "XMB emulator" for PC, with a toolbox at the right where can be seen all the names of objects, attributes, connections with the sprxs and lot of things like that
Is the only way to "build" an XMB really because is a huge mess (and that tool should be a mess too)
That tool existed since the PSX

For an animation like this, in his "xmb toolbox" should appear info like this:
frames = 30
frame size = 30x30 pixels
frames per second = 60
total time = infinite
etc... together with the standard attributes for position, size, and scalers for colors (to change the color of the image by code), etc....

Is the same kind of things that can be made with rco code... is just we dont know any "object" able to do it
So... it seems when they does one of this animations the "xmb toolbox" stores the info about it hardcoded inside the .sprx



-------------------
I imagined the problem in the previous rco with the "playing" image partiallly in black is related with indexed colors... or better said it could be the problem and the solution, not sure yet, i need to dedicate it some time to check it very well but im confident we can display it well

hmm ... interesting this "XMB emulator" ... would be a great help if someone created a tool like this for you guys dev's to use ... would avoid many PS3 problems ... and not only that, but it would make it even easier on looks for answers to some "mysteries" about certain XMB animations.

 

[sandungas]

I hope you can solve your personal challenge .. I'm with you. I don't know if it really is rcomage (can be) I'm using rcomage_psdvwiki v1.1.2, maybe it's my PC, I don't know, I also have rcomage v1.8 and v1.9 ... but what I do most use is v1.1 2.

I think i got why you are having this problem, i wrote a lot of text with it... but you missed the explaination where it tells how to install it

First you need to extract the contents of rcomage-dev-v1.1.2.7z. This is the official rcomage (with the problems and outdated), i included it because i dont want to modify it
After that you need to overwrite some files of it... by using the files inside "Patches" folder

In other words... the contents of the "Patches" folder are the changes i did... and when you overwrite the official rcomage with my patches is like if you are updating it

After that try to extract the contents of this rco's again, and you will see the conversions to PNG doest reduces the images to 512 pixels (this was a problem of the default settings of gimconvert.exe... that is the responsible for the GIM image conversions), there are many more changes though, im just mentioning this because i can see you are still having the problem in your files when you extract images as PNG

 

[Danxx444]

I think i got why you are having this problem, i wrote a lot of text with it... but you missed the explaination where it tells how to install it

First you need to extract the contents of rcomage-dev-v1.1.2.7z. This is the official rcomage (with the problems and outdated), i included it because i dont want to modify it
After that you need to overwrite some files of it... by using the files inside "Patches" folder

In other words... the contents of the "Patches" folders are the changes i did... and when you overwrite the official rcomage with my patches is like if you are updating it

After that try to extract the contents of this rco's again, and you will see the conversions to PNG doest reduces the images to 512 pixels (this was a problem of the default settings of gimconvert.exe... that is the responsible for the GIM image conversions), there are many more changes though, im just mentioning this because i can see you are still having the problem in your files when you extract images as PNG

oh, I see ... now I know what "patch" is for ... I just thought (until then) that I didn't need to do anything with it..but okay, I'll do this update, thanks for this tip.

 

[sandungas]

I could have released the contents of the "patches" folder only + the other walls of text explaining things, tricks and tips
But i preferred to include the official rcomage because this way is a single download
Also, i dont want to modify the official rcomage because this way is very easy to have a control of other tweakers/developers interested in improving my rcomage versions (by updating the contents of the "patches" folder) with new findings of unknown attributes or things like that

And because is very easy to compare the official files with my "patches", this way everybody can see what i did

Edit 1:
Lets say... is like a community project made in a easy way for forums

Edit 2:
Actually, this was the original idea from zinga burga when he decided to load the rcomage setting from external plain .txt files and fill them with lot of "unknowns" names... he was making available for "non programmers" to update it just by editing a .txt incase someone found new "unknowns"

 

[sandungas]

I found the mistake and it worths an explain
I knew the image "tex_playing" from modern firmwares made with frames is made with pure white colors only and it have lot of transparent pixels, because i posted it in this page in psdevwiki many time ago
https://www.psdevwiki.com/ps3/Talk:GimConv#Default_settings_Talk
In the section talking about gimconv problems there is a mention to it with a link to imgur, this way
tex_playing.gim (30x900 pixels) http://imgur.com/2rjGdbe
Usually, when talking about images in wiki or here in the forum we can display them as a preview, but with this image it looks weird because it looks like empty (because are white pixels on top of white pixels)

Like this "empty space" above... there is the "tex_playing.png" from 484 in it... click and hold the image with the mouse left button (and dont release the button), then move it to the left on top of the black background of the forum to see it :P

Ok... so if you are going to overlap an image like that, where only a few pixels contains color info (but most of the others are fully transparent)... it could be a bit weird to use a shadow image at bottom fully opaque (without transparent pixels).. and then do the calculation of transparency in between the 2 images with code... this sounds like... too much weird
But this is how it works on 4.84 !
"tex_playing" only have white pixels and lot of transparent pixels
"tex_playing_shadow" is fully opaque with a black background

So... in my last test, when you advised me that it was needed to change the "tex_playing" from 2.17 firmware to transparent... i guessed the "tex_playing_shadow" was needed to be converted to transparent too
And that was my mistake, i guessed wrong... right now i dont get why they did it this way, and is making me wonder if there is some setting for that "interaction" in between the main image and his shadow

----------------------------------------------------
Anyway... there are 2 different ways to do it, with the images of firmware 2.17, or with the images of firmware 2.52, so i made 2 different versions of explore_plugin_full for 4.84
Inside the .zip there are the files i been working with, and some .txt with notes... are good for learning purposes to see what i was doing, read the talk of this thread again while looking at the files and you will understand better my posts

FILE: https://www.sendspace.com/file/9j6c5j

Spoiler

The gim settings for "tex_busy.gim" and "tex_busy_shadow.gim" in 2.17 are based on -ps3rgba8888 but in 2.51 are based on -ps3dxt5, the image looks different, and the gim settings are different too
The GIM settings used by "tex_playing.gim" and "tex_playing_shadow.gim" for 4.84 are using the profile -ps3rgba8888. I was sure about this, and all experiments i did was using the correct gim settings for 4.84

 

[Danxx444]

I found the mistake and it worths an explain
I knew the image "tex_playing" from modern firmwares made with frames is made with pure white colors only and it have lot of transparent pixels, because i posted it in this page in psdevwiki many time ago
https://www.psdevwiki.com/ps3/Talk:GimConv#Default_settings_Talk
In the section talking about gimconv problems there is a mention to it with a link to imgur, this way
tex_playing.gim (30x900 pixels) http://imgur.com/2rjGdbe
Usually, when talking about images in wiki or here in the forum we can display them as a preview, but with this image it looks weird because it looks like empty (because are white pixels on top of white pixels)

Like this "empty space" above... there is the "tex_playing.png" from 484 in it... click and hold the image with the mouse left button (and dont release the button), then move it to the left on top of the black background of the forum to see it :P

Ok... so if you are going to overlap an image like that, where only a few pixels contains color info (but most of the others are fully transparent)... it could be a bit weird to use a shadow image at bottom fully opaque (without transparent pixels).. and then do the calculation of transparency in between the 2 images with code... this sounds like... too much weird
But this is how it works on 4.84 !
"tex_playing" only have white pixels and lot of transparent pixels
"tex_playing_shadow" is fully opaque with a black background

So... in my last test, when you advised me that it was needed to change the "tex_playing" from 2.17 firmware to transparent... i guessed the "tex_playing_shadow" was needed to be converted to transparent too
And that was my mistake, i guessed wrong... right now i dont get why they did it this way, and is making me wonder if there is some setting for that "interaction" in between the main image and his shadow

----------------------------------------------------
Anyway... there are 2 different ways to do it, with the images of firmware 2.17, or with the images of firmware 2.52, so i made 2 different versions of explore_plugin_full for 4.84
Inside the .zip there are the files i been working with, and some .txt with notes... are good for learning purposes to see what i was doing, read the talk of this thread again while looking at the files and you will understand better my posts

FILE: https://www.sendspace.com/file/9j6c5j

Spoiler

The gim settings for "tex_busy.gim" and "tex_busy_shadow.gim" in 2.17 are based on -ps3rgba8888 but in 2.51 are based on -ps3dxt5, the image looks different, and the gim settings are different too
The GIM settings used by "tex_playing.gim" and "tex_playing_shadow.gim" for 4.84 are using the profile -ps3rgba8888. I was sure about this, and all experiments i did was using the correct gim settings for 4.84

I had seen this tex_playing image before and I always found it kind of weird because it just seems to be "empty" just like you mentioned..but finally, I just tested the files ... the first image is from tex_busy2.17 for tex_playing4.84

and the second image is from tex_busy2.51 for tex_playing4.84

.... this The third image is a bit curious, since yesterday's first test was like this ... but I forgot to warn you.

 

[Danxx444]

@sandungas Amazing... no wonder if the icon tex_busy2.51 for 4.84 doesn't look like a perfect circle, the picture is just like that I took a look here in this video:

...and it seems to be normal ... because where you put it to work on this test is not the your correct place, but still very good.

EDIT:Now that I understand better ... this little black tip of the shadow above circle, represents the shadow of the spinning pointer ... is not a defect of the image (i think)

 

[Danxx444]

 

[Danxx444]

So... in my last test, when you advised me that it was needed to change the "tex_playing" from 2.17 firmware to transparent... i guessed the "tex_playing_shadow" was needed to be converted to transparent too
And that was my mistake, i guessed wrong... right now i dont get why they did it this way, and is making me wonder if there is some setting for that "interaction" in between the main image and his shadow

Yes, there is an interaction between them ... a part of the shadow represents the small pointer where, when it is rotating, the shadow follows it, which is why the icon does not appear to be a perfect circle ... in short, the shadow It's not simply a static black background, it also rotates along with your icon.

 

[pinky]

I don't mess with the shadow icons. I'm not sure if you're meant to manipulate them. when I tried adding shadow to an icon that already had a shadow icon counterpart, the system softbricked. this was with the system_plugin.rco.

my rule of thumb is that when changing colors for thing, replace a colored icon with another color icon (don't overlap or both colors will be combined); if it's a white icon, change the color through the xml.

 

[Danxx444]

Now what's left to do is ... analyze some details to make it work in system_plugin.rco with its old animation (only appears when the system loads and then disappears).

 

[pinky]

I haven't read the rest of this thread, but are you talking about the clock? I seem to recall that at least.

 

[Danxx444]

I don't mess with the shadow icons. I'm not sure if you're meant to manipulate them. when I tried adding shadow to an icon that already had a shadow icon counterpart, the system softbricked. this was with the system_plugin.rco.

my rule of thumb is that when changing colors for thing, replace a colored icon with another color icon (don't overlap or both colors will be combined); if it's a white icon, change the color through the xml.

maybe we could make it "invisible"?