ManaGunZ

PS3 ManaGunZ - PS3 Backup Manager by Zar v1.41

I splitted "COIN SUPERIEUR" because at first, I wanted to display the cover 2D with a rounded corner (not full just half of it = 45°) then when I saw the result, it was ugly, streched so, I changed my mind and displayed the front cover without the rounded corner, I didn't think too much about it. It confirm your post here : https://www.psx-place.com/threads/managunz-ps3-backup-manager-by-zar.1198/page-56#post-255845 there is something weird with this corner. I'll try to fix it.
Mapping the 2D cover to only 45º would be the most accurate because this is what happens in real world. As far i remember it was you who mentioned it first, later i was talking about it too because i liked it
But in the beta (where the 2D cover is not mapped to the curve at all) looks good, better than what i imagined when i suggested it, the vertical section of plastic visible at left when the game is "on focus" doesnt looks bad at all... actually it looks better than without it

After that change that simplifyes the geometry a bit for the 2D cover mapping, and considering the problems of previous versions i was wondering if it would be better to dont split the corners in half... because initially it seems to be the kind of change that "should work" and it simplifyes the geometry (so less problems)
If you dont want to spend much time in it i think is the better aproach to solve the problem by now

My point is... the splitting of the corners in 2 halfs of 45º each is not working very nice by now... so is better to dont do it by now... but eventually that splitting of 45º could be implemented (and images adjusted to it)
The priority is to have the basic geometry working (without the splitting), and the splitting is an improvement, but is not prioritary (and/or we dont need it) :)


-------------
The only problem i see with it is related with an idea i mentioned vaguelly in one of my posts... but i dont really know the difficulty to implement in the code
Is about displaying a "default cover full" (something similar to the images i was doing, intended to be generic)... and on top of it the "cover front" in 2D

If we dont map the "cover front" to 45º of the corner then there is going to be a disalignment in between the "default cover full" (at bottom), and the real cover front (at top)
But i think i can add some details in the "default cover full" to reduce the weirdness of this disalignment :)
 
Last edited:
Just made a dirty sketchup that i think is going to help us to simplify the talks about it, and for the people reading that could have lost the track some posts ago
We have 7 "sections" of the geometry, so i gave them a number from left to right
Ceec80e.jpg


In mgz v1.38 the cover front was mapped to surfaces 5+6+7, but that excesive width was looking a bit meh because the front was visible from the other side when the games are displayed at the right "out of focus"
One of the responsibles of this weird visual effect was the fact we dont have any texture in the surfaces 1,2,3,4 (is like if there was a very notable visual "breakpoint" in between 4 and 5), so the idea of displaying a default generic cover at bottom as a fallback could help reduce this weird visual effect

In the mgz v1.39 beta you uploaded to the forum the cover front was mapped only to surface 7, and the results are better than before, not realistic but is a good compromise
To achieve a realistic look the cover front should be mapped to surfaces 6+7 but this has been proved to be problematic, and it makes the geometry a bit more complex... so if you find how to do it great, but otherway dont worry about it, just map it to 7 and we are done with it

And the other idea about using a "default cover full" at bottom of the "cover front" could be made in a better way than what i suggested by splitting it in 3 PNG files, by now we can do this:
PS3_COVER3D_BACK.PNG = mapped to 1
PS3_COVER3D_SIDE.PNG = mapped to 2+3+4+5+6
PS3_COVER3D_FRONT.PNG = mapped to 7

This way we have all the problems (curved surfaces) in the same place to simplify it a bit, also this matches fine with the mapping used in the mgz v1.39 beta you uploaded to the forum where the "cover front" was mapped to surface 7 only :)

This default cover textures could be aplyed to the polygonal object in the same way used by the BR_LOGO.PNG... i mean... like an static texture that belongs to the object (and there is no need to load them in the memory buffers for covers)

If the user doent have any of the covers for that game then are displayed the 3 default cover images (back, side, front)
If the user have the game "cover front" (but not the "cover full"), then are displayed 2 default images (back, side) + the game cover at front
Im guessing this is the most efficient way to do it instead of the "overlapping" i was suggesting displaying the "default cover full" at bottom + the real "cover front" at top of it. The visual effect would be pretty much the same, but i think this way is more correct and better aligned

--------------
And this same default images are going to fit perfectly if at some point the geometry is rebuilt this way (trying to achieve realism):
PS3_COVER3D_BACK.PNG = mapped to 1+2
PS3_COVER3D_SIDE.PNG = mapped to 3+4+5
PS3_COVER3D_FRONT.PNG = mapped to 6+7
 
Last edited:
  • Like
Reactions: Zar
I'm ok with 3 files, but if I do it correctly I think i can cut the 3D cover default template to not overlap the 2D covers (2D and 3D default). I think the visual result will be exactly the same. So, for me both are ok but I'm just wondering if it's not going to drop down the FPS, each piece of cover is an object to deal with, also it's possible that the joins will be visible especially when the box moves.
 
I'm ok with 3 files, but if I do it correctly I think i can cut the 3D cover default template to not overlap the 2D covers (2D and 3D default). I think the visual result will be exactly the same. So, for me both are ok but I'm just wondering if it's not going to drop down the FPS, each piece of cover is an object to deal with, also it's possible that the joins will be visible especially when the box moves.
Hmmm, i didnt thought in cropping the default cover full image by code at runtime... but you are right, the result visually should be exactly the same because the default cover full images are going to be made with "1 pixel precission", so the cropping can be made very accuratelly. This way the image will be cropped in two, right ?
First section = 1+2+3+4+5
Second section = 6+7

There could be a tiny disalignment in the first section (in the way how the cover image is aligned with the two vertex in between 2 and 3) because there is an small displacement in the whole geometry with a tendence to increase in right direction (note in my reference image i uploaded the other day, the location of the 2 white dots at the right border of the "default cover full", there was some pixels missing in the screenshoot because the texture is "out of the surface"
Anyway, im not complaining about that because is not notable, just mentioning it because this small disalignment is not creating a bad effect in "back" and "front" areas because they have a big width... but the "side" could be more sensitive to it because his small width

Anyway, what you mentioned is good enought

So it was just 1º and the SW selector ?, and you was able to fix it preserving the two for loops of 45º that looks more realistic
Thats awesome, now im more confident the FLOW3D interface of next mgz version is going to look great :encouragement:
 
@Zar what do you think about creating the default 3D covers at x2 scale factor ?, im thinking about this because the default 3D covers are going to be displayed only under 2 cases:
Case 1) if there are no cover/s for that game
Case 2) if there is a "cover front" (but not a "cover full") for that game

In case 2) FLOW3D is going to load the "cover front" (that should be made at the standard 2x scale factor, as example the PS3 covers at 260x300 pixels). With this i mean... if we display "cover front" at 2x scale factor + the default "cover side" and "cover back" at 2x scale factor too.... well... the image quality is going to be the same in all them (a bit/lot pixelated, but this is an expected result anyway)

Displaying the "cover front" that are made at 2x scale factor (pixelated) + "cover back" and "cover side" at a bigger scale factor (with less pixelation) doesnt makes much sense

And in case 1)... well... this is just something temporal because the user is not supposed to use FLOW3D without covers... so yeah the result is low quality for good reasons :)

--------------
Is like... building this new feature about displaying default 3D covers in the lowest quality (x2 scale factor) for performance
Incase it works fine and you decide to increase image size later... well... there will be time to readjust the image sizes in the future
 
Last edited:
And btw... you are going to load this default 3D covers in memory in bitmap format, right ?
This default 3D cover images are going to be 100% opaque, we dont need transparencies in them, so we dont really need to use the PNG format, in my previous tests i was making them in PNG for no special reason
Do you think it would be a good idea to create them in BMP format ?. I guess in BMP are going to be a bit bigger in bytes size than PNG (for the first test i will save them at BMP 24bits max quality), but maybe are loaded in memory in a more straightforward way
 
Doesn't matter the format, it will be loaded in memory in 32 (arbg), even if it's only black and white. So, choose the smallest file just to reeduce the size of the pkg.
 
When loaded to memory they takes the same size, but i mentioned BMP format because i was wondering if there are differences of speed in the internal procesess required to convert the pixel data from BMP ---to--> memory, and from PNG --to--> memory

Or from JPG --to--> memory. This would be another way to do it but i guess this is the worst because jpg is a compressed format so i guess the pixel data needs to be decompressed and/or resampled to convert it to argb

Anyway, the image format used is just a detail... what could be more important for the performance is the other thing i mentioned about using default 3D covers made at 2x scale factor. They are going to take less memory space, but also are going to be loaded faster because the smaller size (and incase the pixel data is resampled it should take less time too because are less amount of pixels)
 
I don't know if it's faster, if both function are written the same way, bmp to memory will be faster because there is no decompression step but as I said it depend how it's done. Anyway, if it's faster, we will win few ms, I don't think it's relevant... don't forget it's only KB files :p
 
Hello. I have a problem with managunz. When I try to mount ps2 iso all freeze...
1) Boot managunz
2) Click in the PS2 game icon to mount it
3) Managunz takes you back to main XMB
4) Click in the PS2 game icon to boot it

The freeze happens in step 2 or 4 ?
PS3 model ?
Firmware type/version ?
Game ID ?
 
Happen to step 2 (i see in the bottom of the screen "square for speedup loading")
I use 4.86 rebug lite (latest ver).
Ps3 slim cfw
Problem happen with all ps2 iso
 
Happen to step 2 (i see in the bottom of the screen "square for speedup loading")
I use 4.86 rebug lite (latest ver).
Ps3 slim cfw
Problem happen with all ps2 iso
Do you have cobra enabled (in rebug toolbox) ?
Can you use an option named "Check MD5", located at bottom of the PS2 game settings menu ?, and report back your results
Also, use the other option that display the game "Properties" to check if the info displayed in that screen looks fine
 
Hi, is it possible to boot the iso from Managunz, instead of loading it from the xmb screen ?.
Yes, for PS3 games there is an option where you can enable the "direct boot"
But there are only a few games that supports it. The other games are going to crash when you try to boot them with that option enabled

Also, for the games that supports it, i suggest to take a look with a filemanager to the folder name used in the gamesaves generated when the game was "direct booted". Usually the saves have an incorrect name

All this problems are caused because when we enter in a program like managunz the PS3 firmware knows we are "inside" a program with game ID = MANAGUNZ0... and the game we are "direct booting" doesnt have that ID
That mistmach in between ID's seems to be the cause of the problems, but there is no way to solve it (unless someone finds an alternative way to do a "direct boot" in a different way)
 
Btw @Zar the other day when i was taking a look at the scene lights i had an idea for a cool (and i hope easy to do) visual effect, basically is about using a timer to animate the intensity of the main scene light, it can be used to create "fade" effects in 3 different ways, 2 of them are going to work and look fine, and the other doesnt

Fade IN (when mgz boots)
The time lenght of the fade is not conflictive with any other mgz feature, the time lenght should be short, like 1 second only
The worst thing that could happen is some sentences from the boot logs could not be completly visible, but i dont think 1 second long is going to hide anything
Also, incase there are no boot logs, i dont think nobody is going to enter managunz and press buttons in less than 1 second... i mean, what everybody does when entering mgz is to take a couple of seconds to see what is displayed in the screen

Fade OUT (when booting a game, or exiting without mounting a game, etc...)
This doesnt seems to work fine, because the times when we are exisitng from mgz varies a lot depending of the "tasks" made when quitting, so we cant calculate how many time we have available to display the fade
In few words, it seems is going to be very hard to synchronize this fade OUT, so forget about it ?

Fade NEXT (in between screens)
This is a variant i imagined while thinking in all this, but probably is going to be the most good looking visually :D
The idea is to create a fade OUT--->IN effect to soften the change from the "game selection" screen to the "file manager" screen. And also in between them and the "mgz global settings" screen
Those are the 3 most importants screens of managunz, but the fact is there are other screens where could be added this effect too (PS2 config editor, plugins manager, etc...)

It needs to be something fast because we dont want to disturb much the usage... 1 second total or even shorter
 
Last edited:
That mistmach in between ID's seems to be the cause of the problems, but there is no way to solve it (unless someone finds an alternative way to do a "direct boot" in a different way)

I managed to direct boot some games moving the trophy folder to the backup manager directory, but the save and updates/DLC still are issues.

I wonder if the direct boot issue could solved launching the backup manager from ★ app_home/PS3_GAME icon.
And maybe patching the current title_id in memory (or maybe doing this alone).

Another workaround could be using a vsh plugin running in background for auto-launch the game from the disc icon, when the backup manager mount the game and return to XMB.

webMAN MOD does not have this issue because it's already in XMB when the game is launched.
 
I managed to direct boot some games moving the trophy folder to the backup manager directory, but the save and updates/DLC still are issues.
Intereting results, so maybe the others that was not working was because the trophy installation ?
Anyway, i think this road is not going to give us good results because the saves (and maybe the "first time boot" gamedata installation too) are going to have problems too
I wonder if the direct boot issue could solved launching the backup manager from ★ app_home/PS3_GAME icon.
I remember i had a "PS3go USB dongle" for 3.41 OFW that was doing this, the dongle had a flash storage with a copy of "gaia manager" that was displayed in XMB under APP_HOME... but i dont remember if that version of gaia had the "direct boot" and incase it had it i dont remember the results when using that option
And maybe patching the current title_id in memory (or maybe doing this alone).
I think this would be ideal, i started thinking in it after i wrote my previous post, the problem is a bit of "chicken-egg", we boot the chicken but the firmware keeps a record of the egg, after that we can swap the chicken but there are problems because the egg doesnt matches... so the solution could be to do a magic trick to swap the egg in memory
1) The app boots
2) Scan memory to find the actual ID and overwrite it with the ID of the game we are going to "direct boot"
3) swap the chicken and boot it

Im wondering if the XMB database is going to complain about the swap, i know the entries of the database are updated individually when you "click" in them to boot them... but i dont think it happens when you quit/exit a game/app, dunno, initially i think this is not going to be a problem, but im mentioning it just incase because it could ruin all this method completly, if the XMB database complains about this trick we are not going to be able to use it

Another workaround could be using a vsh plugin running in background for auto-launch the game from the disc icon, when the backup manager mount the game and return to XMB.

webMAN MOD does not have this issue because it's already in XMB when the game is launched.
I was thinking in this lot of time ago, when i was reading some info published in psdevwiki by mysis, there is some interface dedicated to automatize some actions in XMB (and some inputs from dualshock 3), my original idea was something like this:
1) we boot the backup manager
2) we click in a game to direct boot it
3) the app loads a plugin (or enables a function of the payload actually loaded in memory) dedicated to it
4) the plugin starts with a timer, when the timer expires the plugin unloads itself (10 seconds)
5) so... the app exists and "mounts" the game normally in XMB
6) the plugin disables all the real dualshock3 inputs (to prevent the user to mess around with what is going to happen next)
7) the plugin emulates the D-pad movements (mostly a "dpad-up" repeated a variable number of times)
8) the plugin emulates a press of the "cross button" (to boot the game)
9) so... the game boots normally
10) and the timer expires, so the plugin unloads itself automatically

Later i realized you implemented some features in webman related with this automation of actions in XMB, im not sure how they works, but that was pretty cool :encouragement:
Also, there is that official option in XMB settings where we can enable the autoboot of every optical disc inserted in the drive, and this doesnt discriminate in between real discs or virtual (mounted by a backup manager), so we could take advantage of this feature to achive the direct boot
Is just there is lot of people (like me) that doesnt wants to have that option enabled at all times :/
The solution could be to enable it temporally (not in xregistry.sys but in memory?)... but dunno maybe this is not good enought and could be problematic, im just brainstorming a bit
 
Last edited:
Btw @Zar the other day when i was taking a look at the scene lights i had an idea for a cool (and i hope easy to do) visual effect, basically is about using a timer to animate the intensity of the main scene light, it can be used to create "fade" effects in 3 different ways, 2 of them are going to work and look fine, and the other doesnt

Fade IN (when mgz boots)
The time lenght of the fade is not conflictive with any other mgz feature, the time lenght should be short, like 1 second only
The worst thing that could happen is some sentences from the boot logs could not be completly visible, but i dont think 1 second long is going to hide anything
Also, incase there are no boot logs, i dont think nobody is going to enter managunz and press buttons in less than 1 second... i mean, what everybody does when entering mgz is to take a couple of seconds to see what is displayed in the screen

Fade OUT (when booting a game, or exiting without mounting a game, etc...)
This doesnt seems to work fine, because the times when we are exisitng from mgz varies a lot depending of the "tasks" made when quitting, so we cant calculate how many time we have available to display the fade
In few words, it seems is going to be very hard to synchronize this fade OUT, so forget about it ?

Fade NEXT (in between screens)
This is a variant i imagined while thinking in all this, but probably is going to be the most good looking visually :D
The idea is to create a fade OUT--->IN effect to soften the change from the "game selection" screen to the "file manager" screen. And also in between them and the "mgz global settings" screen
Those are the 3 most importants screens of managunz, but the fact is there are other screens where could be added this effect too (PS2 config editor, plugins manager, etc...)

It needs to be something fast because we dont want to disturb much the usage... 1 second total or even shorter

I'm not working on mgz right now, but when I'll come back to it I don't think i'll work on visual aspect, I'll focus on "real" features ;)
 
Back
Top