Looks great, i can't wait to test it out, but unfortunately i'm on vacation far from home =(
Advise me when you do, i think we can make it better
In my last 4 or 5 posts in this thread i was chilling a bit, some of the things i said was from memory and just by looking at the screenshots devil303 and you was posting
But the next day i was taking a look at the xmb_plugin_normal.xml generated by rcomage and i could see better his sizes, im going to paste here the xml code reorganized, this code is valid btw (rcomage will acept it fine in this format), the only thing im doing is to replace some spaces in between attributes by a new line and tabs
Code:
<Plane name="indi_base"
positionX="0" positionY="-74" positionZ="0"
colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1"
sizeX="560" sizeY="82" sizeZ="0"
sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1"
anchorMode="0x1200"
onInit="nothing"
positionOverrideX="0xc000000" positionOverrideY="0xd000500" positionOverrideZ="0x0"
sizeOverrideX="0x700" sizeOverrideY="0x700" sizeOverrideZ="0x0"
planeImage="image:tex_indi_bg"
planeResizeMode="0x3">
</Plane>
The "anchorMode" could confuse us a bit, his purpose is to connect the position of some objects with others (his parents or childrens), i dont know how that values works. All i nkow is if we scale an object, his anchor point is going to move a bit, so all the objects connected with that anchor point could move together with it
Maybe this movements caused by the values used in the "anchorMode" attributes are involved in the visual effect that increases the size of the "tex_indi_bg"" icon, im not sure
My surprise was to see that is using sizeX="560" sizeY="82" as default... this is close to what devil303 said, and also what i could meassure in other screenshot i had... but is not the 600x60 we calculated (incorrectly)
The other attributes that could affect the size are the sizeOverrideX="0x700" sizeOverrideY="0x700"
That values belongs to the "factor"
XMB layout tables (because are the last 2 bytes of it)
In other words... that values are used as a multiplyer in a tricky math formula that includes all this attributes:
sizeX, sizeY, sizeZ, sizeScaleX, sizeScaleY, sizeScaleZ, sizeOverrideX, sizeOverrideY, sizeOverrideZ
Or better said... is the same math formula applyed 3 times, for X, Y, Z
The 3 formulas is a bit like this (sorry i cant explain it right now and i dont remember it)
Absolute X size = (Ax*Bx) + (Cx*Dx)
Absolute Y size = (Ay*By) + (Cy*Dy)
Absolute Z size = (Az*Bz) + (Cz*Dz)
What happens here is the values sizeOverrideX="0x700" sizeOverrideY="0x700" are loading line number 8 from "layout_factor_table_1080p"... and that value is 1.000
For other screen resolutions that value is smaller... but in 1080p is not doing anything, because you know... is we multiply a value * 1 results in the same value
In short... it looks for 1080p the only sizes that matters are sizeX="560" sizeY="82"
And the sprx probably is updating that values (or the overrides) in runtime to change the sizes of the image dinamically
So... instead of the 60x60 i used.... it seems it would fit better if i rebuild that icon at 82x82 pixels
You know... the goal of the experiment was to create the icon with a size that matches the "target" size to get the max quality posible
And btw, the sizes i been suggesting to use in this experiments (a perfect square of either 60x60 or 82x82) are because by now im only playing with the streching effect applyed to the height... but incase it works fine i think the same can be made with the width, this would give us full control of the image... it would be like removing the "streching" effects, so it doesnt needs to be a "bar" anymore, it could be whatever you imagine it to be (i have a couple of nice ideas)
