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

Status
Not open for further replies.
Cypher_CG89 said:
Yes, it's easy and simple.





Wrong... disable ALPHA:float 0 particles.mnu disables the these, find every file and disable it or it will still show in other set environments.

@raidriar attached is a no particles all black background wave. I made this ages ago for someone on here and works fine but the only background colour is black as I replaced them all to black but it would be quite easy to just set one of them to black if wanted.
Click to expand...
Thanks for reminding it, is something i mentioned at Aug 1, 2019 ;)
https://www.psx-place.com/threads/xmb-waves.18807/#post-196999
sandungas said:
Well, what i said before should work, is needed to replace the alpha values by zero so the particles becomes fully transparent (invisibles)
Click to expand...

Technically i dont like it though... is like a placebo, the particles are still there is just are invisibles , but yeah if we dont have a better solution and that works is fine :D
 
sandungas said:
This happened when replacing all the "emit" values to zero ?, not sure why hapens that, maybe is because the particles emitter starts emitting them so fast that some of them "escapes" from it before the .mnu settings (disabling them) is loaded
Dunno, but yeah, i still think the particles.elf "should" have a mnu setting to disable them completly, i bet it exists because is something useful for them when they was developing and debugging the XMB

Well... then, if we are entering in other destructive scenarios (modifying particles.elf)...
What we was trying eventually in one of the rfankenstests was to replace the particles.elf by spline.elf with the hope of having 2 waves. We also tryed the opposite, having 2 particles.elf playing together (and no wave)

That tests was not successfull (but we are not sure why), if i remember right in one of them the particles (or the wave) dissapeared completly... most probably because we made the .elf file unavailable (by damaging his path) or we corrupted it, or it was an incompatible firmware version (i was using other .elf from older firmware versions)

Long story short... from all this tests, the most easyer you can do at this point is to delete the particles.elf
You are risking a XMB crash and a firmware reinstall though, but is easy to do

In the files extracted by XForge... open the lines.xml in notepad++ (this is the control file, located at root of the extraction folder)
Locate the line where appears particles.elf in the xml..... delete that line from the xml... and thats all... build the qrc using that xml
Click to expand...
No this is the default behavior without modifying lines.qrc. Simply set theme to classic instead of original to replicate behavior
 
At this point i think the idea about deleting particles.elf worths a try, it was very tricky to do it before, but since the release of XForge tool (published yesterday) is easy

Incase it works is the most efficient way to do it... because is going to reduce a bit the the processor/s workload. Not sure if CELL or RSX or both... but for sure if we delete the .elf is going to be imposible to load it
The doubt is if the firmware have some check for the .elf file that could cause a firmware crash... but i guess there is only one way to know it
 
But the fact that there is a PARTICLES_SPE.mnu means the particles.elf is running inside a CELL SPU coprocessor (and the spline.elf for the wave probably in another SPU)
The goal of deleting the .elf files is to prevent CELL loading them, this is going to reduce CELL workload for sure

I know the workload caused by the wave and particles is notable because time ago i was doing temperature tests with/without them and it can be seen there is a difference in the temperature of CELL and RSX
This workload reduction would only apply to XMB and other enviroments (not inside games/apps) so doesnt matters much because we dont spend much time in XMB... but anyway if the goal is to disable them i prefer to kill them instead of only hiding them :D
 
I had tonnes of ways of disabling the particles and wave in the sprx, one of those will probably work in the qrc. I was removing calls to vpo/fpos which is not the same as removing them completely in the qrc. Maybe we need to make or find a replacement we can use to dummy them. Not sure, not at my pc now.
 
Cypher_CG89 said:
Yes, it's easy and simple.





Wrong... disable ALPHA:float 0 particles.mnu disables the these, find every file and disable it or it will still show in other set environments.

@raidriar attached is a no particles all black background wave. I made this ages ago for someone on here and works fine but the only background colour is black as I replaced them all to black but it would be quite easy to just set one of them to black if wanted.
Click to expand...
This one is a little weird compared to mine. At gameboot it raises the xmb waves to the front a little bit, in mine it simply removes the xmb waves altogether on gameboot. I will have to make a mod again it seems.

FYI: replacing particles.elf with a 0 byte dummy file gives soft brick, so don't do that.
 
Last edited:
raidriar said:
FYI: replacing particles.elf with a 0 byte dummy file gives soft brick, so don't do that.
Click to expand...
And deleting it ? (in the xml control file generated by XForge)

Anyway, i guess compiling a particles.elf like the sample below would be the cleanest solution
The firmware functions that are going to try to load it are going to find it, the file is valid, the firmware loads and executes it, and it does nothing
Code: 
#INCLUDE whatever

main (){
   break;
}

Another btw... the PARTICLES.mnu files can be converted to a dummy this way
Only keep this line
Code: 
#MNU_1.0
That line is mandatory. Without it the firmware crashes, and with it doesnt crashes, we tested it
The idea is (after disabling particles.elf) to convert all the PARTICLES.mnu to dummies that way
But actually... you can do it pretty similar for what you are doing now, this way:
Code: 
#MNU_1.0
global alpha:float:0

You only need that setting for what you are trying to achieve
The other settings removed are not critical, because the particles.elf have all the setting with the default values "hardcoded" inside it
In other words... if you remove all the settings from a .mnu file the .elf continues working normally but using the default values
 
motrooke said:
Um, Is there anyway to uh Disable the Wave Blur When Going into a Menu?
Click to expand...
I remembered how I did that mod, it was in an RCO too, it's not an sprx patch so it will work on HEN and CFW universally. :)


This "blur" line needs to be removed in the custom_render_plugin.rco...simple :)

upload_2020-4-7_1-2-36.png


OR:
If you are on CFW, instead you can disable it in the custom_render_plugin.sprx by zero filling the word "blur" out here:

upload_2020-4-7_3-2-23.png



Here you can see I am in a folder with no blur.

blur.jpg



RCO attached that will work on all recent CFW/HFW back to at least 4.80.
 

Attachments

Last edited:
@Danxx444 I can't remember was it you who wanted to change the way the background is pink during the coldboot, and then it changes to the user set background when the XMB loads? :)

Cos I just figured it out thanks to that new tool Xforge. :)

bg.jpg


bg2.jpg
 
DeViL303 said:
@Danxx444 I can't remember was it you who wanted to change the way the background is pink during the coldboot, and then it changes to the user set background when the XMB loads? :)

Cos I just figured it out thanks to that new tool Xforge. :)

View attachment 25178

View attachment 25179
Click to expand...

How that's interresting, because it always bothered me to start with the month color and just when xmb loads it got the users colors.

Can you share this
 
LuanTeles said:
How that's interresting, because it always bothered me to start with the month color and just when xmb loads it got the users colors.

Can you share this
Click to expand...
It's far from perfect as its a static patch and will not change with the XMB setting. This mod works best for someone like me who always leaves it on one color or someone who just wants to change the pink to something else.

It so simple :D Basically what I just learned using the new app Xforge is that 04.dds from the classic theme is used for the boot up background. So you can change that to any dds you want and have your boot up that color. :)

It might look good in black or something for your Pro Mod, this way people can use option 4 to choose a black background too, who wants pink anyway?

Change this one to whatever you want.

upload_2020-4-7_2-58-21.png
 
DeViL303 said:
It's far from perfect as its a static patch and will not change with the XMB setting. This mod works best for someone like me who always leaves it on one color or someone who just wants to change the pink to something else.

It so simple :D Basically what I just learned using the new app Xforge is that 04.dds from the classic theme is used for the boot up background. So you can change that to any dds you want and have your boot up that color. :)

It might look good in black or something for your Pro Mod, this way people can use option 4 to choose a black background too, who wants pink anyway?

Change this one to whatever you want.

View attachment 25180
Click to expand...
So we could say for the coolboot is always april ?, lol


Btw, have you tryed to change the clock to "night time" ?... remember there are 2 background wallpapers for april
 
sandungas said:
So we could say for the coolboot is always april ?, lol


Btw, have you tryed to change the clock to "night time" ?... remember there are 2 background wallpapers for april
Click to expand...
Ah feck, thats it. We would need to change them all. :D

sandungas said:
Wait... im wondering if was used april in the coldboot in that test.... just because we are in april ? o_O
Click to expand...
Yeah, I had not made that connection yet...dam.. :)
 
sandungas said:
So we could say for the coolboot is always april ?, lol


Btw, have you tryed to change the clock to "night time" ?... remember there are 2 background wallpapers for april
Click to expand...
Actually no, my date is set wrong, its set to march and still uses 04.dds for the coldboot, so yes, it is always april for the coldboot, i think . lol :)
 
I dont remember to see the coldboot using bright colors though (like the intense red or yellows used in some, or the other that is pretty much like white)
Some of you remember to see the official coldboot starting in white ? o_O

I guess the colors from the background wallapaper are affected by some MNU settings (BACKGROUND.mnu or others) that "soften" them a lot... to the point the real color (from the dds file) is barelly notable
 
@DeViL303 i'm not on my pc now, but i was messing with the Xforce two weeks ago the beta one, and i found i didn't remember which qrc but its called side menu, or menu i'm not sure, with 12 colors one per line in a single image, i bet it is for the side menu preview in color themes that some months ago we are searching. for

@Louay
 
Last edited:
LuanTeles said:
@DeViL303 i'm not on my pc now, but i was messing with the Xforce two weeks ago the beta one, and i found i didn't remember which qrc but its called side menu, or menu i'm not sure, with 12 colors one per line in a single image, i bet it is for the side menu preview in color themes that some months ago we are searching. for

@Louay
Click to expand...
Think you mean this one?

upload_2020-4-7_3-55-43.png


Tried making it all black:
upload_2020-4-7_3-56-19.png


No luck though :(

upload_2020-4-7_3-57-2.png
 
Status
Not open for further replies.

Similar threads

Back
Top