Treellama wrote:Heh, I would expect a 4x resolution version of an image to display at the same size as the original if image_scale is 1.0.
I think I see where you're coming from now. The current version of image_scale (assuming the POT fix) re-uses nothing from the original shape but the top left corner; it's very oriented around using knowledge from the replacement image, but not knowing or caring a lot about the original bounds -- image_scale is relative to the replacement image, not the shape. Your approach, as I understand it, modifies the original shape's bounding box, and then fits the replacement into it. That does match the default case, where the original bounding box is not modified, and the replacement is fitted into it. Let's see where this leads.
A.E.M's 400% canvas replacements, then, would use a shape_scale of 4.0; the original shape's bounding box would be increased accordingly, and would contain the extra padding built into the replacement. The increased canvas and increased scale cancel each other out, so nothing appears changed. (Offsets may be necessary, depending on the anchor point we choose, but that's a separate discussion.)
To load an M1 compiler (exported from the M1A1 shapes file) in place of an M2 compiler, you'd need something to change the aspect ratio. For argument's sake, let's say the aspect_ratio attribute keeps the height constant, and resets the bounding box width to be height * aspect_ratio. I considered x_scale and y_scale instead of shape_scale and aspect_ratio, but that seems no less confusing.
The M2 compiler is 86x184; an M1A1 compiler is 63x172. You'd need an aspect_ratio of 63/172 = .3663, to match the M1A1 image. To account for the difference in height, you'd need a shape_scale of 172/184 = .9348. If the M1 compiler were stretched into a 256x256 image, or blown up to a high-res version, the same values would work, as the attributes are only changing the bounding box and don't care about the replacement's pixel dimensions at all.
For the same M1 compiler padded into a 256x256 texture instead, the aspect would be 1.0 to match the replacement's dimensions, and the shape_scale would be 256/184 = 1.3913. Because the actual compiler image only takes up 172/256 of the space, overall each pixel would take up the same space on screen as the previous example. The extra space in the shape would be blank, and it has nothing to do with the actual physics model, so it wouldn't be noticeable.
In both of the examples above, the aspect_ratio is the same as the replacement image's aspect ratio. This allows us to accept aspect-distorted images, at the expense of having to calculate the replacement dimensions and code them into the MML. To streamline that, we could reduce the float to a boolean "use replacement aspect ratio", or accept a special value like -1 to have the engine calculate and apply the replacement's native aspect ratio.