PS3 [Discussion] 0.90 DECR XMB Entries on 4.84

sandungas said:
Right now im thinking is displayed fine in your test because you reduced the size (unpurposelly though, but it looks you won the lottery)
Click to expand...
Yes and no, I reduced size, but I did it on purpose, as it would not load big images, but I tested smaller ones and they worked. I had to go all the way down to 99x93 , I think 100x94 would not work.. but maybe I messed up test as I have so many files..

I used -ps3rgba8888 , but Im not sure I needed to, I think size was issue.

I have only added one image, maybe you can help me with adding both and getting ti to change, im not great with rcos.

I just added it like this, quick and easy way:
Code: 
<Plane name="impose_back_color" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="0" sizeScaleX="0.25" sizeScaleY="0.25" sizeScaleZ="0.25" anchorMode="0x0" onInit="nothing" positionOverrideX="0x4000100" positionOverrideY="0x5000100" positionOverrideZ="0x0" sizeOverrideX="0x7000000" sizeOverrideY="0x8000000" sizeOverrideZ="0x0" planeImage="image:tex_ps3black" planeResizeMode="0x0"></Plane>


But then I am getting white box on battery icons, I don't know why as I have not touched that at all. I think maybe there is only certain amount of ram available for that screen or something, and once it goes over that then images become corrupt..or maybe another explanation?

EDIT: Thanks for offsets, I still cant figure it out :)

The reason I used -ps3rgba8888 was simply because all other icons in that rco used that option.

Maybe if we compress the others, we can make this one bigger, I will test.
 
Last edited:
What im going to say is speculative
It seems in firmware 0.90 the .sprx is who decides when are loaded the "Plane" objects named "controller_bg_0" and "playstation3_bg_0"

In the video of 0.90 uploaded to youtube by pixelbutts it can be seen how the images changes when you select the texts... but in the rco doesnt exist any "link" in between that images and the texts

And firmware 4.84 doesnt seems to have that "link" in the sprx... so long story short.... we cant make that "swap" of images :(
Or better said... we cant make it in the same way that it was made in 0.90
Maybe there is an alternative way though... i was thinking in it but this is another story, harder to achieve and requiring lot of tests and im just speculating

For this reason i suggest you to start the tests with only 1 image, in the tests i made i always used 2 and i regret because now im not sure if that was one of the reasons why it failed :(

-------------------------------
This is what i did in the first test: https://pastebin.com/E8MygVXp
Copypaste it to a real xml in your PC (or download the file).... and scroll most to right because i added some notes as comment for myself with the overrides conversions, by readiing that comments you will see better what i changed
I just added 4 lines
The positions and sizes was exactly the same than 0.90 (but using different overrides to load the values i needed from the .txt files)
The GIM files was exactly the ones from 0.90

So i was confident it was going to work... but it was displayed as a white image :crybaby:

Then i build another rco... where i changed the GIM settings to -ps3rgba8888 and positionOverrideX=0x5000100(line5+1=0) (to center the image)
In 0.90 the images are located at left and the texts at right, but in 4.84 the texts are at center, so i thought it was going to look better with the images centered too

But it was displayed as a white image :crybaby:

At that point i knew there was a lot of things i "could" try... but none of them had a potential success ratio like the previous 2 tests... so i was a bit confused and giving myself some time to review everything and eventually (with a bit of luck) finding some weirdness

Yesterday i was looking at it, but instead of focusing in this problem i started converting the overrides of the controller charging leds
Before yesterday i knew and i had proofs of how works the "grid" overrides, but yesterday i found proof of the other "factor" overrides... then everything started making sense about overrides. It was something i was looking since months ago, so i was a bit excited :D

So lets say... i was back at step 1 with this problem of the white images... so today when i saw your screenshot i was surprised
 
Last edited:
well yes, your overrides work perfectly with my small gim. I did scale it down a bit as it was too big at that resolution.

The way I figured it out was, I tried with tex_red , and it worked, gave me full screen stretched tex red as background, so then I knew it was possible if the source image was correct, I then tested with same conversion options and it still would not, work, then I messed with bit depth of image, that did not help, then final thing was resolution or file size, so I shrunk it down and it worked. so that is story of story of how I won lottery. :)


Here is where Im at, maybe you can see if we can get resolution higher somehow? and fix battery icon, even though I never touched it afaik.

tex_ps3black2.png
 

Attachments

Hold on, something strange... If I add the image to image tree as last item, then it doesn't load, and is white, if I add it as first item, then the battery icon is white... so now I need to check resolutions again, as I did not think position on list made any difference... so not sure if I was consistent during tests.. feck..

There must be some kind of limit on images, either amount of them allowed , file size of total of all images, limited RAM, or something else.. pixels displayed.. I dont know.
 
Last edited:
DeViL303 said:
Hold on, something strange... If I add the image to image tree as last item, then it doesn't load, and is white, if I add it as first item, then the battery icon is white... so now I need to check resolutions again, as I did not think position on list made any difference... so not sure if I was consistent during tests.. feck..

There must be some kind of limit on images, either amount of them allowed , file size of total of all images, limited RAM, or something else.. pixels displayed.. I dont know.
Click to expand...
The image displayed in white here is tex_controller_number.gim (not tex_red.gim)
The tex_red.gim image is the tiny red square, is displayed fine here, on top of the white image
tex_ps3black2-png.15488

Im mentioning it because the last image under the <ImageTree> is tex_red.gim

What i mean is... by adding the new image tex_ps3black.gim (from 0.90) at first position of the list it doesnt "breaks" the last image of the list (tex_red.gim), but the previous to the last (tex_controller_number.gim)

And this... doesnt makes sense right now to me, i dont get it o_O
 
sandungas said:
The image displayed in white here is tex_controller_number.gim (not tex_red.gim)
The tex_red.gim image is the tiny red square, is displayed fine here, on top of the white image
tex_ps3black2-png.15488

Im mentioning it because the last image under the <ImageTree> is tex_red.gim

What i mean is... by adding the new image tex_ps3black.gim (from 0.90) at first position of the list it doesnt "breaks" the last image of the list (tex_red.gim), but the previous to the last (tex_controller_number.gim)

And this... doesnt makes sense right now to me, i dont get it o_O
Click to expand...
EDIT: i was wrong there, not sure, stealing other icons slot or ram? strange..
 
DeViL303 said:
EDIT: i was wrong there, not sure, stealing other icons slot or ram? strange..
Click to expand...
Im thinking it could be related with a ram alignment, dunno but usually is needed to follow "some obscure rules" to fill the ram with images
Is like a tetris, and the goal is to not create "gaps" in between images

But is very weird because this short sentence in itself is exposing the problem
DeViL303 said:
Hold on, something strange... If I add the image to image tree as last item, then it doesn't load
Click to expand...

So you had the image at first position of <ImageTree> and everything was displayed fine... but simply by changing it to last position it stopped working ?
But the others continued working (so incase there was some bad alignment in ram the others was not affected?)

-----------
Dunno, but we are missing something
And i bet the XMB and RCO formats are not making any restriction about pixel sizes and/or bytes sizes of the images
Actually, i remember there are a couple of images that are bigger than 1920x1080... so if there is some restriction is made by the .sprx (but not a general rule)

Edit:
Actually... the original images from 0.90 have a resolution of 640x600 pixels, so we know the XMB can display them at that size
 
Last edited:
sandungas said:
So you had the image at first position of <ImageTree> and everything was displayed fine... but simply by changing it to last position it stopped working ?
But the others continued working (so incase there was some bad alignment in ram the others was not affected?)
Click to expand...
When I move PS3 image to top, IT works fine, but battery icon goes white, if I move it to bottom, then battery icon is fine and ps3 image is white, so only one will work at a time basically.

sandungas said:
Dunno, but we are missing something
And i bet the XMB and RCO formats are not making any restriction about pixel sizes and/or bytes sizes of the images
Click to expand...
sandungas said:
Edit:
Actually... the original images from 0.90 have a resolution of 640x600 pixels, so we know the XMB can display them at that size
Click to expand...

Normally that's true, but the impose is used ingame, so is a little different, maybe it is ultra restricted (even on xmb) , also there was a lot less on xmb back then on 0.90, so maybe it was not so restricted, also was maybe why they removed them in v1.00. Imagine sony devs saying... "why we wasting 0.5MB (or whatever) RAM on some stupid images when we need every little bit for games" ..so they took it out.. only guessing.. but it looks nice, and they removed it for a reason..

EDIT: You know I think it must be RAM, because I can display tex_red, at full screen as background, no prob, but that image is already in there, so not adding anything except text to rco-xml.
 
Last edited:
DeViL303 said:
When I move PS3 image to top, IT works fine, but battery icon goes white, if I move it to bottom, then battery icon is fine and ps3 image is white, so only one will work at a time basically.
Click to expand...
Oki, but... the broken image in your screenshot is not the battery icon
The battery icon is tricky, is composed by 4 "frames" , it seems the .sprx "crops" the frames and displays only one of them with a "tilt" animation effect

The broken image is tex_controller_number.gim (the filename have the tail "number" because it have the numbers 1,2,3,4 "printed" in it)
Is important to know his name because is located before "tex_red.gim" in the official list

So... the relationship of how an image breaks other image based in his position in the <ImageTree> is not a simple "first breaks last" (and last breaks first)

----------
Btw, there are 4 official images that can be removed... are 4 shadows with an horrible quality that looks like a fart in the night, i bet by removing them the screen will look the same
Can be removed by deleting this lines:
Code: 
<Image name="tex_battery_shadow" src="Images\tex_battery_shadow.gim" format="gim" compression="zlib" unknownByte="0" />
<Image name="tex_charge_arrow_shadow" src="Images\tex_charge_arrow_shadow.gim" format="gim" compression="zlib" unknownByte="0" />
<Image name="tex_controller_shadow" src="Images\tex_controller_shadow.gim" format="gim" compression="zlib" unknownByte="0" />
<Image name="tex_error_batsu_shadow" src="Images\tex_error_batsu_shadow.gim" format="gim" compression="zlib" unknownByte="0" />

<Plane name="impose_pad_battery_notice_arrow_shadow" planeImage="image:tex_charge_arrow_shadow"></Plane>
<Plane name="impose_pad_battery_notice_padicon_shadow" planeImage="image:tex_controller_shadow"></Plane>
<Plane name="impose_pad_battery_notice_error_shadow" planeImage="image:tex_error_batsu_shadow"></Plane>
<Plane name="impose_pad_battery_notice_icon_shadow" planeImage="image:tex_battery_shadow"></Plane>
 
Last edited:
Hmmm, i just had an idea (blind shot really)
There is an unknown "Image" attribute that was added to rco format specifically for PS3 (not available for PSP), im thinking it could be related with some special alignment of ram enabled/disabled for the image

If you make some more tests try in one of them to enable it for the image we are adding from 0.90 this way (is the last attribute most at the right unknownByte="1")
Code: 
<Image name="tex_ps3black" src="Images\tex_ps3black.gim" format="gim" compression="zlib" unknownByte="1" />

The value looks like a flag, only values posibles are 0 or 1, and most of the images uses 0.... but i remember to see some images using 1 and right now im wondering if that images i found using 1 had big sizes
 
sandungas said:
Hmmm, i just had an idea (blind shot really)
There is an unknown "Image" attribute that was added to rco format specifically for PS3 (not available for PSP), im thinking it could be related with some special alignment of ram enabled/disabled for the image

If you make some more tests try in one of them to enable it for the image we are adding from 0.90 this way (is the last attribute most at the right unknownByte="1")
Code: 
<Image name="tex_ps3black" src="Images\tex_ps3black.gim" format="gim" compression="zlib" unknownByte="1" />

The value looks like a flag, only values posibles are 0 or 1, and most of the images uses 0.... but i remember to see some images using 1 and right now im wondering if that images i found using 1 had big sizes
Click to expand...
I did some more testing and it does seem filesize related, or something like that. I removed the icons you said, still the same. Then I compressed most icons with dxt5 and got rco down to 40kb, all working fine, Then I pushed ps3 image up to 240x225, ran it through PNG gauntlet first to optimize it, saved 20kb on png, then repacked rco to 47kb, and its working good.

upload_2019-3-21_19-44-22.png



EDIT: Updated attached file to v2, now it has same image on yes no screen too.


EDIT 2: Pushed image up to 300x280 and got this:
upload_2019-3-21_20-30-25.png


Now the little battery icon is white... rco at 50kb and its no good, at 47kb its ok.. Note the attached 47kb file is working fine, just showing my failed test in the image.
 

Attachments

Last edited:
Having another look through, seems the only one that doesn't work is the Flash Player entry, all it is on the XMB is a spinning circle indicating whatever its pointing to doesn't exist on the system.

EDIT: The "Path" is different because i'd been experimenting with it.

s.png
 
There's also the "call xmb_plugin_debug - test1" option that looks like it was purely a test function, but the plugin it calls is nowhere to be found in the 0.90 and 101.001 DECR Firmware.
 
dazzaXx said:
Having another look through, seems the only one that doesn't work is the Flash Player entry, all it is on the XMB is a spinning circle indicating whatever its pointing to doesn't exist on the system.

EDIT: The "Path" is different because i'd been experimenting with it.

View attachment 15603
Click to expand...
The path should probably have a "/" at the start too like other paths i expect.

The reason its spinning is just because the icon does not exist, so you can just put in an existing icon, obviously that will not effect the function of it at all,

dazzaXx said:
There's also the "call xmb_plugin_debug - test1" option that looks like it was purely a test function, but the plugin it calls is nowhere to be found in the 0.90 and 101.001 DECR Firmware.
Click to expand...
That sprx is in one of the other early dumps. I did a couple of tests but not very much at all. You need to resign it with latest keys, You can do that by using scetool with the template command and using a 4.84 sprx as a template.
 
I think they all were posted in my 0.90 DECR thread, there should be a link there.

Here is the one from 0.85.010 (probably best to get all the dumps yourself as I'm not 100% if I resigned this one or what i did to it.
 

Attachments

Last edited:
DeViL303 said:
I think they all were posted in my 0.90 DECR thread, there should be a link there.

I grabbed them all if you have any issues i could upload them somewhere.
View attachment 15606

Here is the one from 0.85.010 (probably best to get all the dumps yourself as I'm not 100% if I resigned this one or what i did to it.
Click to expand...
I have 085.010, but couldnt figure out how to extract it since it came as these 3 files and not a .pup
Captusre.PNG
 
You must log in or register to reply here.

Similar threads

Back
Top