Ares Ex Machina wrote:how did you get -570 and -770 for your mml offsetting?
<texture coll="1" bitmap="3" normal_image="Weapons/Magnum/magnum_03.png" opac_type="1" type="3" image_scale="5.00" x_offset="-250" y_offset="-250"/>
Hopper wrote:I was curious about this, so I took a look. The stretching is related to the fact that your replacement textures are loaded into a square OpenGL texture with powers-of-two sides: the image_scale attribute doesn't play nice with the code to deal with translating between the actual texture size and your replacement image's size.
Hopper wrote:I didn't; as far as I can tell, the attachment above has -250 and -250 in the mml...
Treellama wrote:Should we fix this?
I'm considering adding an aspect_ratio attribute so the XBLA replacements can work without a shapes file. I think they're already POT though.
Ares Ex Machina wrote:For my new magnum image, what I did was measure the distance from the left side of my image to the left side of my canvas: 93 pixels.
Then I measured the distance from the top of my image to the top of my canvas: 67 pixels.
Multiplied by 5, this gave me an X offset of -465 and a Y offset of -335, so that's what I plugged into the mml. But my weapon is off center in-game, so where did I go wrong?
Hopper wrote:After seeing what the engine is doing, I'm not sure you need a new attribute to work with a stock Shapes file.
Treellama wrote:I was never able to adjust the aspect ratio on replacement images. It looks like offset_x has a chance of doing that? Not very intuitive...
Hopper wrote:Not offset_x, but image_scale. When image_scale is unspecified (or <= 0), then your replacement is locked exactly to the bounds of the original image. When image_scale is a positive number, it shows your image as square pixels, using image_scale as it would the Shapes file's scale factor. Offset_x and offset_y can then be used to recenter that image.
The upshot is, if you use image_scale, the engine will use the aspect ratio of the replacement, not the aspect ratio of the original frame.
Treellama wrote:That's even less intuitive! And not documented!
And it doesn't help you correct the aspect ratio of shapes resized to fit POT textures.
Hopper wrote:To me, if image_scale were actually multiplied by the Shapes file's scale factor, it'd be a lot more intuitive. With that change, if you exported an original shape and loaded it as a replacement with an image_scale of 1, it'd look exactly the same, instead of needing an image_scale of 5. If you created a high-res version at 4x the size and used an image_scale of 0.25, it'd fit perfectly. If you used a replacement with 4x the pixels and an image_scale of 1, the monster/weapon would look 4 times bigger. If the replacement was wider, it'd be shown undistorted, with the extra pixels extending past the right of the original shape's boundary. (Centering the replacement might make more sense than anchoring the top left, although I gather some XBLA shapes have the data in the top left of a large square canvas.)
If image_scale defaulted to 1.0, then my expectation could still be met. I'm not saying it should.One problem with that scheme is that it doesn't really mesh well with the default, no-image_scale-specified case, where the shape is the same apparent size regardless of the number of pixels in the replacement.
Are the XBLA textures distorted in their raw form?
Unless there's compelling existing content like that, I don't see why adjusting the aspect ratio of replacements in-engine is more important than, say, rotating or flipping them (features previously requested that we decided against adding).
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.
Treellama wrote:Maybe it would be more intuitive to separate the two: specify the new width and height of the bounding box, and use actual_width and actual_height to compensate for any padding already present in the replacement texture. Would there be any need for image_scale then?
Hopper wrote:Actual_width and actual_height do make the padding cases much easier. I didn't mention them because -- wait for it -- they're not documented! I had no idea they were there.
I do like the idea of directly specifying the bounding box in pixels, with the defaults being the dimensions of the Shapes bitmap. Without fractional math, it's a lot easier to grasp. You're correct, we don't need image_scale any more. We do still need x and y offsets, so we can keep the x_offset and y_offset names, or rename them to go with our width and height. Maybe sprite_left, sprite_top, sprite_width, and sprite_height?
Treellama wrote:Do we still need to do key point alignment in the shapes? So, maybe offset_x and offset_y could be the offsets from that key point, and you'd calculate right/bottom using sprite_width and sprite_height. (how about shape_width and shape_height?)
Seems like no NPOT fix would be necessary, since the engine accounts for the padding it does with UScale and VScale, and the MML user can account for same with actual_width and actual_height? Just get the bounding box right, and even aspect ratio doesn't matter.
Ares Ex Machina wrote:Everything is working great now.
Ares Ex Machina wrote:Now nothing is working as it should. Understandable, since you guys have changed a few things around since beta 2. My frames are now too small and stretched. Is this how image replacement is going to work for 1.0? If so, what do I need to change in order to get my replacements looking the way they did in beta 2?
Treellama wrote:Follow Hopper's last post in this thread. That's the implementation that went in! It should be in MML.html too I hope.
Users browsing this forum: No registered users