| Age | Commit message (Collapse) | Author |
|---|
|
Wherever DVector was used outside of DAffine and CMatrixTransform
I replaced with FVectors. So Internally those functions are still
using DVectors.
This required adding some new functions to FVector that duplicated
functionality in DVector.
|
|
Fixes #10170.
I've added a boolean variable that tracks whether the game is
in the process of locking onto a star or not.
When the user hits the unlock button _isInLockingProcess gets checked and
the request to unlock is denied if the locking on is currently happening.
Once the locking on is finished then the release is lifted and the user
can unlock at this time (or after locking onto the next star).
|
|
|
|
The problem was that the camera when locking onto the 2nd star
was starting at a bad spot and then overshooting when it moved
to do the locking movements.
A solution I picked is just to start at the final spot.
I also removed the check that the distance the mover had to move
was too large since the bug is now avoided.
|
|
Named many variables in the lockMarker2 functions.
|
|
Very important for StarCamera:lockMarker2 is an inverse of the
difference between locked star1 and about to be star2.
Before it was calculating the col4 values by doing a
new col4 = -inv(R)*col4. col4 represents the x,y,z
position of the vector. This calculation is not correct
in the most general sense and is only valid for a single
rotation and translation.
For any more than one rotation and translation the upper left
3x3 inverse is still the transpose of the previous 3x3
portion there since that is just the rotation part, but the
translation part is now R2T1 + T2, which can't be undone by
simply multiplying by the inverse of R2. This gets more complicated
for lots of rotations so I've added a general 4x4 inverse
calculation and just pulled of the column 4 values.
The inverse implementation I used was from the mesa 3d library and
that has an MIT license so its okay to use in GPL.
|
|
More correct function naming then before.
|
|
This makes lockMarker2 more manageable.
|
|
|
|
|
|
1. Removed updatePosition function defintions since
UnmarkedCameraMover and MarkedCameraMover, derived classes,
are overriddening it. I.e., CCameraMover::updatePosition doesn't
get used.
This also allowed some header files to removed.
2. Renaming of some functions.
|
|
|
|
TITANIC: Viewport refactor
|
|
1. Improved naming of functions.
E.x., fn17 is now called getRelativePosNoCentering
2. Improved variable names
E.x., _valArray[3] is now _pixel1OffSetX, naming makes sense for it
use in CBaseStars::draw.
3. Lots of comments and TODO added for suspicious behavior
Mentioned unused functions and values that don't get used.
4. Changes in other classes that viewport renaming affected
Some of the star_camera functions were 1-1 mapping of
functions in viewport so I just made the names be the same.
|
|
One of the fields wasn't getting saved. This field determines
whether the star color should be pink or white. It gets recomputed
when you put the helmet back on so it doesn't really matter.
Previously, when it loaded this value it was loading some orientation
data which occurs next in the saved data file for saved games saved
by scummvm versions before this commit.
|
|
I wanted to use that variable in viewport.cpp and since fvector.h
is included in more functions (already) then dvector it makes sense
to move it there.
|
|
This adds a non-member function that computes the
product between two fpose "matrices" and puts it in
a third. One of the constructor was doing that so now
it calls this non-member function.
|
|
|
|
Minimized a lot of the unncessary files includes in the
implementation files as well.
|
|
I reduced the header includes a lot in Titanic.h and forward
declared when I could. Titanic.h was including a lot and
a lot of functions that were including it were not using its
API. This will help make it more clear which implementation
files are using which class since they will just need to include
which ones they need.
I also moved the debug related items in Titanic.h into the debugger
header.
I also reordered several of the the header includes to be local to
global.
|
|
|
|
This variable controls the number of transitions the game goes
through when the mover is changing position. This reduces
several 31/32s from the code.
|
|
Named some functions, made _speeds be an array instead of
a dynamic one.
|
|
|
|
I have added a conditional to the code so that if the player
tries to lock onto the 2nd star and they are very far away, >1e8,
then the game will not allow the star to be locked.
This is a temporary workaround since if a distance of farther
then this is attempted then the view will be throw way off
and the stars will not be shown locking onto correctly.
I've also made the locking functions return booleans so I can
determine the success of the lockings.
This is a partial fix for #9961.
|
|
The code was preventing the position and view from changing
when the distance between the current and new position for
a marked auto mover was zero. This happens if you lock the
2nd or 3rd star and then unlock and relock again.
It was prevented this with asserts and if statement checks
and I removed them all.
This section of code isn't doing any inverses based on the
reciprocal of the distance so theres no issue with allowing
transition speeds/distances of zero.
Fixes #10148.
|
|
|
|
Originally, if you unlocked a star when you had 2 or 3 stars
locked and then relocked without changing views then the game
crashed.
This was because it was trying to transition a distance of zero
and this failed an assert (to normalize the length to be the distance).
The transition is no longer done so the crash does not happen.
Fixes #10147.
|
|
Before the normalization function was asserting if it couldn't
normalize now the caller can determine what to do with a failed
normalization.
|
|
If you want to remove locked stars you can do so using the D key,
but previously, you could also deselect a currently locked star
via the skymap and it would crash.
It previously crashed if:
1. You had 2 stars locked on and you tried to remove the 1st
2. Had 1 locked and 1 unlocked and you tried to unlock the 1st
3. Had 2 locked and 1 unlocked and you tried to unlock any of
the other two locked stars.
Refactoring would allow quicker comprehension of the logic of
this section of code.
Fixes #10126.
|
|
Before it was add/remove row so the new name is more informative.
|
|
This involved removing header files and forward declaring when possible.
I also reorded the header include files to be local to gloabal.
E.x., in the class implementation the class header file
would be the first included.
This is a first pass of header reduction for star_control/ files
|
|
|
|
Was doing 3x3 inverse now it is doing a transpose.
Also named the function.
|
|
Replace rotation inverse with transpose.
inv(R)=tranpose(R) for rotation matrices.
|
|
Changing the fpose Y axis rotations flipped some of the keys (z,x)
so I added in negatives to fix that.
Also before slash was looking up and comma was looking down.
This is the same as the original, but I think thats less
intuitive so I have reversed that. It also makes those keys
now correct in the readme.
|
|
Add negatives to star camera turning rotations so view turns correctly
when no stars are marked and 1 star is marked.
|
|
|
|
TITANIC: DAffine refactor
|
|
|
|
The X and Z rotation already follow the convention given in wikipedia,
but the Y axis rotation doesn't (its the negative angle) so I switched
that and updated where that was used.
This allowed stray negatives for angle calls to this function (for Y
rotations) to be removed from other parts of the code (dvector).
In theory this was a non-functional change. In dvector the code was taking
the negative of the angle so it was essentially doing the negative of the
negative, but when it was used once in star_camera it was not
(when it should of been). So That was changed. That part of the code
was used for locking onto the third star after the 2nd was already locked.
I can't tell if the star control puzzle has improved after this change.
It can still have issues locking onto the 2nd star and also not.
Also added lots of todos for things to check.
|
|
The matrix product doesn't change anything about the class so it
doesn't need to be a member function.
This way other functions can do multiplication of matrices.
|
|
Changed the left and right matrix product to use the matrix
product function with the matrix order reversed.
|
|
renamed fn2->MatRProd and fn3->MatLProd.
They do post (R) and pre (L) multiplication.
|
|
The previous code wasn't reseting all the other elements to zero
when setting up a rotation matrix. This would of left other values
in the not set elements leading to a matrix not quite what the caller
wanted. This should lead to the function getFrameTransform returning
a different Daffine matrix.
Also added lots of todos
|
|
Made default constructor col4 construction explicit.
Change amount argument to be angle_deg. Added constant
from dvector that does conversion from degrees to radians".
Also moved conversion constants for angles in dvector to
header file so daffine could use that.
|
|
|
|
It does a rotation around the X axis then Y.
|
|
This function was using two vectors one as a frame rotation and
the other as a vector/point rotation.
This function is only used in when you click on a star in starview.
|
|
replace atan2 implementation
fn3 in dvector returns a vector that stores a magnitude, and 2 angles.
The second angle (the z component of the returned vector) was the angle
that the internal vector was between its z and x axis.
This angle was obtained by doing a poor man 4-quadrant atan implementation
and it gave large values for negative x. This has been replaced with the
atan2 standard function.
|
