Closed Yaniko closed 7 years ago
Sorry for the late reply, that report somehow got swept away by other things ...
Hm, no, looking at the original code, it's doing what I was intending: this method sets up the vertices for the given texture, so the rectangle should not be as wide as the frame, but just as wide (and high) as the cropped texture. (The frame's coordinate system has its root at the top left of the cropped texture, with x and y pointing to the "big" version [and are thus negative].)
Could you maybe post some sample code that reproduces the problem? I.e. some code which produces output that's surprising or wrong?
Thanks in advance!!
Ok, I'll make an example on 10 May.
Thanks, I appreciate it!
I've made an example project. It contains two rectangles. One normal and one invisible. And it works fine. Both rectangles are the same size. Example project is very simplified. It uses starling only. We use GAF in "main" project. Must be something with it. Case needs further investigation. My chief says we don't have time on that. I'm sorry.
Hm, yes, the problem could also be in an additional library. That makes it harder to track it down. I'll close this issue for now — but feel free to post more information or open it up again if there's a chance to get to the root of it.
Hi. In our project we use rectangles as placeholders (in fla files). We set alpha 0 to their fill. After converting to textures such a rectangle becomes a 3x3 with frame 1x1. All was good in starling 1.6. Recentlty we migrated to starling 2. All placeholders become 3 times wider and higher. I think there is a bug in Texture.as in setupVertexPositions().
Looks like it should be (line 609)
Also I'm not sure about
-frame.x, -frame.y
. In our caseframe.x == 0
so it works. Maybe here is a good place to use texture'spublic function get frameWidth
?