Open quiret opened 4 years ago
Maybe we could add an extra argument realtime=false
to getCameraMatrix
that, when set to true
, will return the CCam results rather than 'target values'
Well, the getCameraMatrix function is not mentioned in this issue, but it could suffer from the same problem, as demonstrated by #1282. Do you have a plan how to return this 'realtime' matrix? Also I think introducing this realtime parameter would just overcomplicate things for the scripter. Like what justification does non-realtime have if it is just worse then realtime.
Like what justification does non-realtime have if it is just worse then realtime.
getCameraTargetLookAt/TargetPosition does not exist — this is what getCameraMatrix is supposed to provide (or currently provides)
changing fov return value is OK because we can get the 'target' fov using get/setCameraFieldOfView
getCameraMatrix function is not mentioned in this issue
Ah, now I see, your example uses getElementMatrix(getCamera())
. I suppose we can update the camera object matrix getter to get the realtime version.
The question now is whether it makes sense for getElementMatrix(getCamera())
to return different underlying data as getCameraMatrix
.
The question now is whether it makes sense for getElementMatrix(getCamera()) to return different underlying data as getCameraMatrix.
The programming API of getCamera in combination with getElementMatrix is much newer than the getCameraMatrix function. The camera is defined as matrix inside of the game engine. Thus it makes sense to look at getCameraMatrix as subset of getElementMatrix, a sort of helper function, a wrapper using getElementMatrix. So I speak in favor of changing the way getElementMatrix works but keeping the look-at behaviour of getCameraMatrix the same for backwards compatibility.
I am getting a hunch that this weird function is the cause of the issue. Why do we query fields from CCamSA instead of CCameraSA directly?
So I speak in favor of changing the way getElementMatrix works but keeping the look-at behaviour of getCameraMatrix the same for backwards compatibility.
To confirm, by "look-at" behaviour do you also mean "target current position" behaviour?
I am getting a hunch that this weird function is the cause of the issue. Why do we query fields from CCamSA instead of CCameraSA directly?
Until your comment I did not realise that CCameraSA
existed. From reading the headers it appears that CCameraSA
is essentially a "camera manager" jam packed with LOTS of features, and each individual camera instance (with some features) is a CCamSA
.
But my guess is as good as yours. I suspect that querying from CCamSA here is probably fine.
The top of the files describe CCameraSA
as "Camera rendering" and CCamSA
as "Camera entity".
To confirm, by "look-at" behaviour do you also mean "target current position" behaviour?
I don't know exactly what you mean by "current position" but if you mean the functionality as exposed by setCameraMatrix then yes. If you mean camera following an entity then no.
Describe the bug If you enter or exit a vehicle then GTA:SA performs camera interpolation for a smooth transition. During this camera state, calling getElementMatrix on the camera element returns a wrong matrix. Instead of returning the interpolated matrix, it returns the result of interpolation.
Video https://www.youtube.com/watch?v=orM45pHPiXA
To reproduce 1) join a local server and start this resource: screen-border-detect.zip 2) teleport to the middle of the map (close to 0, 0, 0) 3) spawn a vehicle near you 4) look at the white rectangle and enter the vehicle. you should see the white rectangle leave the hayroll object as long as the camera is interpolating.
Expected behaviour The white rectangle should not leave the center of the hayroll object. Then the camera matrix is the same as used by GTA:SA at all times.
Version MTA:SA 1.5.7
Remarks The issue about the rectangle leaving the hayroll on vehicle acceleration has been addressed by https://github.com/multitheftauto/mtasa-blue/issues/1282 already.