-
Notifications
You must be signed in to change notification settings - Fork 45
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
camera: fix unchecked NO_HEIGHT usage #2569
camera: fix unchecked NO_HEIGHT usage #2569
Conversation
Download the built assets for this pull request: |
This resolves an OG bug whereby the camera shift could result in extremely large values when NO_HEIGHT is involved, hence resulting in the camera going out of bounds for a frame or so. We now check for this case and use the previous valid Y position of the camera. Resolves LostArtefacts#1034.
This neatens the bounce control in the TR1 camera, similar to TR2.
a808392
to
2b9c72a
Compare
Slight logic re-organisation, so we're testing for no height first to still allow a LOS check. This gives a slightly smoother shift in some cases e.g. in the save below if you jump straight up |
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 can confirm the scenarios from the issue are fixed. Also City of Khamoon and Wreck of the Maria Doria, room 52 both LGTM.
It's fantastic to see this bugfix introduced to TRX. Thank you again. 👍
I can't load the save for some reason due to the item count.
|
I ran into the same issue, I figured I needed to enable the |
Ah, sorry, I forget the mummy can cause this issue. Thanks. |
Resolves #1034.
Checklist
Description
This resolves instances where the camera Y shift could result in extremely large values when
NO_HEIGHT
is involved, hence resulting in the camera going out of bounds for a frame or so. We now check for this case and use the previous valid Y position of the camera. @aredfan has provided saves in the issue where there are prominent cases of this.This doesn't fix all instances where the camera can go into walls/OOB - the other related issue is with the interpolated values, which we'll tackle separately. This PR addresses only those instances where the camera is thrown up to -32768.