-
-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Take scale into account #1906
Conversation
@kurtome @ufrshubham could you review this PR too? :) |
LGTM, although can you double check that |
Sure thing. Probably needs a test as well. |
9557029
to
a827fc7
Compare
So it doesn't look like it uses the destination tile size into account.. and I'm not sure it should. Yes, destination tile scale might seem like a cheap "scale" or "zoom", but it could just be sizing different maps to be the same for mixing. I don't know what the original intent was behind having it passed in versus reading it from the map.... and now that Tiled Component is positionable - it's also scalable. That mixed with my unfamiliarity with parallax and I'm not sure. |
My hunch is that it will work fine as is because parallax is really a function of solely the current Viewport/Camera relative to the 0,0 position of the map. And |
This is correct. Tile size won't matter for parallax. I'll try to play around with the changes just to be sure. But if I don't post anything within the next few days, consider a LGTM from my side. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some structural comments. Overall the changes look solid!
late double offsetX = layer.offsetX * scaleX + (parent?.offsetX ?? 0); | ||
|
||
double get opacity { | ||
if (parent != null) { | ||
return parent!.opacity * layer.opacity; | ||
} else { | ||
return layer.opacity; | ||
} | ||
} | ||
late double offsetY = layer.offsetY * scaleY + (parent?.offsetY ?? 0); | ||
|
||
double get parallaxX { | ||
if (parent != null) { | ||
return parent!.parallaxX * layer.parallaxX; | ||
} else { | ||
return layer.parallaxX; | ||
} | ||
} | ||
late double opacity = layer.opacity * (parent?.opacity ?? 1); | ||
|
||
double get parallaxY { | ||
if (parent != null) { | ||
return parent!.parallaxY * layer.parallaxY; | ||
} else { | ||
return layer.parallaxY; | ||
} | ||
} | ||
late double parallaxX = layer.parallaxX * (parent?.parallaxX ?? 1); | ||
|
||
late double parallaxY = layer.parallaxY * (parent?.parallaxY ?? 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any specific reason to not have these as getters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which ones? Offset, Opacity, or Parallax?
Main reason: performance. As getters, you're calculating this every single render loop. As late-calculations, they are calculated once and cached.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per our discussion on discord, this is few as these values never change.
final Vector2 destTileSize; | ||
final TiledMap map; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to not have these in here? It look like it is unnecessarily increasing all the derived classes as well. For example, _UnrenderableLayer
is not even using them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think it's possible. Let work on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually; they are needed for the scale and offset calculations. Tile, Image, and Group uses these. _UnrenderableLayer
is just unlucky. RenderableTiledMap
is allocated after the layers are created... maybe we just update the layers to point to RenderableTiledMap
as the parent map?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got idea. Also, unrenderable layer is basically the object layer and technically it can contain renderable tile objects. So this change is actually useful for adding rendering support for the object layer in future.
void handleResize(Vector2 canvasSize); | ||
|
||
void refreshCache() {} | ||
void refreshCache(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe better to leave these with a default implementation. Will avoid some empty overrides in derived classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_RenderableLayer
is abstract. Having these as default implementations actual lead to the bug that this is fixing.
- Take scale into account when calculating offsets - Memoize the work of offsets - don't calculate it each time. - Tests - everyone loves tests. Fixes flame-engine#1904
a827fc7
to
6f53e78
Compare
These changes LGTM 🔥 |
Description
In scaled destination tile size, this would render the pyramids in different locations:
Example pre-fix wrongness:
Checklist
fix:
,feat:
,docs:
etc).docs
and added dartdoc comments with///
.examples
.Breaking Change
Related Issues
Fixes #1904