Quote:Maybe your hex editor is trying to interpret it as ASCII?
I know, for example, UltraEdit does try to revert to a textual input if you give it a text file.

could be, but as I mentioned, i saved the file, then reopened it and looked that it didn't change the symbol to anything, so my flawed logic tells me it should be identical to the original working one.
Well it's not really a big deal either way so don't waste your time on it.

Quote:PRXs are compiled code, so it's not going to be easily manipulated like RCOs.
I don't have a PS3 so I haven't looked in those files, no, and probably won't due to aforementioned reason.
Good luck on finding the icons though.  You can try searching for references to "GIM" in the PRX files if you believe they're in there.

i tried looking for GIM headers from few but failed to find anything so far. Ps3 XMB is far more complex than it gives away, and unfortunately, it's very much different from psp's layout.

the ps3 prx's are elf files so i suppose they can be disassembled somehow, though that's hardly my area of expertise.
I was sort of hoping you'd know about it seeing you have burned some time doing things regarding psp's XMB modding, but can't have it all I guess :P

you don't happen to know who mapped the editable attributes for psp prx files ? i know there's editors that allow an rco+prx to be loaded and then modified so maybe the people behind that would be able to help me with mapping them for ps3.

In he meantime I'll burn my time doing some testing with the unknown params of RCOmage and hunting down the remaining icons and modules...

thanks for all the help so far by the way, I've managed to do some neat stuff with rcomage so far :) the app is awesome.

im trying to find out images and the values and everything else pretty much.
the ultimate goal of my research of these files is to have everything figured out so that ps3 XMB could be modified just like psp's.

what comes to using the xml values as reference, that would be impossible unfortunately.
only plain values there are are width,height,posX and posY (and posZ) and in most if not all cases, this is always width=0, height=0, posX=0, posY=0 and posZ=0
while the positioning can be changed here, the defaults are loaded into the prx's directly, and the size and location attributes of elements are parentrelative (to a parent i haven't fully figured out yet., it has something to do with a plane the element is loaded on), so there's no clear point of reference to compare anything to anything.

in the example of the clock i made you see on the pic, the image size was defined as 0,0 and changing the image size itself didn't resize the element so it has to be coded elsewhere.
i overwrote them in the xml but left the attributes of the ticks to 0,0,0,0,0 because their positioning and size is relative to the busy icon itself (the clock face)

i don't really know enough yet to draw any solid conclusions... :(

proudly doubleposting once again :P

could you please take a look at the gims i uploaded here and tell me what's different in tex_user.gim and tex_sysconf.gim than the rest does.
i can't figure this out for the life of me.

when said plugin is extracted and repacked (gim's converted to png) every other gim fails to work aside user and sysconf.

tried compiling them with (gimconv --image_format dxt5 input.png -o output.gim) and no cigar.


  xmb_ingame.rar (Size: 22.9 KB / Downloads: 293)

they are originals extracted without converting.

im pretty much at a loss here, as only thing i ever noticed from these is the fact that tex_psn looks like it's lower quality than it's main counterpart (the one that shows up in normal XMB state)
it looks like it might have a reduced colorspace or something.

are gims always 24bit + alpha or does it come from the source png ?
im gonna try and do a reduced colorspace ones and see if that helps it.

i know it's not a space issue on the flash, or an allocated space issue on ram because I've tested with larger files and smaller files and identically sized files and whatever i could think of.

using the currently working method after you fixed the gimconv.cfg for me, the 2 images work and rest corrupt (white square)
the -ps3 switch alone makes them dissappear (wrong formatting)
using DXT5 does same as above.

.....sigh :(

im just missing out on something very simple and obvious here i think.

I've been toying with gimconv now and it's possible I've tried generating every type of gim possible with it, no success.
smaller files than originals = don't work
identical sized = don't work
bigger ones = don't work
anything made with weird switches of gimconv = don't work

only ones that do work are the original gims
only ones that appear as a white square are with rcomage's current conversion settings after your latest gimconv.cfg fix.
anything else = icon vanished, no corrupted graphics, no nothing :/

the funny part is that tex_user and tex_sysconf work, the rest doesn't

so far i can only generate broken things in modules that are used in ingame-XMB
the clock mod i did corrupts (only) in ingameXMB too, and these gims here are specific to that function.

oh yeah, the background of the digital clock also works, there's a separate gim for it for XMB and ingame XMB. Like tex_user and tex_sysconf, it works wonders.

sony just makes me facepalm. What the hell did they do really..

not all images are in the rco files indeed.

i know that the psn category's custom wallpapers, some icons (f@h, widgets, such things) reside in dev_flash/vsh/resource/explore/
also, some icons are nowhere to be found on current means.

a batch of rco files and otehr modules are hidden somewhere i believe is not accessible yet.
there's metldr which is a complete mystery, and i found references to non-existant rco/sprx files from the boot sequence along with a location called /dev_system...
whatever it is, can't really say. I lack time to properly research things at the moment.