jonathanrpace
commented
10 years ago Hi Jarrod - looks like you've delved into the scary world of UV's and fills :)
I won't have chance to check this out in any detail anytime soon. But after reading your point about centering the UV's for ellipse fills, I thought it might be worth clarifying that the extension aims to mimic Flash's texturespace.
The 1/width, 1/height keeps the matrix translations in pixel coordinates by taking into account the texture's dimensions.
I'm afraid centering the ellipses UV's will break the desired 1:1 mapping between the api's.
It's worth noting that the primitives that the API uses (such as NGon) don't care about this (by default they build their geometry in a way that makes sense for GPUs) - it's the API that contorts the UV trasformations into pixelspace.
jarrodmoldrich
IonSwitz
Hi Jonathan (and anyone else watching),
I was refactoring the stroke code to be more streamline, and in doing so ripping out those strange and superfluous 'degenerates' I added in a long while back. Apparently the stroke generation for ellipse etc. were leaving the _fillStyleSet flag set on while using moveTo/lineTo to generate the outline, thus creating a fill over the top of the fill generated from the NGon created previously.
When I fixed that, I noticed the NGon was filled with one colour. I quickly noticed that the UVs were very very large. Following the code:
1) beginTextureFill takes a user supplied uv matrix and scales it by (1/width, 1/height) 2) drawEllipse then creates a uv matrix scaled to (width, height) * fillMatrix from 1) and applys it to the NGon 3) the buildSimpleNGon function would create UVs that were the same as their relative positions (an NGon of radius 50 would have UVs in the range of -50 to 50) 4) applyUVMatrix is called straight after which applies the uv matrix from 2), which, if lucky, has been cancelled out to be identity
It took me a while to figure it all out. It seems a number of separate changes that you have been involved with over a long period of time that have conspired to create confusion about where exactly the UVs are supposed to be manipulated.
I have made a branch where the ellipse fill has UV is centred and scaled to the ellipse. Scaling works from the centre, so passing a UV matrix scaled to 2.0 means the texture should remain centred within the ellipse and the texture only half visible within the ellipse. Due to the inexplicable scaling in 1), which I have kept, translation happens in terms of texture pixels. So a translate of (32,0) on a 64 by 64 texture means that it's shifted half to the right.
Please have a look at fix_uvs_patch on the upstream repository and tell me what you think. If everything seems fine to you, I'll merge it with master.
Cheers!