I know, the ones inside impose_plugin.rco are for a buttonbar and circle and cross buttons, there is a page in psdevwiki with all the animations used in official PS3 firmwares (and one example from PSP firmware using an infinite loop for the battery charging) https://www.psdevwiki.com/ps3/RCOXML_ofw_animations
All them are very simple effects, are good to take a look at them as an introduction of how it works but there is not much creativity in them, the most complex are the coldboot and gameboot
Still waiting for someone to beat my "Star Wars Rave" coldboot animation for complexity, even that was quickly thrown together I'm sure someone here can do something better.
@sandungas: Did you realize that in theory we can create polygons with rcos planes and then animate them with scripts without using any actual image files. Who's going to make the first rotating 3D cube. Or recreate the PS1 - PS2 coldboots. I would also like to do a C64 or spectrum style coldboot where it shows text counting the RAM etc.
Still waiting for someone to beat my "Star Wars Rave" coldboot animation for complexity, even that was quickly thrown together I'm sure someone here can do something better.
@sandungas: Did you realize that in theory we can create polygons with rcos planes and then animate them with scripts without using any actual image files. Who's going to make the first rotating 3D cube. Or recreate the PS1 - PS2 coldboots. I would also like to do a C64 or spectrum style coldboot where it shows text counting the RAM etc.
Btw @Danxx444 im realizing there is an easy way to restore the original gameboot... and you are not using it (because the custom_render_plugin.rco i made was not using it)
This one is better, is explained in the readme, in the PS3 firmware there are several coldboots and gameboots, but in the way im doing it there is only 1 coldboot and 1 gameboot, and the firmware is going to play them always
And looks exactly like the originals from firmware 1.00 because im not adding a single line of code... actually im deleting a few lines, this .rco is smaller than the official
There is a way, I did it once during testing but can't remember how. If it helps I know the blur is controlled by dev_flash/vsh/resource/qgl/rhm.qrc.
If anyone is looking into it, I think I patched out something in one of the related sprx files, maybe custom_render_plugin.sprx or xmb_plugin.sprx or qglbase.sprx.
What makes all this work different from taking cold boot.raf and game boot from firmware 2.80 and simply replacing the existing ones in 4.85? Did some effects also change? I don't remember what coldboot looked like from 2009 and earlier
What makes all this work different from taking cold boot.raf and game boot from firmware 2.80 and simply replacing the existing ones in 4.85? Did some effects also change? I don't remember what coldboot looked like from 2009 and earlier
You could take the coldboot.raf from 2.80 but its the exact same file as the coldboot.raf in 4.85.
The coldboot.raf file has never changed since it was added, and the gameboot is not a raf or any single file that can be taken, The coldboot and gameboot are made up from lots of files like custom_render_plugin sprx and rco, xmb_plugin sprx and rco, icon.qrc, lines.qrc, qglbase.sprx , ac3 files etc. The older files are not compatible with new FW as there have been lots of changes since then.
What makes all this work different from taking cold boot.raf and game boot from firmware 2.80 and simply replacing the existing ones in 4.85? Did some effects also change? I don't remember what coldboot looked like from 2009 and earlier
Originally in the first PS3 firmware versions the coldboot and gameboot animations was made completly with settings stored inside RCO files (custom_render_plugin.rco mostly)
And later, when they implemented RAF support to the PS3 firmware is when they created the coldboot.raf but the way how coldboot.raf is loaded is a bit tricky
Sony doesnt uses to rewrite much code if posible (and doesnt uses to delete either)
For coldboot.raf they created some kind of "link" to load the coldboot.raf file instead of a plain image (that was supposed to be located inside custom_render_plugin.rco)
Inside the RCO files there are some definitions of "XMB objects" (as example a checkbox), and settings for that objects (es example, his size). And there are also "XMB animations" for that objects
All that info is exported by the tool rcomage as a xml file... we have posted some samples of both coldboot and gameboot animations in xml, are just a few lines of xml code
Back to the story... that xml animations from inside custom_render_plugin.rco are loaded in all firmwares.. is just since firmware 2.00 or so there is additional info to load the gameboot.raf
And we cant modify the xml lines responsibles of loading coldboot.raf, because the .sprx searches for them, if we modify them the firmware crashes
In some of my posts in this thread i was trying to disable the loading of coldboot.raf just by editing the RCO stuff (it would be convenient to do it this way becaue his simplicity) but was not working :/
The solution to disable coldboot.raf seems to be simply by deleting it... it seems the firmware doesnt complains about it (and the xml animation stuff from custom_render_plugin.rco keeps loading normally)
---------------------------
There are other settings involved in coldboot and gameboot animations though... mostly the MNU files inside QRC files
That MNU files contains some settings for the different "XMB enviroments" and there are some settings for coldboot and gameboot animations
Are things that could affect the scene illumination, reflections, and other visual effects... so they generates very notable changes visually
In some days it will be released a tool to deal with QRC files that is going to help a lot to compare the settings from different firmware versions
That was one of the most important things we where missing in the previous talks in this thread... we was not copying the "old" MNU settings to "port" them to 4.85
The differences could be subbtle... but i have doubts about it... the only way to know for sure if we was missing something would be to make an accurate list to compare them related MNU settings: firmware 1.00 versus 4.85
Originally in the first PS3 firmware versions the coldboot and gameboot animations was made completly with settings stored inside RCO files (custom_render_plugin.rco mostly)
And later, when they implemented RAF support to the PS3 firmware is when they created the coldboot.raf but the way how coldboot.raf is loaded is a bit tricky
Sony doesnt uses to rewrite much code if posible (and doesnt uses to delete either)
For coldboot.raf they created some kind of "link" to load the coldboot.raf file instead of a plain image (that was supposed to be located inside custom_render_plugin.rco)
Inside the RCO files there are some definitions of "XMB objects" (as example a checkbox), and settings for that objects (es example, his size). And there are also "XMB animations" for that objects
All that info is exported by the tool rcomage as a xml file... we have posted some samples of both coldboot and gameboot animations in xml, are just a few lines of xml code
Back to the story... that xml animations from inside custom_render_plugin.rco are loaded in all firmwares.. is just since firmware 2.00 or so there is additional info to load the gameboot.raf
And we cant modify the xml lines responsibles of loading coldboot.raf, because the .sprx searches for them, if we modify them the firmware crashes
In some of my posts in this thread i was trying to disable the loading of coldboot.raf just by editing the RCO stuff (it would be convenient to do it this way becaue his simplicity) but was not working :/
The solution to disable coldboot.raf seems to be simply by deleting it... it seems the firmware doesnt complains about it (and the xml animation stuff from custom_render_plugin.rco keeps loading normally)
---------------------------
There are other settings involved in coldboot and gameboot animations though... mostly the MNU files inside QRC files
That MNU files contains some settings for the different "XMB enviroments" and there are some settings for coldboot and gameboot animations
Are things that could affect the scene illumination, reflections, and other visual effects... so they generates very notable changes visually
In some days it will be released a tool to deal with QRC files that is going to help a lot to compare the settings from different firmware versions
That was one of the most important things we where missing in the previous talks in this thread... we was not copying the "old" MNU settings to "port" them to 4.85
The differences could be subbtle... but i have doubts about it... the only way to know for sure if we was missing something would be to make an accurate list to compare them related MNU settings: firmware 1.00 versus 4.85
Yep, thats relativelly easy to achieve, you need to use XForge
[File]>[Open] ...and select lines.qrc
[File]>[Extract all]
After that you can close XForge, and use the extraction folder as your work directory, you can modify all files or replace them, and when you are done with your modifications open XForge again and:
[File]>[Open] ...and select lines.xml (located at the root of the extraction folder)
Not sure what you meant about selecting a black color, i guess you are talking about the background wallpapers, are DDS files extracted to path lines.qrc/textures/month_bg/rgb/*dds (for daytime hours) and lines.qrc/textures/month_bg/night/*dds (for nightime hours), you can replace all them by pure black images
If you are talking about making a black wave is needed to modify the settings inside the BACKRGOUND.mnu files, basically you need to change all the values for RED, GREEN, BLUE to zero https://www.psdevwiki.com/ps3/Lines.qrc#BACKGROUND.mnu
To disable the particles... i guess there are several different approaches, and what im going to say is not completly confirmed, but you can change the setings inside PARTICLES.mnu https://www.psdevwiki.com/ps3/Lines.qrc#PARTICLES.mnu
Take a look at the settings most at top, all the settings with a name starting with "emit" are the responsibles of the amount (and speeds, directions, etc) of the particles emited
As a concept... the particles are emited by an emitter (i guess the emitter is the geometrical position of the wave)... when you change the settings of the emitter by zeroes it stops emiting any particles
Im wondering if there is a better way to disable the particles though... this kind of things uses to have a general setting that works as a switch with only posible values ON/OFF... the particles should have a settings for this that would allow to disable or enable them completly, but i cant find it now
-------------------
And btw, all this changes in the MNU files needs to be made for every "XMB enviroment" (and there are more than 20... so are 20 MNU files)... you can choose to use specific settings for every enviroment (in other words, every MNU file with different values)... or more easyer, use the same settings for all the enviroments
The way to keep some order while editing them is (in windows explorer) go to the root of the extracted QRC files, right click in your mouse and select "search"
Then search for PARTICLES.mnu.... or BACKGROUND.mnu
This is going to display a list with all the files (up to 20 files or so with the same name)
Then right mouse click in the search window and select "show details" (with the full paths), so you can see in a single look which file belongs to every "XMB enviroment"
Im wondering if there is a better way to disable the particles though... this kind of things uses to have a general setting that works as a switch with only posible values ON/OFF... the particles should have a settings for this that would allow to disable or enable them completly, but i cant find it now
Im having a nice idea... previously it was very hard to do it, but now with XForge is easy
Take a look at LINE1.mnuhttps://www.psdevwiki.com/ps3/Lines.qrc#LINE1.mnu
The first setting named STATE:int:1 is the ON/OFF switch.... if you replace the default 1 by a 0 the wave is disabled completly
The weird thing is the file PARTICLES.mnu doesnt have that setting (but i really think it should be valid)... so the idea is to add the STATE:int:0 to the PARTICLES.mnu files
Easy (and probably it works)
Im having a nice idea... previously it was very hard to do it, but now with XForge is easy
Take a look at LINE1.mnuhttps://www.psdevwiki.com/ps3/Lines.qrc#LINE1.mnu
The first setting named STATE:int:1 is the ON/OFF switch.... if you replace the default 1 by a 0 the wave is disabled completly
The weird thing is the file PARTICLES.mnu doesnt have that setting (but i really think it should be valid)... so the idea is to add the STATE:int:0 to the PARTICLES.mnu files
Easy (and probably it works)
Damn, what a shame, his simplicity made it so beauty
Well, try the other idea about setting all the "emit" values to zero, i was talking about it time ago in this forum but i dont really remember if someone tryed it, but the concept is straightforward...
We have an emitter with some settings like speed (the "emit vel" seems to mean "velocity")... if we set the speed to zero then the particles are not going anywhere, right ?, i guess it should work, at least in concept it makes sense to me
There could be more "destructive" ways to disable the particles though, but im not sure either if are going to work... like replacing the particles.elf by a dummy
I think we was talking about something like this too time ago, but dont remember well, maybe is something that happened by mistake because we corrupted it in one of the tests when i was trying to "inject" the .elf files to make some frankensperiments
If i remember right it works... but better dont try it yet... by now is looks better to modify the .mnu files
Lets say... modifying the .mnu files is a less invasive way to achieve your goal
Incase the .mnu files are not enought... yeah is time to consider doing some butchery with the particles.elf
Damn, what a shame, his simplicity made it so beauty
Well, try the other idea about setting all the "emit" values to zero, i was talking about it time ago in this forum but i dont really remember if someone tryed it, but the concept is straightforward...
We have an emitter with some settings like speed (the "emit vel" seems to mean "velocity")... if we set the speed to zero then the particles are not going anywhere, right ?, i guess it should work, at least in concept it makes sense to me
There could be more "destructive" ways to disable the particles though, but im not sure either if are going to work... like replacing the particles.elf by a dummy
I think we was talking about something like this too time ago, but dont remember well, maybe is something that happened by mistake because we corrupted it in one of the tests when i was trying to "inject" the .elf files to make some frankensperiments
If i remember right it works... but better dont try it yet... by now is looks better to modify the .mnu files
Lets say... modifying the .mnu files is a less invasive way to achieve your goal
Incase the .mnu files are not enought... yeah is time to consider doing some butchery with the particles.elf
Setting theme to "classic" nearly disables all the particles. They are not present on coldboot, gameboot, or in the general xmb. Only when quitting a game do the particles briefly appear before disappearing again when on "classic" theme. It's jarring the way they appear/disappear so suddenly, I cannot believe Sony did not do a better job polishing this part. Otherwise xmb is perfect Gui
Actually, im guessing it could be posible to compile a particles.elf using 100% custom source code but containing only a couple of lines of code
Code:
#INCLUDE whatever
main (){
break;
}
A shit like that is really a legit program, the firmware is going to run and stop it inmediatly, and should not complain
I cant compile that though... im just mentioning it incase someone with the needed tools is reading us and wants to play a bit
The weird thing is the file PARTICLES.mnu doesnt have that setting (but i really think it should be valid)... so the idea is to add the STATE:int:0 to the PARTICLES.mnu files
Easy (and probably it works)
There could be more "destructive" ways to disable the particles though, but im not sure either if are going to work... like replacing the particles.elf by a dummy
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.
Setting theme to "classic" nearly disables all the particles. They are not present on coldboot, gameboot, or in the general xmb. Only when quitting a game do the particles briefly appear before disappearing again when on "classic" theme. It's jarring the way they appear/disappear so suddenly, I cannot believe Sony did not do a better job polishing this part. Otherwise xmb is perfect Gui
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
I'm sure someone here can do something better.
