Skip to content

Conversation

Cheemsandfriends
Copy link
Contributor

I've been using setGraphicSize as a way to scale up/down images. While this gets the job done, of course, it's a bit tedious and setting the scale via sprite.scale.scale(0.5) isn't as convenient since it scales it in an absolute level, not in a relative-like width, up and down.

This fixes it, plus it doesn't affect it that much since it's mostly an extern inline to the already established setGraphicSize.

@Geokureli
Copy link
Member

Geokureli commented Sep 19, 2025

This is a very obfuscated way of doing this. The doc doesn't really clarify things for me but it looks like sprite.scaleGraphicSize(sX, sY, true) is the same as sprite.scale.set(sX, sY), and an absolute arg of false assumes the hitbox matches the graphic's size, which seems very unhelpful and unclear (especially considering setGraphicSize doesn't update the hitbox) and doesn't fit the method name scaleGraphicSize.

I say remove this new method, and add myPoint.setXY(n) allowing:

  • sprite.scale.setXY(n) instead of sprite.scaleGraphicSize(n, true)
  • sprite.scale.set(x, y) instead of sprite.scaleGraphicSize(x, y, true)
  • sprite.scale.scale(n) instead of sprite.scaleGraphicSize(n, false)
  • sprite.scale.scale(x, y) instead of sprite.scaleGraphicSize(x, y, false)

While we're at it, point.set(x) should be deprecated. Many people expect it to set both values, rather than set y to 0, eventually we should remove that option and then re-add it so that it behaves like setXY

So I went and did that: #3490

Edit: if you think there is some value in a method that scales a sprite relative to its current hitbox, then I'm open to adding that, but I would not call it scaleGraphicSize or scaleGraphicSizeRelative, to me those names are misleading, or unintuitive, and it should probably scale the hitbox, as well, right?

@Geokureli Geokureli closed this Sep 19, 2025
@Cheemsandfriends
Copy link
Contributor Author

sprite.scaleGraphicSize(sX, sY, true) is the same as sprite.scale.set(sX, sY)

Essentially, yes. I did it with the frame dimensions simply to fit in with setGraphicSize

and an absolute arg of false assumes the hitbox matches the graphic's size which seems very unhelpful and unclear

I don't see how this is confusing or problematic.
The documentation already tells you that it is falling back to setGraphicSize, and by default, both fields act different:

  1. frameWidth: it being from the actual image. so it doesn't matter how many times you scale and update the hitbox, it still scales up properly.
  2. width: it being the processed hitbox and yara yara. plus, when you load spritesheet, it's the first frame to be loaded, so with a clean FlxSprite, it's the general hitbox that affects the whole spritesheet.

both are used for different purposes, like for example, scale down sprites from the same spritesheet. from 1080p to 720p, for example.

or scaling images down that the developer intentionally trimmed the hitbox a bit so that it has more or less the same scaling down at any frame.

the idea with scaleGraphicSize is to scale general spritesheets to a certain level, which the point PR that you added (although I think set should be an overloaded extern inline instead of its own function) is not the intended behavior.

things like sprite.scale.scale would not work because it is scaleGraphicSize(x, y, true) and only the first time, then it all breaks up, unless you use set, which is more appropiate to it.

I would not call it scaleGraphicSize or scaleGraphicSizeRelative, to me those names are misleading, or unintuitive, and it should probably scale the hitbox, as well, right?

it follows up the same name principle as setGraphicSize. I don't think anyone's thinking it would update the hitbox, honestly. by that logic, we would need to change setGraphicSize because it doesn't update the hitbox lol.

@Geokureli
Copy link
Member

Geokureli commented Sep 20, 2025

sprite.scaleGraphicSize(sX, sY, true) is the same as sprite.scale.set(sX, sY)

Essentially, yes. I did it with the frame dimensions simply to fit in with setGraphicSize

and an absolute arg of false assumes the hitbox matches the graphic's size which seems very unhelpful and unclear

I don't see how this is confusing or problematic. The documentation already tells you that it is falling back to setGraphicSize, and by default, both fields act different:

  1. frameWidth: it being from the actual image. so it doesn't matter how many times you scale and update the hitbox, it still scales up properly.
  2. width: it being the processed hitbox and yara yara. plus, when you load spritesheet, it's the first frame to be loaded, so with a clean FlxSprite, it's the general hitbox that affects the whole spritesheet.

I think if this already existed in this form, with this name and documentation and you stumbled across it, you yourself would find this confusing. it takes scale and determines a size, and passes it into a function that takes the size and determines the scale, rather than just changing the scale directly. Using the term "absolute" here is confusing as well, false is really "relative to the frame size" and true is "relative to the current hitbox". The term "absolute" should indicate "relative to the current scale" or "sets the absolute scale"

both are used for different purposes, like for example, scale down sprites from the same spritesheet. from 1080p to 720p, for example.

or scaling images down that the developer intentionally trimmed the hitbox a bit so that it has more or less the same scaling down at any frame.

I would also just have two different functions for this rather than a bool, plus this further conflates hitbox vs graphic size which is a problem with a lot of FlxSprite tools. While I'm listing gripes, I also think setGraphicSize allowing two zeroes is dumb and should change

the idea with scaleGraphicSize is to scale general spritesheets to a certain level, which the point PR that you added (although I think set should be an overloaded extern inline instead of its own function) is not the intended behavior.

things like sprite.scale.scale would not work because it is scaleGraphicSize(x, y, true) and only the first time, then it all breaks up, unless you use set, which is more appropiate to it.

I would not call it scaleGraphicSize or scaleGraphicSizeRelative, to me those names are misleading, or unintuitive, and it should probably scale the hitbox, as well, right?

it follows up the same name principle as setGraphicSize. I don't think anyone's thinking it would update the hitbox, honestly. by that logic, we would need to change setGraphicSize because it doesn't update the hitbox lol.

setGraphicSize sets the sprite's graphic size, there's no mention of hitbox, scaleGraphicSize uses the current hitbox as a base to scale the graphic. I don't see why this should involve the hitbox, call it scaleRelativeToCurrentHitbox or something

If you disagree, ask someone to weigh in. If you think this offers something that my PR doesn't, share a snippet that showcases that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants