Open Aravind-Sundararajan opened 3 years ago
Interesting! Sorry for the late reply! If I had to guess, it might be something to do with the texture pages for html5 vs windows. Thanks for letting me know! I will try to get back to working on Fauxton soon. Been taking a little break from it to try and focus on personal projects.
I believe that HTML5 might have issues using the information provided by 'sprite_get_uvs'.
When running the debug log it shows all of the information correctly for the return array
[0] = left [1] = top [2] = right [3] = bottom [4] = amount of pixels the asset compiler has trimmed from the sprites left side [5] = amount of pixels the asset compiler has trimmed from the sprites top side [6] = normalised percentage of pixel data from the original sprites width that has been saved to the texture page [7] = normalised percentage of pixel data from the original sprites height that has been saved to the texture page
but maybe it isn't using them correctly? I remember vaguely running into this issue when developing the html5 build, but I'm not exactly sure what can fix it, as even using separate texture pages don't seem to fix it....hmm...
Interesting, I'll play around with it :)
Lmk if you figure it out. I'm not exactly sure what causes it. I found another issue as well with scaling models and rotating them. I might have to do some matrix multiplying for non-static models as well. If you do something like xscale=2 yscale = 1 and set the rotation to anything other than 90-degrees it skews the models for some reason.
I haven't looked to deeply into this, but it appears that sprite-stacked models on the html5 release must be square (64,64,64) (32,32,32) etc or else you get scaling issues, but this problem doesn't happen on the windows release. This can be an issue if have particularly large strip images ( potentially >150px on dimensions) and are trying to reduce the size