PS3 [Research] Modifying the Coldboot/Gameboot Sequence (custom_render_plugin.sprx/rco)

DeViL303 said:
Black screen again unfortunately. FTP still working so not a soft brick. We could try double particles i guess although that is not as cool.
Click to expand...
Shhhhhit, never minds, double particles i guess is going to do the same, and i like the wave too much, so is not worthy to try the double particles imo

From the files i uploaded, the version where i made the "clean" is ready to add a different .elf btw
I dont know what... but the firmware is going to run it at boot
To me that looks like a juicy vector attack... so dont know but could be used for some experiments, to try to trigger an exploit in OFW, or to automatize something for HEN, dunno
But maybe there is some security restriction to prevent exploits... dunno, maybe this is the reason why our experiment failed :crybaby:

While doing this i realized the requirements to replace files, is needed to apply 2 patches
One patch is the file itself (should be equal or smaller than the file that is going to be patched)
The other patch needs to be made in the TOC, is needed to change the length of the new file
And thats all



Edit:
Im mentioning this because we was talking before about replacing the "DebugGUI" files in the QRC structure by the files from Q-games visualizer, in that case both files had the exact same size, so the patching is straightforward

And now i realized if the files have different size is a bit more pita, but yeah, it should work, we can replace all the others :)
 
Last edited:
Cypher_CG89 said:
I haven't had a chance to fully look into it properly, just the lines files that @Danxx444 gave me, I made a few note's about them somewhere either on this PC or my other one.

And what I really want to do is to look at every lines qrc file upto 2.80 to see exactly where and when changes were made> eg like things added, MNU settings changed> stuff like that.

Then I want to look at all lines.qrc files from 2.80 to 4.40 from the same reasons, but not just the lines.qrc but the corisponding game_ext_plugin.sprx's and custom_render.rcos as well from 1.00 to 2.80 then 2.80 to 4.40.

As you can imagin that is a lot of files and stuff to look through but mainly want to start from 1.00 > 2.80's lines.qrc, game_ext_plugin.sprx and custom_render.rco first, and that still quite a few files.

Also any other files that could/are releated to this.... Any suggestions on other files to look at are welcome ... for example I forgot which file can be found info on the theme settings... this is also a good place to go looking at what exactly is been changed, called upon and any overides its applying to the lines.qrc.

I need to set aside some time to do this fully, nose to the grindstone so to speak (or nose to PC screen and keyboard in this case lol) and at the minute I don't have much spare time to fully dedicate to this, and just doing a bit here and a bit there will just do my head in and I will lose interest in doing it at all.
Click to expand...
You need to take a look at icons.qrc and custom_render_plugin.sprx too
At this point i think the other functions of the firmware accesses the contents of the qrc files throught custom_render_plugin.sprx
This is confirmed for lines.qrc and icons.qrc because there are a lot of names from them inside custom_render_plugin.sprx
Also, from the other qrc files... there is a raf.qrc and coldboot.raf is directly related with custom_render_plugin.rco

Anyway... the 2 that matters are icons.qrc and lines.qrc because both contains MNU files for settings that affects the visual look and lot of screen effects

And btw... in older firmware versions the icon textures (actually located inside icontex.qrc) was located in icons.qrc... not needed to worry about that, im just mentioning it because that was a big change in the firmware and together with it probably they changed more related things

I dont know how it was made all that in oldest firmwares, but yeah, is going to be more simple, so is better to start looking at the oldest firmwares
 
@DeViL303 want to try this ?... is a triple patch for icons.qrc that we can call... "use always shaders". Basically we have all this FPO files
Code: 
lib/icons/icons_cheap_ss.fpo
lib/icons/icons_cheap_ss_no_shad.fpo
lib/icons/icons_full_ss.fpo
lib/icons/icons_full_ss_no_shad.fpo
lib/icons/icons_no_ss.fpo
lib/icons/icons_no_ss_no_shad.fpo

With the triple patch im remapping the "no_shad" versions (without shaders) to the others (with shaders)
The text strings inside them looks pretty much the same, and his sizes too, it looks the "no_shad" versions are a reduced version of the others

*This is the kind of remapping you was doing in custom_render_plugin.sprx... not sure if you tryed it before, im posting this patch info for icons.qrc because could be used in HEN

icons.qrc "use always shaders" patch for 4.10-4.85
Code: 
Remap "lib/icons/icons_cheap_ss_no_shad.fpo" to "lib/icons/icons_cheap_ss.fpo"
SEARCH:  0000AB5000001880
REPLACE: 0000914000001A10

Remap "lib/icons/icons_full_ss_no_shad.fpo" to "lib/icons/icons_full_ss.fpo"
SEARCH:  00010EE000004360
REPLACE: 0000C3D000004B10

Remap "lib/icons/icons_no_ss_no_shad.fpo" to "lib/icons/icons_no_ss.fpo"
SEARCH:  000168D000001530
REPLACE: 0001524000001690
FILE: https://www.sendspace.com/file/opwgek
 
sandungas said:
@DeViL303 want to try this ?... is a triple patch for icons.qrc that we can call... "use always shaders". Basically we have all this FPO files
Code: 
lib/icons/icons_cheap_ss.fpo
lib/icons/icons_cheap_ss_no_shad.fpo
lib/icons/icons_full_ss.fpo
lib/icons/icons_full_ss_no_shad.fpo
lib/icons/icons_no_ss.fpo
lib/icons/icons_no_ss_no_shad.fpo

With the triple patch im remapping the "no_shad" versions (without shaders) to the others (with shaders)
The text strings inside them looks pretty much the same, and his sizes too, it looks the "no_shad" versions are a reduced version of the others

*This is the kind of remapping you was doing in custom_render_plugin.sprx... not sure if you tryed it before, im posting this patch info for icons.qrc because could be used in HEN

icons.qrc "use always shaders" patch for 4.10-4.85
Code: 
Remap "lib/icons/icons_cheap_ss_no_shad.fpo" to "lib/icons/icons_cheap_ss.fpo"
SEARCH:  0000AB5000001880
REPLACE: 0000914000001A10

Remap "lib/icons/icons_full_ss_no_shad.fpo" to "lib/icons/icons_full_ss.fpo"
SEARCH:  00010EE000004360
REPLACE: 0000C3D000004B10

Remap "lib/icons/icons_no_ss_no_shad.fpo" to "lib/icons/icons_no_ss.fpo"
SEARCH:  000168D000001530
REPLACE: 0001524000001690
FILE: https://www.sendspace.com/file/opwgek
Click to expand...
Can i do the test?
 
sandungas said:
@DeViL303 want to try this ?... is a triple patch for icons.qrc that we can call... "use always shaders". Basically we have all this FPO files
Code: 
lib/icons/icons_cheap_ss.fpo
lib/icons/icons_cheap_ss_no_shad.fpo
lib/icons/icons_full_ss.fpo
lib/icons/icons_full_ss_no_shad.fpo
lib/icons/icons_no_ss.fpo
lib/icons/icons_no_ss_no_shad.fpo

With the triple patch im remapping the "no_shad" versions (without shaders) to the others (with shaders)
The text strings inside them looks pretty much the same, and his sizes too, it looks the "no_shad" versions are a reduced version of the others

*This is the kind of remapping you was doing in custom_render_plugin.sprx... not sure if you tryed it before, im posting this patch info for icons.qrc because could be used in HEN

icons.qrc "use always shaders" patch for 4.10-4.85
Code: 
Remap "lib/icons/icons_cheap_ss_no_shad.fpo" to "lib/icons/icons_cheap_ss.fpo"
SEARCH:  0000AB5000001880
REPLACE: 0000914000001A10

Remap "lib/icons/icons_full_ss_no_shad.fpo" to "lib/icons/icons_full_ss.fpo"
SEARCH:  00010EE000004360
REPLACE: 0000C3D000004B10

Remap "lib/icons/icons_no_ss_no_shad.fpo" to "lib/icons/icons_no_ss.fpo"
SEARCH:  000168D000001530
REPLACE: 0001524000001690
FILE: https://www.sendspace.com/file/opwgek
Click to expand...
By chance, it is possible to remove or disable the transparency of the icons? like the classic theme....but for the whole system.
 
Danxx444 said:
Can i do the test?
Click to expand...
Well, i would say you shoud not test it, but i have the feeling you are going to test a lot more risky things in the next weeks anyways, and i know you did some kamikaze tests already... so you decide

Today after the fail of the other thread is a bad day to say this https://www.psx-place.com/threads/png-to-gim.26340/page-5#post-207950
...but this remapping for the "use always shaders" in icons.qrc is something that im confident is going to work
What i dont know is how is going to look... maybe it looks so weird that is not usable

Danxx444 said:
By chance, it is possible to remove or disable the transparency of the icons? like the classic theme....but for the whole system.
Click to expand...
Yes i think, there is a setting in icons.MNU named: https://www.psdevwiki.com/ps3/Icons.qrc#ICONS.mnu
SS METHOD:int:0

That seems to allow to choose one of the FPO files im remapping
Code: 
lib/icons/icons_cheap_ss.fpo
lib/icons/icons_cheap_ss_no_shad.fpo
lib/icons/icons_full_ss.fpo
lib/icons/icons_full_ss_no_shad.fpo
lib/icons/icons_no_ss.fpo
lib/icons/icons_no_ss_no_shad.fpo

I guess are three options, 0, 1, or 2
I dont know which one is each... but that setting applyes globally (is unique inside icons.qrc and never changes for any of the enviroments)... so whatever that means that 0 it seems to be used always
 
Last edited:
sandungas said:
Well, i would say you shoud not test it, but i have the feeling you are going to test a lot more risky things in the next weeks anyways, and i know you did some kamikaze tests already... so you decide

Today after the fail of the other thread is a bad day to say this https://www.psx-place.com/threads/png-to-gim.26340/page-5#post-207950
...but this remapping for the "use always shaders" in icons.qrc is something that im confident is going to work
What i dont know is how is going to look... maybe it looks so weird that is not usable
Click to expand...
"Kamikaze test" LOL...okay then i'll be quiet this time :D
 
Im quoting this old post to discuss it, you mentioned it here (incase someone is interested to follow the track of the crossed conversations)
https://www.psx-place.com/threads/png-to-gim.26340/page-6#post-208078
DeViL303 said:
This seem to be the best settings for quickest boot time, its hard to measure, but maybe 1.0 second quicker approx.

Code: 
<Animation name="anim_coldboot2">
<Fade object="object:scelogo" duration="0" accelMode="0x3" transparency="0" />
<FireEvent object="event:native:/anim_coldboot_ShowGUI" />
</Animation>
Click to expand...
The line with the <Fade> is working as a initialization (inside the animation) of the color alpha of the <Plane> "scelogo"

At top, in the <ObjectTree> is located the <Plane name="scelogo"... with the attribute colorScaleA="1"
This means the image is opaque (fully visible) when the firmware loads the rco

This is why the first thing that happens inside anim_coldboot2 animation is to "initialize" that image to transparent

Long story short... you can delete the <Fade> line inside anim_coldboot2 and change the colorScaleA="1" to 0 of "scelogo" <Plane>
I dont think this is going to short the time, but the amount of xml code is going to be smaller


--------------
For the other lines in the official anim_coldboot2 i would keep this ones, mostly because i dont know what they does
Code: 
<Anim name="anim_coldboot2">
	<Lock unknownInt0="0xffffffff" />
	<Delay time="0" />
	<FireEvent event="event:native:/anim_coldboot_ShowGUI" />
	<Unlock unknownInt0="0xffffffff" />
	<Delay time="0" />
	<FireEvent event="event:native:/anim_coldboot_Finished" />
</Anim>
Im keeping the delays with 0 just to prevent some conflict, i guess you tryed without them so probably is safe to remove them
If i remember right... there are some delays=0 used in official firmware

The <Lock> and <Unlock> are completly unknown... by me and by everyone, even zinga burga who made rcomage and all the people helping him... nobody know what does that lock/unlock... and actually the names lock/unlock was invented by zinga burga (so maybe are wrong, and the way they works is not related with locks at all)
I have some theories about them though, but never minds, i dont know any way to check if my theories are right or wrong... so is like smoke
 
Hard to know with the lock entry. I think its something to do with releasing control to the pad but maybe does more than that, I have not looked into lock/unlock much as it seems to be boring, But in one of my tests it seemed like I could bring up the impose screen quicker if I have it unlocked sooner, not sure though exactly. The "coldboot finished" line seems to do nothing except stop the coldboot audio. it might also stop the coldboot background animation a little quicker but it stops so fast anyway its hard to know.

Yeah you could make the image transparent up there for more efficient xml, or even better just remove that whole plane and delete the image from the image tree for smallest filesize too.
 
DeViL303 said:
Hard to know with the lock entry. I think its something to do with releasing control to the pad but maybe does more than that, I have not looked into lock/unlock much as it seems to be boring, But in one of my tests it seemed like I could bring up the impose screen quicker if I have it unlocked sooner, not sure though exactly. The "coldboot finished" line seems to do nothing except stop the coldboot audio. it might also stop the coldboot background animation a little quicker but it stops so fast anyway its hard to know.

Yeah you could make the image transparent up there for more efficient xml, or even better just remove that whole plane and delete the image from the image tree for smallest filesize too.
Click to expand...
I think the lock/unlock is related with the loading of other parts of the interface, most specifically, the XMB bar with his icons and all that

The reason why i think this is because the animation does the "unlock" inmediatly after the "anim_coldboot_ShowGUI"
And well... is locked at the first lines to prevent the XMB to load in the previous steps of the animation (when is doing the fades and fireevents)

Yes, the "event:native:/anim_coldboot_Finished" seems to be stopping everything inside the animation, if i remember right... is perfectly synced in time with the sum of the previous delays + times (for both, the old coldboot from firmware 1:00 and the new coldboot.raf for mdoern firmwares)
But for the audio i dont think is simply stopping it... well, this doesnt matters much, im just mentioning it for curiosity sake, i was checking times the other day and noticed the sound is way longer... right now i think it does a "fade out" with the audio (decreasing his volume)... by code i mean, like an audio effect made on real time, not sure about this thought, i know it doesnt makes much sense, but im sure there is a weird disalignment at the end of the coldboot sound

Anyway... incase of removng the previous "event:native:/anim_coldboot_BootBG2" and "event:native:/anim_coldboot_NormalBG2"... then there is no need to stop anything... so should be safe to remove the "event:native:/anim_coldboot_Finished" like you did
 
sandungas said:
But for the audio i dont think is simply stopping it... well, this doesnt matters much, im just mentioning it for curiosity sake, i was checking times the other day and noticed the sound is way longer... right now i think it does a "fade out" with the audio (decreasing his volume)... by code i mean, like an audio effect made on real time, not sure about this thought, i know it doesnt makes much sense, but im sure there is a weird disalignment at the end of the coldboot sound
Click to expand...
I'm fairly sure it does stop the coldboot sound fairly dead, That's how I enabled the 10 minute coldboot.ac3 mod. I discovered it by mistake when I had a very short animation with that line still in it, and it did not leave enough time for official ac3 to play.

If it is a fade its very quick, less than a second.
sandungas said:
Anyway... incase of removng the previous "event:native:/anim_coldboot_BootBG2" and "event:native:/anim_coldboot_NormalBG2"... then there is no need to stop anything... so should be safe to remove the "event:native:/anim_coldboot_Finished" like you did
Click to expand...
Yeah its safe, in my infinite looping 3 minute animation mod I removed it. Also I have been just having lock and unlock first thing in most of my mods just in case it does something important. :)
 
Ok, so i guess this is the minimalistic version, changing transparency in the object
Code: 
<Plane name="scelogo"... replace... colorScaleA="1"... by 0
And keeping just 1 line in the anim
Code: 
<Anim name="anim_coldboot2">
	<FireEvent event="event:native:/anim_coldboot_ShowGUI" />
</Anim>
But im wondering what is going to display the PS3 after that ?... directly into the epilepsy warning screen ?
So the "showGUI" is not really showing the GUI :crybaby:
Well, i mean... it does it, but first it shows the epilepsy screen... then the GUI
 
Maybe epilepsy warning could be effected in lines.qrc, I think the overrides welcome1 and welcome2 are for that, maybe if they were missing or replaced with something else it would change something.. unlikely but small chance as ps3 is funny machine sometimes with how it behaves.
 
@sandungas @esc0rtd3w @kozarovv I have not got much time, but I think qglbase.sprx is very tied in with Q-Games wave particle debug GUI, might be worth a look.

See here, looks like debug references and a path dev_hdd0/game/ABCD12345/ . It makes sense that Q-Games could claim the first title ID as they were working on XMB from the start. Also see all the paths just like the visualizer application

upload_2019-9-30_14-3-51.png



It looks like there is support for loading qrc files from ABCD12345/USRDIR/dataplat/ and also support for gz files from datacom. The error text there also seems to suggest it supports loading from multiple locations, bank = flash I guess?

upload_2019-9-30_14-10-37.png



More stuff the same as lines.qrc/custom_render_plugin.sprx that looks interesting.

upload_2019-9-30_14-16-12.png


Also lots of stuff that looks like debugging text errors:

upload_2019-9-30_14-33-56.png

upload_2019-9-30_14-36-28.png


Other image formats supported.

upload_2019-9-30_14-39-29.png







Also see in qgl_gaia_app.sprx there is actually "debug::_interact_menu_lock" in there which looks like a native event you call from rco.

upload_2019-9-30_14-30-40.png



BTW: I think there will be some good mods of the earth visualization with like 2 moons and 2 suns and stuff like that. :)
 
In this one there are 2 info messages "load from disk" and "load from bank"
"disk" usually is hdd (most specifically, i guess is dev_hdd0)... so i guess bank should be flash
upload_2019-9-30_14-10-37-png.20315


And im thinking... maybe the patches in custom_render_plugin.sprx with the remaps to force the firmware to load the DebugGUI files was not enought. You are showing now that there are more references to DebugGUI inside qglbase.sprx
So maybe is needed to patch both .sprx for the remaps
Or what we was mentioning the other day... doing the remaps in lines.qrc and not in the .sprx's

qglbase.sprx have the names of the other FPO/VPO files ?... like background.fpo/vpo ?
 
DeViL303 said:
Nice little mod I discovered when messing with swapping around overrides in the custom_render_plugin.sprx. It looks even better in real life :)

I call it:

Ignore the RED screen glitches at the end of the video, that did not really happen, glitch with my capture card.

For CFW only due to the sprx, files attached. Includes the lines.qrc from ps3 pro mod.
Click to expand...

Can it be modded for HEN? in the lines.qrc?

i'm using it on the pro CFW version, but want to add it in HEN
 
Probably, but I cant remember what I did in that mod. :) You would need to compare the sprx in hex with the original and then see if those patches can be applied in the qrc.
 
You must log in or register to reply here.

Similar threads

Back
Top