matteo sisti sette wrote:
I don't have a camera to plug in and double check, but I never noticed this inverted problem before. You can always re-invert the numbers if you need to ;-)
Yes of course it is stright-forward to correct the inversion. But I was wondering if there may be some weird platform-dependence in the involved objects that may cause the y coordinate to work in one sense or the other in different computers/os's?? Because it would be really really strange that it were just an error in the patch and you never noticed before - I mean the cursor moves down when the object moves up, and you mention having used it in workshops for years.
I was just curious if it may be some platform or version dependency.
the problem is, that some pix-sources (platform dependent!) supply the images with (0/0) in the upper-left corner, whereas others (0/0) is the lower-left corner (like openGL expects it). for performance reasons, Gem does not put the images "right" when it retrieves them, but tries to flip the image on the texture, once they are uploaded. this often makes things behave weird (e.g. mixing 2 images will make one of them upside-down, even though the look "normal" when viewed separately) so, sometimes the upside-downness is not respected by certain pix_objects (it seems like [pix_blob] is one of them), this is a bug and should be fixed.
finally, i am wondering how much the penalty would be to manually flip the images when retrieving them (this would involve one additional copy of the entire image, each time it is pulled from the source) - this will just magically fix a lot of weirdness...
masd.r IOhannes