I will do another longer one to show it better. What exactly should I do, leave it sit for 30 sec, then just move one icon at a time, or move lots, but then stay still longer like 5 seconds after each move?
The interaction of the particles with the DS3/icons is using the settings from PARTICLES_UI.mnu
https://www.psdevwiki.com/ps3/Lines.qrc#PARTICLES_UI.mnu
Im mentioning it because is good if you take a look at the setting names while shaking the DS3 in the XMB
Some things i noticed...
If you move the DS3 up 1 time and down 1 time fast, the first up makes the particles to move in a direction, but the second move down stops them a bit... so is better to dont move in opposite directions, this way you can see how the particles decelerates by themselfs, or does a "decay", or dissapears, or are more affected by gravity... thing like that
If you move the DS3 up and down several times fast... it looks like the particles movements becomes a lot more chaotic... lets say 5 shakes of the DS3 = chaos mode
Also, the icon images have different effects, the basic concept is the XMB is like a container with a fluid... like a fishtank, and the icons are objects, lets say... when an icon moves to right, it creates a turbulence around itself and the fluid moves in opposite direction to left (to fill the "hole" of the original position of the icon), but if an icon "hits" a particle is like if you ht a tennis ball with a hammer, is a collision in betwen 2 solid objects... and the particle flyes away at high speed and goes out of the screen o/
Dunno, probably there are more cool details, i bet lot of people did not even realized (like myself time ago, i think i realized about all this while lurking in the firmware files)
Can we look inside the DebugGUI vpo/fpo and maybe see some elements or anything like variable names, images, text etc? That might give us a clue for enabling it, or tell us something else?
Well, are compiled code, the only thing we can see in them is the names of the variables, functions, etc... but nothing more... and usually are not much explicit, so is hard to deduce how are working
To have a better understanding of them we need to disassemble them with a mythological tool named
sce-cgcdisasm.exe
I have a feeling that PARTICLES_UI is where we need to look, at a guess we need to load that instead of one of the other PARTICLES.MNU files.or as well as the other PARTICLES files.
I dont think, this is a road end, the PARTICLES_UI is an unique file, so his settings are globally applyed, are related with the interaction in between particles and DS3/icons, and i guess are applyed everytime that appears the particles... is just sometimes the DS3 is locked when the particles are displayed (like in coldboot or gameboot, i guess in them the particles are still reactive to DS3/icons... is just the DS3 outputs are ignored, and there is no icon "hitting" them or creating turbulences in the fluid)
It really could be a flag on hdd that enables it, like a simple txt file maybe in correct location.
View attachment 20247
I think this txt file is very important, it is right next to the dev_gui/debugGUI stuff. Is it possible that this txt file is inside the QRC?
I can tell that is not inside any QRC... but yeah is interesting, the fact that is located so close to the others DebugGui is fishy
Also check this, is there anything there that helps, its an Gamemoneky Script file from the visualizer application that mentions devgui.
Code:
//Devgui child
//Devgui
global g_devgui_layout = {};
global DevGuiMngLayout = function(_Name,_Func)
{
local opened = ?g_devgui_layout[_Name];
local new_value = Q.SIMGUICheckBox( opened, _Name );
if (new_value != opened)
{
if (opened)
{
g_devgui_layout[_Name].Release();
g_devgui_layout[_Name] = null;
}
else
{
local layout = _Func();
g_devgui_layout[_Name] = layout;
layout.SetName(_Name);
layout.EnableTitle( true );
}
}
};
global DevGuiDump = function()
{
DevGuiMngLayout(
"HDR Param",
function() { return Q.NewLayout( 80, 80, 700, 500, null, g_hdr_gui.Param.draw ); }
);
/*
DevGuiMngLayout(
"Camera",
function() { return Q.NewLayout(120,120,500,200,null,g_camera_gui); }
);
*/
/*
DevGuiMngLayout(
"Rumble Editor",
function() { return Q.NewLayout(300,120,500,500,null,g_rumble_debug_gui); }
);
*/
/*
if( Q.SIMGUIButton("GmDebugEntry") )
{
g_devgui_layout["GmDebugEntry"] = Q.NewLayout(120,120,300,300,null,GmDebugEntry);
g_devgui_layout["GmDebugEntry"].EnableCloseButton( true );
g_devgui_layout["GmDebugEntry"].EnableDebuggerLayout( true );
}
*/
// HDRMenu(this);
};
Does the wave use gamemonkey too or something or ....?
I been looking at some of them... the files with .gm extension that seems to be "GameMonkey" code
I was reading about gamemonkey the other day, is good that is a bit like LUA, the program loads it like that, not compiled, are easy to be modifyed... but in the PS3 that gamemoneky files are not used... as far i know... and i could bet on it
The interesting thing is some of the VPO/FPO files from the Q-games visualizer app are identical to some of the FPO/VPO files inside the QRC containers of the PS3 firmware
Specially the files located under paths "glutils", this folder exists in the Q-games visualizer, and also exists in all/most of the QRC containers, the files inside them are repeated a lot, as example the file/s
ConeFilter.fpo/vpo exists inside: store.qrc, earth.qrc, canyon.qrc, raf.qrc, rhm.qrc, lines.qrc, icons.qrc... and of course inside the Q-games visualizer
I have not extracted them to compare his MD5 but i bet are identical
This is the part of the "library" i was talking the other day that we should not modify (of couse we can do whatever we want)
The point is... the "glutils" is a part of "openglES" that is distributed as source code (not compiled), and the shaders are source code too and are "not platform specific"
When they installs openglES there is a point when they needs to select the "target platform" that is going to run the compiled code
The platform is the PS3... and the tool to compile the VPO/FPO files is included in the PS3 SDK, and is using a profile for the NVIDIA RSX of the PS3
So... when they does the installation of openglES for the PS3 target... the installer is going to compile hundreds of shaders into VPO/FPO, and after that you should not modify them, because are like small utilities very generic
Then when you write a program and at the top of the source code you can indicate that:
#INCLUDE conefilter
#INCLUDE gaussian
This is why are repeated inside most of the QRC files... and why are identical
The only reason for not be identical... is if the opengl or that collection of libraries for shaders was updated
This is posible, and could be interesting, but not much though.. the point is the VPO/FPO files of the PS3 probably are dated from 2006 or so... and the ones from the Q-games visualizer are dated from 2011
Theoretically we could replace them, this way we could "update" the ones of the PS3
But like said before... maybe this is going to be a bit "meh"... i dont want to be pessimistic but the reward doesnt looks promising
Edit:
Just to be clear... i mean... replacing a VPO/FPO file of the PS3 firmware by a VPO/FPO file from the Q-games visualizer... both with the same name (with the goal of updating them), is not worthy in my oppinion because most probably the reward is going to be minimal
But taking one of the FPO/VPO files that exists in the Q-games visualizer (but doesnt exists in the PS3 firmware)... to add it to the PS3 firmware could be very interesting
The resume of the story is... the files inside "glutils" path are not much interesting... the others are better targets for the experiments because are "custom made" either by sony of by q-games
---------
In the gamemonkey files i can see some interesting codenames... they are using the "vis" (because the visualizer), there is something named "SIMVIEW" (or SIMSOMETHING, i dont remember well, that i guess it could be like a XMB emulator/simulator for pc)
I dont understand much in the gamemoneky files, most of them just looks like a single function, but potentially could be interesting, because obviouslly are interacting directly or indirectly with the VPO/FPO files
If there is some direct connection in betweem them maybe by looking at the gamemonkey files someone could figure what the FPO/VPO files does
