PS3 [Discussion] 0.90 DECR XMB Entries on 4.84

Discussion in 'XMB Modifications' started by dazzaXx, Mar 19, 2019.

  1. 406
    252
    122
    dazzaXx

    dazzaXx Member

    Joined:
    Feb 4, 2018
    Messages:
    406
    Likes Received:
    252
    Trophy Points:
    122
    Gender:
    Male
    Occupation:
    XMB UI Editor/Coder, VENOM ELITE GAMING
    Location:
    United Kingdom
    Might've removed it.
     
    Last edited: Mar 25, 2019
  2. 406
    252
    122
    dazzaXx

    dazzaXx Member

    Joined:
    Feb 4, 2018
    Messages:
    406
    Likes Received:
    252
    Trophy Points:
    122
    Gender:
    Male
    Occupation:
    XMB UI Editor/Coder, VENOM ELITE GAMING
    Location:
    United Kingdom
    Also i'd appreciate it a lot if you were able to do that and DM me a link or something, i've scoured the entire internet and only found 0.90.002.
     
  3. 6,924
    8,226
    797
    DeViL303

    DeViL303 Developer PSX-Place Supporter

    Joined:
    Jan 23, 2016
    Messages:
    6,924
    Likes Received:
    8,226
    Trophy Points:
    797
    Occupation:
    Part-Time XMB Modder
    Location:
    Ireland
    I will do that.
     
    dazzaXx likes this.
  4. 1,692
    1,152
    297
    Naked_Snake1995

    Naked_Snake1995 Senior Member

    Joined:
    Dec 11, 2017
    Messages:
    1,692
    Likes Received:
    1,152
    Trophy Points:
    297
    Gender:
    Male
    Occupation:
    Graphic Designer
    Location:
    NEC/TOKIN wants to know your location
    Sounds neat mate, i would be more than glad and thankful, to learn to work on a CFW, although my main profession its Graphics Designer, i am always open for new ideas :)

    Sent from my G8341 using Tapatalk
     
    T.A.U and dazzaXx like this.
  5. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Thread has been moved to "XMB Modifications" subforum

    There was a few things i would like to mention before i forgot related with this

    An small detail without much importance is the size override values i suggested you to use @DeViL303 are loading the same values than in the official firmware 0.90 (the real image had a size of 640x600pixels so 2 of the the overrides i suggested are loading the values 640 and 600)
    I was taking a look at your rco and noticed what you are doing is to multiply this size values (with the attribute sizeScaleX/Y/Z) by 0.6 or so

    This way you was able to change the displayed size without modifying my overrides... and technically is fine, there are veeeery few places in the official firmware where is made that way though
    The point is you are doing an additional math operation, but i guess doesnt matters much because it could only hit in the performance, but most probably the performance hit is ridicully small
    Anyway, just wanted to mention it because usually is better to avoid using that attributes named sizeScaleX/Y/Z

    -----------------------
    I was talking with @M4j0r about this (few days before this thread existed, heheh), this is a photo he made with the first impose_plugin.rco 4.84 i made, where i was using exactly the same sizes, positions, and the same GIM (exact binary) from 0.90
    [​IMG]
    Some details that worths to be mentioned:
    This exposes very well the differences in the positions of every element of this screen in between 0.90 and 4.84
    In 0.90 the right border of the image was located at center of the screen... and the texts ("turn off the system", and "turn off the controller") had the left margin aligned to center too... so in few words... in 0.90 you had the image at left and texts at right
    But in 4.84 firmware the texts are located at center, grrr...
    We thought in moving the texts, etc... but instead we stepped back trying to imagine why the image was displayed in white

    There is other overlap of the image at bottom-left, because that small icons for the dualshock was displaced to other position (at this point i did not waste much time in trying to imagine how to solve it, but i did this in the meantime). It was a coincidence that icons was using some attribute values rarelly used in official firmware, and by looking at them it helped me to understand a bit better how the rco object works. I need to continue writing something more in that thread because i found one more thing that in some way completes what i was explaining about how the overrides works ;)

    Anyway... at that point @DeViL303 had the impose_plugin.rco working with some tweaks and we abandoned a bit this story

    -----------------------------
    I still have my doubts about what is causing this problem with the white images, initially i agree that most probably is a memory size problem, but i would not bet in it
    One of the most weird things that was mentioned in this thread is the fact that the position of the image inside the <ImageTree> affects the others, and that relationship in between the "cause" image, and the "consequence" image doesnt looks straightworward (not sure how to explain this in concept, read back the talk)
    In my oppinion this is the most obvious key point needed to follow to resolve this mistery... or in other words, by finding how an image affects other image we will have a better understanding of what is happening and how it happens

    -----------------
    But lets take other approach, and acept the theory that there is a problem of memory size, and that size is defined "somewhere"
    @M4j0r mentioned me that a good candidate to store memory sizes is basic_plugin.sprx i guess he said it because this plugin exists in firmware 0.90
    I decrypted it and was taking a rought look at it in HxD... the idea was... if basic_plugins.sprx is storing the memory size of the rcos from other plugins, then it should contain some kind of "table" with lot of entryes (hundreds because there are hundreds of rcos)
    This could be the kind of "checkered pattern" that can be identifyed visually in a hexeditor
    I know... is a noob approach, im not disasembling it, not using ida or any serious tool... it was just a rought check... and as you deduced at this point i failed miserably
    I could not find anything like what i was expecting to find :D

    -------------------------
    When i was looking at basic_plugins.sprx i was thinking in other alternative ways to manage memory
    To me makes more sense that every "memory size for rco contents" value is defined by every sprx
    The point is... i think the sequence is like this... the sprx is loaded, and it reserves some memory space, then the rco contents are extracted in the reserved space
    But is not so straightforward, because every rco content needs to be extracted in a different place of the memory map, and this is related with the rco internal structure

    The text strings are stored in a place, entire numbers in a array, another array for the foats, other for the textures, etc...
    I think all this definitions for memory sizes should be located together in some point of the .sprx
    And initially... what we are searching for is the memory reserved for the textures (not the whole rco contents)

    The firmware can read the real sizes from the rco structure... but this is not what we need to change... we are looking for a place where there is a value working as a restriction

    So... dunno... but my guess is they prepared this features for memory management very well and very detailed to have the best control posible
    The restriction could be located in everyone of that defintions (very hard to find)... or maybe is something generic (easy to find)

    ------------------------------
    But finding that restriction for memory management could be one of the best things ever found, it could be used in 2 different directions
    First we could "remove the garbage" to make the firmware functions fasters indirectly, to reduce the memory footprint, and to release memory for the taxing custom process (like the video recording plugin made by mysis that always suffered by memory problems)
    And after removing the garbage we could use that recovered space to add nice mods
    The rule is a bit... for every piece of garbage you remove, you have room to add a cool thing

    impose_plugin.rco is a good example of this, as i mentioned in a post before, there are 6 "shadow" images that can be removed, are pointless because are displayed on top of black so are almost invisibles
     
    Last edited: Apr 6, 2019
    T.A.U likes this.
  6. 6,924
    8,226
    797
    DeViL303

    DeViL303 Developer PSX-Place Supporter

    Joined:
    Jan 23, 2016
    Messages:
    6,924
    Likes Received:
    8,226
    Trophy Points:
    797
    Occupation:
    Part-Time XMB Modder
    Location:
    Ireland
    Yeah, I think we can definitely slim down FW and save some RAM most likely, for example, I noticed when looking at software update rco, it has loads of arcade stuff in it, no need for it, lots of rcos are like that, we could slim them all down, remove unused images etc. same with xmls, I think every icon showing on XMB is having in effect, especially scrolling stuff like wboard etc.

    So we could make super efficient CFW i bet, and OFW, as these mods would work there too. Then another level altogether would be doing same to sprx files if possible. zeroing out loads of unused stuff. stopping all unwanted process before they even start. Think about it, we have one process logging stuff, and another removing the logs, completely arseways way to do it in a way, we could patch out the logging altogether, just a small example.


    BTW, with the impose rco, I think it might be under different rules to others, as it can be used in game, so maybe ingame rcos are restricted a lot more, that would make sense to me. I know i have added loads of stuff to explore_full rco, and category rcos, so i dont think there is any general restriction. With impose rco i got away with adding about 3kb, that was all. :)
     
    T.A.U and sandungas like this.
  7. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Yes, inside rcos there are lot of images that can be removed, like the shadows from impose_plugin.rco i mentioned, sometimes is not so straightforward though, but the shadows from impose_plugin.rco are easy because there is a xml line specific for everyone of them... you just need to delete that line, delete the entry in <ImageTree>, then delete the file and everything will kept connected, no error
    For every image candidate to be removed is needed to check if is made this way, at this point im not sure if is very frequently made this way though

    And there is another thing that can be made with the GIM images, i started thinking in this while looking at the available image formats allowed by GIM format
    The point is every image format is intended to be used for a specific case, most GIM images are rgba8888 (this is considered the max quality available) but there are a looooooot that doesnt needs that quality
    -If the image is in grayscale (like all official XMB icons) then there is a different image format that should result visually the same
    -If the image is fully opaque, there is an image format without alpha channel
    -If the image only needs a few levels of transparency (usually in small icons with 4 or 5 is good enought) there is another image format with reduced alpha channel

    And in general there are a looooooooot of images that we never see, because are used very deep in some weird function that nobody uses (like the printer support)
    The point is... nobody (or not much people) uses that images, so who cares if we replace them by the same images in lower quality ?

    As you can see by following this rules we could potentially reduce the size of most/all the images \o/
    There are going to be only a few that his "high quality" worths to be preserved (or improved, because i know very well that the official icons have lot of pixel garbage and innacuracies)

    ----------
    In the XMBML files too, there is some obvious things that can be removed safelly
    With the sprx i guess is not posible to cut them down, but it could be posible to stop them from being loaded in first place
    I guess the lists inside xmb_plugin.sprx and xmb_ingame.sprx are a good place to stop them
    A different matter could be to disable also the other places of the firmware that was trying to communicate with them
    I mean, is not a matter of stopping them, but is also needed to "cut" the connections with them, and this is the kind of things hard to imagine how many there are

    Hmmmm, but i guess xmb_ingame.sprx is not loaded (or small bits of info readed from it without loading it) when you initiate impose_plugin.sprx
    If i remember right... @dazzaXx mentioned the memory problems before our talk, when he was adding a huge icon of a animal in right-bottom corner in the first versions of his clock mod. And @LuanTelles mentioned it too, he was hitting with one of that restrictions in the "PS3 PRO 4K MOD"

    I remember they was talking about it because in some way it lighted my spark, it was the first time i thought about it and made me think that maybe they are right
    Later, your tests by reducing size of the image for impose_plugin.rco confirmed it partially

    In some way this is very important because i always thought the errors of images displayed in white was caused because the GIM file was rebuild with GIM settings different than the original
    The theory was... that images are displayed by openGL, and there should be some part of the code where is specifyed the image type that needs to be displayed in every place, that code is part of openGL libraryes or who knows so is "harcoded" (we cant change it)
    The complementing theory 2 was... every "enviroment" of the PS3 interfaces is built using the same image types... and in that screen could be displayed multiple images that could belong to different rco files.. and thats the reason why we have rco files with GIM files inside made with diferent settings... because every GIM image is intended to be displayed in a different screen (under strict image type rules)

    I know time ago that is posible to replace some of the GIM files originally made with the option -ps3dxt5 by -ps3rgba8888
    But i always thought this "compatibility" was happening because the -ps3rgba8888 is used as the "standard"... in some way like if -ps3rgba8888 was compatible globally (for all the envoriments and visual interfaces of the PS3)

    But now im changing my mind a bit, and not sure how much of that is correct :P
     
    Last edited: Apr 6, 2019
    dazzaXx, T.A.U and DeViL303 like this.
  8. 6,924
    8,226
    797
    DeViL303

    DeViL303 Developer PSX-Place Supporter

    Joined:
    Jan 23, 2016
    Messages:
    6,924
    Likes Received:
    8,226
    Trophy Points:
    797
    Occupation:
    Part-Time XMB Modder
    Location:
    Ireland
    What we can probably do too is use this blank.gim to replace lots of gims in rcos, this way, even if image does get called somehow , at least it got something to load, and its only 144bytes. Its transparent and 1x1 pixels.
     

    Attached Files:

    T.A.U and sandungas like this.
  9. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Ahh, yes thats another technique to reduce sizes radically, the widthxheight of the GIM files doesnt matters, because are defined in the rcoxml code
    The firmware takes the GIM image and scales it (up or dows as needed) to the size defined in the rcoxml code

    So you can create a GIM of 1x1 pixels (or 2x2 incase openGL refuses images of 1x1), fully transparent and use it as a dummy... and for the GIM settings of it... dunno, you could go radical again and build it with -ps3dxt1 or -ps3index4
    This 2 options are going to generate the most minimalistic GIM size (not sure which one is going to win the minimalistic championship, but i bet for -ps3dxt1)

    ----------
    Btw, i almost forgot, and this talk made me remember it... another thing i wanted to suggest you is to use one of this "medium quality" image formats for the custom image_plugin.rco with the image from 0.90
    You was having problems because it was displayed in white at big sizes, so you decided to reduce it in size... but you reduced it a lot, this is why it looks pixelated when displayed in PS3
    The image is tiny, but is displayed at x2 or x3 his size

    The only way to reduce pixelation is either by unlocking that memory restriction (that we dont know where is it, so lets forget about it by now), or by using a different image format

    Initially i think you could try with -ps3rgba5650 (this format doesnt have alpha) because the image is fully opaque
    I think this is going to allow you to increase his size to double or so

    Another one you could try is -ps3index16
    This is an intermediate quality, not sure how good is going to match with what you want to do and which size it will result
     
    T.A.U and DeViL303 like this.
  10. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Hmmm for the record, i just reminded there are some alternative ways to store images inside RCO files that maybe could solve indirectly the problem we was talking about



    ZLIB compressed GIM
    This is the most usual in OFW, most images inside RCO files are stored this way
    The image is in GIM format, and is compressed to ZLIB when stored inside the RCO, the PS3 reads the RCO index to locate the image, in the index there is a value that indicates the "decompressed size" so the PS3 reserves that space in memory and then decompress the GIM in that reserved space
    Code:
    <RcoFile UMDFlag="0" rcomageXmlVer="1.1" type="ps3" minFirmwareVer="unknownId0x130">
    	<MainTree name="impose_plugin">
    		<ImageTree>
    			<Image name="tex_ps3black" src="Images\tex_ps3black.gim" format="gim" compression="zlib" unknownByte="0" />
    		</ImageTree>
    	</MainTree>
    </RcoFile>
    


    Uncompressed GIM
    This is used in OFW but rarelly, the file is the same than in the example above, but we are removing one step of the procedures (the PS3 doesnt needs to do the ZLIB decompression)
    Code:
    <RcoFile UMDFlag="0" rcomageXmlVer="1.1" type="ps3" minFirmwareVer="unknownId0x130">
    	<MainTree name="impose_plugin">
    		<ImageTree>
    			<Image name="tex_ps3black" src="Images\tex_ps3black.gim" format="gim" compression="none" unknownByte="0" />
    		</ImageTree>
    	</MainTree>
    </RcoFile>
    


    Uncompressed PNG/BMP/JPG
    This is used in OFW too but rarelly, in the example im suggesting to use BMP because the image from impose_plugin.rco 0.9 we are talking about doesnt have transparent pixels, and i think the pixel info that is going to be copyed to memory is the same you would achieve with a GIM built with the option -ps3rgba8888
    Code:
    <RcoFile UMDFlag="0" rcomageXmlVer="1.1" type="ps3" minFirmwareVer="unknownId0x130">
    	<MainTree name="impose_plugin">
    		<ImageTree>
    			<Image name="tex_ps3black" src="Images\tex_ps3black.gim" format="bmp" compression="none" unknownByte="0" />
    		</ImageTree>
    	</MainTree>
    </RcoFile>
    


    ZLIB compressed PNG/BMP/JPG
    I dont remember to see this one used in OFW but i bet is allowed, most probably what happens is not much practical (so they implemented it just incase and later they gave a f***), but if this solves the problem we was having then is welcomed :)
    Code:
    <RcoFile UMDFlag="0" rcomageXmlVer="1.1" type="ps3" minFirmwareVer="unknownId0x130">
    	<MainTree name="impose_plugin">
    		<ImageTree>
    			<Image name="tex_ps3black" src="Images\tex_ps3black.gim" format="bmp" compression="zlib" unknownByte="0" />
    		</ImageTree>
    	</MainTree>
    </RcoFile>
    




    -------------------------------------------------------------------------
    Disclaimer:
    The attribute compression="none" needs to be written this way if you are using the RCOmage psdevwiki MOD
    Otherway, if you are using one of the official rcomage versions released by zingaburga you need to write compression="uncompressed"
     
    Last edited: Apr 8, 2019
  11. 934
    1,015
    247
    LuanTeles

    LuanTeles Senior Member

    Joined:
    May 15, 2017
    Messages:
    934
    Likes Received:
    1,015
    Trophy Points:
    247
    Gender:
    Male
    Occupation:
    Civil Engineer
    Location:
    São Paulo - Brazil
    Home Page:
    Hey Guys I spent all night about 10 hours trying to have the old 0.90 PS3 FW image in the IMPOSE.RCO like the one provided by the @DeViL303

    I don't know if you guys saw but the one he provided crashes when pressing the PS button, due the fact that shadow image lines has been removed to shrink down the rco size. Removing any of those lines the in-xmb battery icon will crash

    So i managed to keep them and replace the controller shadow with a 144bytes transparent blank image that worked good.

    Now i put my pro mod stuff in there, 1 different color for each controller and the Animated X and O buttons.

    The Rco file size is now 51KB bigger than this will break some stuff (Blank Icons)

    But i have a bug since the first version

    in 1080 i / p (The Correct Size)



    in 720 p and below (480p the icons will be even bigger)




    I know it can be fixed using the table_grid and table_factor

    But since the rco already uses it for the X and O button i used the same, but the result is the icons bigger than before

    The original X icon as e.g

    Code:
        <Plane name="cross_shadow" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x85020000" positionOverrideY="0x89020000" positionOverrideZ="0x0" sizeOverrideX="0x8a020000" sizeOverrideY="0x8b020000" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0">
                            <Plane name="cross_icon" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x8c020000" positionOverrideY="0x8d020000" positionOverrideZ="0x0" sizeOverrideX="0x8a020000" sizeOverrideY="0x8b020000" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0"></Plane>
                            <Text name="cross_label" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="1" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x3100" onInit="nothing" positionOverrideX="0x8e020000" positionOverrideY="0x8f020000" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" textMessage="nothing" textFontStyle="nothing" textFontMode="0x1000001" textUnk29="0x1" textFontSizeY="0" textTopColorScaleR="1" textTopColorScaleG="1" textTopColorScaleB="1" textBottomColorScaleR="1" textBottomColorScaleG="1" textBottomColorScaleB="1" textLineSpacing="0" textUnk37="0x0" textUnk38="0x0" textUnk39="0x0" textCharacterSpacing="0" textShadowOffsetX="4" textShadowOffsetY="-5" textShadowOffsetZ="0" textShadowColorScaleR="0.25" textShadowColorScaleG="0.25" textShadowColorScaleB="0.25" textShadowColorScaleA="1" textUnk48="0x0" textUnk49="0x0" textUnk50="0x0" textUnkFloat51="1" textUnkFloat52="1" textUnkFloat53="1" textUnkFloat54="1" textResizeMode="0xffffffff" textOverrideUnk56="0x15000000" textOverrideUnk57="0x3000000" textOverrideUnk58="0x0"></Text>
                        </Plane>
    And my modded one is

    Code:
        <Plane name="cross_shadow" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x85020000" positionOverrideY="0x89020000" positionOverrideZ="0x0" sizeOverrideX="0x8a020000" sizeOverrideY="0x8b020000" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0">
                            <Plane name="cross_icon" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0"></Plane>
                            <Plane name="cross_box_plane" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="0" sizeX="480" sizeY="272" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0">
                                <Plane name="cross_x_plane" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="0" sizeX="480" sizeY="272" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="anim:cross_box_init" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0">
                                    <Plane name="cross_1_plane" positionX="6" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="25" sizeY="25" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="image:tex_error_batsu" planeResizeMode="0x0"></Plane>
                                    <Plane name="cross_2_plane" positionX="-6" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="25" sizeY="25" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="image:tex_error_batsu" planeResizeMode="0x0"></Plane>
                                </Plane>
                                <Plane name="cross_y_plane" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="0" sizeX="480" sizeY="272" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0">
                                    <Plane name="cross_3_plane" positionX="0" positionY="6" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="25" sizeY="25" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="image:tex_error_batsu" planeResizeMode="0x0"></Plane>
                                    <Plane name="cross_4_plane" positionX="0" positionY="-6" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="25" sizeY="25" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="image:tex_error_batsu" planeResizeMode="0x0"></Plane>
                                </Plane>
                                <Plane name="cross_z_plane" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="0" sizeX="480" sizeY="272" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0">
                                    <Plane name="cross_5_plane" positionX="0" positionY="6" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="25" sizeY="25" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="image:tex_error_batsu" planeResizeMode="0x0"></Plane>
                                    <Plane name="cross_6_plane" positionX="0" positionY="-6" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="25" sizeY="25" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x0" positionOverrideY="0x0" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" planeImage="image:tex_error_batsu" planeResizeMode="0x0"></Plane>
                                </Plane>
                            </Plane>
                            <Text name="cross_label" positionX="0" positionY="-6" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="1" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x3100" onInit="nothing" positionOverrideX="0x8e020000" positionOverrideY="0x8f020000" positionOverrideZ="0x0" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" textMessage="nothing" textFontStyle="nothing" textFontMode="0x1000001" textUnk29="0x1" textFontSizeY="0" textTopColorScaleR="1" textTopColorScaleG="1" textTopColorScaleB="1" textBottomColorScaleR="1" textBottomColorScaleG="1" textBottomColorScaleB="1" textLineSpacing="0" textUnk37="0x0" textUnk38="0x0" textUnk39="0x0" textCharacterSpacing="0" textShadowOffsetX="4" textShadowOffsetY="-5" textShadowOffsetZ="0" textShadowColorScaleR="0.25" textShadowColorScaleG="0.25" textShadowColorScaleB="0.25" textShadowColorScaleA="1" textUnk48="0x0" textUnk49="0x0" textUnk50="0x0" textUnkFloat51="1" textUnkFloat52="1" textUnkFloat53="1" textUnkFloat54="1" textResizeMode="0xffffffff" textOverrideUnk56="0x15000000" textOverrideUnk57="0x3000000" textOverrideUnk58="0x0"></Text>
                        </Plane>
    Yeah there are some psp code on it since i used it a long time ago in my psp theme And i didnt set the Overrides

    if i set them as the Cross Icon


    Code:
    <Plane name="cross_icon" positionX="0" positionY="0" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="0" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" anchorMode="0x0" onInit="nothing" positionOverrideX="0x8c020000" positionOverrideY="0x8d020000" positionOverrideZ="0x0" sizeOverrideX="0x8a020000" sizeOverrideY="0x8b020000" sizeOverrideZ="0x0" planeImage="nothing" planeResizeMode="0x0"></Plane>
                            
    it will be bigger than normal, isnt supposed to follow the right sizes?

    And how did this line calls the X icon? since it isnt linked with a image file?



    I need some help to figure it out and implement them in the others moddeds rcos!



    Any idea guys? @DeViL303 @sandungas @dazzaXx @pinky

    i attached my rco if you guys want to see all the code
     

    Attached Files:

    jeka26 and sandungas like this.
  12. 6,924
    8,226
    797
    DeViL303

    DeViL303 Developer PSX-Place Supporter

    Joined:
    Jan 23, 2016
    Messages:
    6,924
    Likes Received:
    8,226
    Trophy Points:
    797
    Occupation:
    Part-Time XMB Modder
    Location:
    Ireland
    My rco was not crashing anything here AFAIK, was working fine. try it without any of your other mods.
     
  13. 2,659
    1,306
    297
    Cypher_CG89

    Cypher_CG89 Senior Member

    Joined:
    Jul 30, 2018
    Messages:
    2,659
    Likes Received:
    1,306
    Trophy Points:
    297
    Gender:
    Male
    Occupation:
    Lead Graphic Artist/Dev, VENOM ELITE GAMING
    Location:
    North East, England, UK
    It crashed the PS3 for me too when trying to access the in game xmb menu, the impose screen works fine.
     
  14. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Im trying to understand all you wrote, i will try to answer in parts
    I uploaded a collection of "dummy" GIM files here:
    https://www.psx-place.com/threads/research-rcomage-psdevwiki-mod.17958/#post-170597
    All them are very small because have a size of 1x1 pixels and are fully transparent (so are not visibles when displayed)
    I made them because i was trying to see which image format settings generates the smallest GIM files and which ones have a better compression ratio, also because the official gimconv.exe tool allows to create that 14 GIM formats for PS3 (all them are diferent)
    Try them, i guess this will help you to reduce the rco size, this was the goal when i made them and im confident are well made :)

    About the bug when pressing "PS" button "ingame"... im not sure if someone tryed that... and now you are mentioning it looks we didnt realized it was needed to made that test, ooops

    But you are right, the impose plugin that appears in main XMB is a bit different than the one that appears "ingame"
    I was looking at this months ago (when we was researching about imagefont.bin icons)... and if i remember right one of the differences is the DualShock 3 battery icons
    I dont remember exactly what happens with them... but i remember very well they have something a bit weird
    So... dunno, but maybe you are right and is needed to keep that shadows for the batery icons (in that case try with my GIM dumies, they "should" work)
     
  15. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    @LuanTeles i been looking at your xml's and honestly i dont know why happens that, there are too many custom planes added by you under <Plane name="cross_box_plane"> with custom values related with size and positions
    As a general concept i can tell you the plain sizes and positions (used by psp) needs to be summed (or multiplyed) by the others overridesize and overrideposition
    The resulting value (used to display the image in screen) is a math operation with all them
    As example... if you have an size override with value = 1 (for all resolutions) then is multiplyed for the plain size and the result is exactly what you wrote in the rco
    Another example... if you have a size override of 1.5 (for 720p resolution) and the plain size you wrote in the rco is 20 the image is going to be displayed as 30

    Btw, by looking at the videos it looks you have a problem with the sizes... but the positions are fine
    And btw, i see you displaced some images 6 pixels up and others 6 pixels down, this is made on purpose i guess to disalign them, right ?

    Also, the values of sizes and positions are affected by the parents of the hierarchy by the "anchorMode"... i dont think the problem is related with this, but im just mentioning it because could affect the position and sizes of "childrens"





    Edit:
    Woooho, i think i got it.... and i found a useful trick you are going to love because it makes things a loooot easyer :P.... hmmm, not so easy
     
    Last edited: Jul 27, 2019
    DeViL303 likes this.
  16. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Look at this (lines 6, and 7 of the .txt files), it does rings some bells ? (related with what i was mentioning in my previous post)

    dev_flash/vsh/etc/layout_factor_table_1080.txt
    1
    0
    0
    1920
    1080
    1
    1


    dev_flash/vsh/etc/layout_factor_table_720.txt
    1
    0
    0
    1280
    720
    0.6667
    0.6667


    dev_flash/vsh/etc/layout_factor_table_480.txt
    1
    0
    0
    640
    480
    0.4444
    0.3333


    dev_flash/vsh/etc/layout_factor_table_272.txt
    1
    0
    0
    854
    480
    0.4444
    0.4444

    -----------------------------
    The idea is... you can work at 1080p and write the real sizes in the rco (appropiated for 1080p)... then use the overrides to multiply them by line 6 and 7 of the .txt files
    As you can see (for 480p but can be applyed for all) line 6 is intended to be used in X axis ....and line 7 is for Y axis

    Because are located at the first positions of the .txt... we can deduce are loaded by lot of "planes" inside lot of rco's (we dont know which ones, and we dont care by now)
    So... that scale factors are something generic... actually i was making some calculations and it looks can be applyed to everything :P

    Lets use your animated cross icon for the example... you wrote in the rco that have sizeX="25" sizeY="25". So the "fix" could be:
    sizeOverrideX="here load line 6 of the .txt"
    sizeOverrideY="here load line 7 of the .txt"

    For 1080p are going to be multiplyed by 1, so... 25 * 1 = 25
    For 720p are going to be multiplyed by 0.6667, so... 25 * 0.6667 = 16,6
    And so on :)
     
    dazzaXx likes this.
  17. 934
    1,015
    247
    LuanTeles

    LuanTeles Senior Member

    Joined:
    May 15, 2017
    Messages:
    934
    Likes Received:
    1,015
    Trophy Points:
    247
    Gender:
    Male
    Occupation:
    Civil Engineer
    Location:
    São Paulo - Brazil
    Home Page:

    DAMNNNN @sandungas IT WORKED


    Thank you so much, so now i can finally fix that
     
    sandungas and DeViL303 like this.
  18. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Really ? yeah is a bit awesome because is going to make all that calculations very easy
    You just need to work at 1080p and forget about the other resolutions... then use the same multiplyers for everything
    I mean... you need to use the same overrides for all other custom stuff you did... this way everything is going to be scaled properly... not sure if is going to be so simple but in theory i thing it should

    Which values you used for the overrides btw ?... is the kind of thing everybody could use

    And btw... if at some point sony releases firmware 4.85... you need to take a look at the layout_factor_table_*.txt (the 4 of them) to check if the multiplyers you are using are still located in the same position (lines 6 and 7 in the .txt)
    Eventually they adds more values in the .txt files, if for some reason they adds a new value before line 6 then all the other values after line 6 will be displaced in firmware 4.85 (and this will break your mod)
    I dont think it will happen... but im advising just incase it happens you already knows how to fix it :)
     
    Last edited: Jul 27, 2019
    LuanTeles likes this.
  19. 5,782
    5,394
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,782
    Likes Received:
    5,394
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Btw @dazzaXx take a read at the previous posts, you are going to undertand it (because you already understand how some of the overrides works) and you are going to love it too :D

    This overrides are new, i didnt mentioned much about them before but works in a bit different way, the firmware does a different math operation with them and can be used as multiplyers, very handy if used well
     
    LuanTeles likes this.
  20. 934
    1,015
    247
    LuanTeles

    LuanTeles Senior Member

    Joined:
    May 15, 2017
    Messages:
    934
    Likes Received:
    1,015
    Trophy Points:
    247
    Gender:
    Male
    Occupation:
    Civil Engineer
    Location:
    São Paulo - Brazil
    Home Page:

    I used the sizeX="25" sizeY="25" that matches the default X and O icons in the XMB

    and calculated the Overrides as you said, using only the factor table

    Line 6 for X and Line 7 for Y

    So reversing the steps that you explained in other posts

    Ignoring the layout_grid_table , because the layout_factor_table has the values that we want

    For X

    0000 0006 <--------- First Group is for the layout_grid_table, so i set them to 0, Second Group is for the layout_factor_table (Line 6)
    0000 0005 <--------- Removing -1
    0x0000 0x0005 <--- Hexing Them
    0x0000 0x0500 <--- Flippling the bytes
    0x00000500 <------- Joining them

    So i got sizeOverrideX="0x00000500"

    For Y
    0000 0007 <---------- First Group is for the layout_grid_table, so i set them to 0, Second Group is for the layout_factor_table (Line 7)
    0000 0006 <--------- Removing -1 due the fact the system sees the first line as 0
    0x0000 0x0006 <--- Hexing Them
    0x0000 0x0600 <--- Flippling the bytes
    0x00000600 <------- Joining them

    So i got sizeOverrideY="0x00000600"


    Now my icon Size multiplies it for each resolution

    sizeX="25" x the layout_factor_table_1080 line 6 = 25 x 1 = 25
    sizeY="25" x the layout_factor_table_1080 line 7 = 25 x 1 = 25

    And the others layout_factor_table_xxxx

    layout_factor_table_720.txt
    0.6667 ---- Line 6
    0.6667 ---- Line 7

    layout_factor_table_480.txt
    0.4444 ---- Line 6
    0.3333 ---- Line 7


    layout_factor_table_272.txt
    0.4444 ---- Line 6
    0.4444 ---- Line 7


    I realized that i could leave both of them as 0x00000500, since the line 6 and 7 shares the same value except for the 480 table

    but i didn't realize any difference in their aspect ratio on 480p as they have different values

    They fit perfectly in every resolution now
     
    Last edited: Jul 29, 2019
    jeka26 likes this.

Share This Page