-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Merged by Bors] - fix cluster tiling calculations #4148
Conversation
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.
I think we should probably be using debug_assert
for situations that could happen due to programming errors within bevy that would cause runtime problems, but that if we wrote our code properly, should never happen. And then use assert
for things that could happen at runtime in release builds due to a user error, though proper error handling would be nicer than panicking... so I'm trying to think of a situation where assert should really be used... I realise I've used assert
elsewhere in this code but the thought came up now. @cart @mockersf do you have any opinion / clear thoughts and guidelines on this?
Co-authored-by: Robert Swain <robert.swain@gmail.com>
The rule of thumb I've been using:
|
This particular case doesn't feel like a debug_assert. This is a user-facing type that has constraints on the values it supports. These constraints should either be enforced here (panic if unrecoverable, or warn + auto-constrain to avoid crashing) or they should be enforced via a constructor. I'm inclined to auto-constrain and warn here. |
bors r+ |
# Objective fix cluster tilesize and tilecount calculations. Fixes #4127 & #3596 ## Solution - calculate tilesize as smallest integers such that dimensions.xy() tiles will cover the screen - calculate final dimensions as smallest integers such that final dimensions * tilesize will cover the screen there is more cleanup that could be done in these functions. a future PR will likely remove the tilesize completely, so this is just a minimal change set to fix the current bug at small screen sizes Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective fix cluster tilesize and tilecount calculations. Fixes bevyengine#4127 & bevyengine#3596 ## Solution - calculate tilesize as smallest integers such that dimensions.xy() tiles will cover the screen - calculate final dimensions as smallest integers such that final dimensions * tilesize will cover the screen there is more cleanup that could be done in these functions. a future PR will likely remove the tilesize completely, so this is just a minimal change set to fix the current bug at small screen sizes Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective fix cluster tilesize and tilecount calculations. Fixes bevyengine#4127 & bevyengine#3596 ## Solution - calculate tilesize as smallest integers such that dimensions.xy() tiles will cover the screen - calculate final dimensions as smallest integers such that final dimensions * tilesize will cover the screen there is more cleanup that could be done in these functions. a future PR will likely remove the tilesize completely, so this is just a minimal change set to fix the current bug at small screen sizes Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Objective
fix cluster tilesize and tilecount calculations.
Fixes #4127 & #3596
Solution
there is more cleanup that could be done in these functions. a future PR will likely remove the tilesize completely, so this is just a minimal change set to fix the current bug at small screen sizes