Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
setClip() - Gideros Forum

setClip()

It appears that when you call setClip() on a Sprite, the clip coordinates are calculated from the Sprites AnchorPoint, not it's top left pixel. Is this by design?

It's kind of strange to have to make all sorts of silly offsets just to set clipping for a Sprite that is not being handled by its top left pixel (to me anyway).

Comments

  • MoKaLuxMoKaLux Member
    edited July 9
    antix said:

    It's kind of strange to have to make all sorts of silly unecessary offsets just to set clipping for a Sprite that is not being handled by its top left pixel (to me anyway).

    +1 ;)

    Likes: antix

    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
    +1 -1 (+1 / -0 ) Share on Facebook
  • antixantix Member
    silly :D

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • hgy29hgy29 Maintainer
    Clipping is computed in sprite shape space, that is untransformed. So anchor point shouldn’t affect it. In other words, the whole transform matrix (Local to global) of the sprite is applied to the clipping rectangle at render time.
    Doesn’t that sounds correct ?
  • antixantix Member
    edited July 9
    AnchorPoint does however affect it. I will just adjust all of my code to not handle Sprites by their middle point ;)
  • hgy29hgy29 Maintainer
    Or maybe you can just use two nested sprites ?
  • rrraptorrrraptor Member
    edited July 9
    antix said:

    It appears that when you call setClip() on a Sprite, the clip coordinates are calculated from the Sprites AnchorPoint, not it's top left pixel.

    Sound logical to me :smile:

  • antixantix Member
    Still doesn't sound logical to me sorry. If I'm handling a Sprite by it's midpoint then why the need to calculate the top left to set clip? Clip should always start from 0,0 in my opinion.

    as I said though I'll just use Sprites anchored at 0, 0 for ease of use :)
  • keszeghkeszegh Member
    edited July 9
    @antix, you can make a setClipAntix() function that works as you wish by using getAnchorPoint() to calculate clipping and using setClip() with appropriate values. the only issue is if later the anchor point is changed then the clipping will be incorrect, but i think generally people don't tend to change anchor point after the sprite is set up, so hopefully it won't be an issue for you. or you can even make a setAnchorPointAntix() which updates the clipping if necessary.
  • hgy29hgy29 Maintainer
    I used this test code:
    local circle=Particles.new()
    circle:addParticles{{ x=100,y=100, size=200,color=0xFF0000}}
    circle:setClip(100,100,100,100) --Bottom right quarter
    stage:addChild(circle)
     
    circle:setAnchorPosition(50,50)
    And fail to understand the issue: adding or removing the setAnchorPoint line doesn't affect the clip, as expected: the bottom-right quarter of my circle is still correctly shown and nothing else.
  • keszeghkeszegh Member
    @hgy29 maybe setAnchorPosition does not effect, but setAnchorPoint does? i did not check.

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • keszeghkeszegh Member
    actually i would find computing clipping relative to the anchor more logical, as otherwise if i add/remove children to the sprite then (if clipping includes the children in computing the boundary of the sprite) then the clipping would change which is not how i'd prefer.
  • hgy29hgy29 Maintainer
    @keszegh, Good point to check.
    Also Bitmap behaves differently when setAnchorPoint is used (legacy specific behavior), so it may well not work as expected with setClip()
  • antixantix Member
    This code...
      local r = pack:getTextureRegion('block4.png')
      local b = Bitmap.new(r)
      b:setPosition(MIDX, MIDY)
      stage:addChild(b)
     
      b = Bitmap.new(r)
      b:setPosition(MIDX, MIDY)
      b:setColorTransform(0.5, 0, 0)
      b:setClip(32,32,32,32)
      stage:addChild(b)
     
      b = Bitmap.new(r)
      b:setAnchorPoint(0.5, 0.5)
      b:setPosition(160, 400)
      stage:addChild(b)
     
      b = Bitmap.new(r)
      b:setAnchorPoint(0.5, 0.5)
      b:setPosition(160, 400)
      b:setColorTransform(0, 0.5, 0)
      b:setClip(16,16,32,32)
      stage:addChild(b)
    Produces the following output...

    You can see by just changing the AnchorPosition, it doesn't work as I expected. But that's all good because as I already said.. I'll just not use AnchorPositions.
    image.png
    656 x 1019 - 24K
  • keszeghkeszegh Member
    edited July 9 Accepted Answer
    @antix, so as it seems, setAnchorPoint() works as you don't want but setAnchorPosition() works as you want, so just use the latter.

    e.g., try to comment/uncomment the relevant lines to see the difference (i used a 120x120 bitmap):
      local r = Texture.new('bitmap.png')
      local b = Bitmap.new(r)
      b:setPosition(60, 160)
      stage:addChild(b)
     
      b = Bitmap.new(r)
      b:setPosition(60, 160)
      b:setColorTransform(0.5, 0, 0)
      b:setClip(16,16,32,32)
      stage:addChild(b)
     
      b = Bitmap.new(r)
      b:setAnchorPosition(60, 60)
      --b:setAnchorPoint(0.5, 0.5)
      b:setPosition(260, 160)
      stage:addChild(b)
     
      b = Bitmap.new(r)
      b:setPosition(260, 160)
      b:setAnchorPosition(60, 60)
      --b:setAnchorPoint(0.5, 0.5)
      b:setColorTransform(0, 0.5, 0)
      b:setClip(16,16,32,32)
      stage:addChild(b)

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • keszeghkeszegh Member
    i agree that it's strange that they behave differently, in any case, whichever is the one the community prefers.
  • hgy29hgy29 Maintainer
    Yes, I see that you are using Bitmap, which implement setAnchorPoint differently. Actually setAnchorPoint used to be available only for Bitmap, so it is not really that Bitmap is doing it wrong, but more that it is doing it in a way not compatible with setClip and not equivalent to the generic anchoring system which was implemented later. The big question is, would changing Bitmap anchoring system break
  • hgy29hgy29 Maintainer
    Yes, I see that you are using Bitmap, which implement setAnchorPoint differently. Actually setAnchorPoint used to be available only for Bitmap, so it is not really that Bitmap is doing it wrong, but more that it is doing it in a way not compatible with setClip and not equivalent to the generic anchoring system which was implemented later. The big question is, would changing Bitmap anchoring system break current gideros apps ?
  • keszeghkeszegh Member
    hard question, ruining an old project's behaviour is not very cool.
    perhaps in setClip there could be a last optional variable which if set to true, then disregards the anchorpoint?
  • keszeghkeszegh Member
    edited July 9
    "Actually setAnchorPoint used to be available only for Bitmap" - at least anchorPoint is still only for Bitmap so this issue is only relevant for them and not for sprites in general.

    EDIT: it seems Sprite also has a setAnchorPoint function, although it is not documented.

    Because of this, for @antix there is an even easier workaround, just use Pixel.new(r) instead of Bitmap.new(r) and then setAnchorPoint also works as you want.
  • hgy29hgy29 Maintainer
    setClip disregard the anchor point, but when you set the anchor point on bitmap specifically, bitmap changes its vertices offsets: 0,0 is no longer the origin. So this is not a setClip issue, but a Bitmap:setAnchorPoint one.
  • keszeghkeszegh Member
    edited July 9
    in general to me it seems Pixel can do the same and more than Bitmap so Bitmap is kind of obsolete.
  • antixantix Member
    I liked the idea of a flag to choose for Bitmap if it will ignore the AnchorPoint :)

    With regards to Pixels and BitMaps.. I thought on a pure performance level that BitMaps were faster than Pixels overall. This is why I use them.. unless I'm mistaken (as is usually the case) ;)
  • keszeghkeszegh Member
    edited July 9
    Bitmaps may be slightly faster according to http://forum.giderosmobile.com/discussion/7427/pixel-vs-bitmap but probably this shall not ruin your app's performance if you do not have too many bitmaps. but that's only my guess. Also, only texture change was measured so if you use the same texture then performance gap may be even less.
  • antixantix Member
    @keszegh well if BitMap is faster then I'll use that. When making things like bullet hell shooters.. you need the most bullets possible ;)

    Likes: keszegh

    +1 -1 (+1 / -0 ) Share on Facebook
  • SinisterSoftSinisterSoft Maintainer
    If you are making a load of bullets, then use the particles object, you can have thousands of them.

    Likes: hgy29

    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
    +1 -1 (+1 / -0 ) Share on Facebook
  • antixantix Member
    I thought particles had to be like the same graphic or something. I was also under the impression that they weren't able to be animated.
Sign In or Register to comment.