setClip()

antix · July 2020

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).

MoKaLux · July 2020

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

antix · July 2020

silly

hgy29 · July 2020

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 ?

antix · July 2020

AnchorPoint does however affect it. I will just adjust all of my code to not handle Sprites by their middle point

hgy29 · July 2020

Or maybe you can just use two nested sprites ?

rrraptor · July 2020

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

antix · July 2020

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

keszegh · July 2020

@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.

hgy29 · July 2020

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.

keszegh · July 2020

@hgy29 maybe setAnchorPosition does not effect, but setAnchorPoint does? i did not check.

keszegh · July 2020

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.

hgy29 · July 2020

@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()

antix · July 2020

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.

keszegh · July 2020

@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)

keszegh · July 2020

i agree that it's strange that they behave differently, in any case, whichever is the one the community prefers.

hgy29 · July 2020

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

hgy29 · July 2020

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 ?

keszegh · July 2020

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?

keszegh · July 2020

"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.

hgy29 · July 2020

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.

keszegh · July 2020

in general to me it seems Pixel can do the same and more than Bitmap so Bitmap is kind of obsolete.

antix · July 2020

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)

keszegh · July 2020

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.

antix · July 2020

@keszegh well if BitMap is faster then I'll use that. When making things like bullet hell shooters.. you need the most bullets possible

SinisterSoft · July 2020

If you are making a load of bullets, then use the particles object, you can have thousands of them.

antix · July 2020

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.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

setClip()

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

setClip()

Comments