| Age | Commit message (Collapse) | Author |
|---|
|
These are flagged by GCC if -Wswitch-default is enabled.
|
|
|
|
|
|
|
|
The functions that dealt with the mover handling only
had handler in the name so I added mover and type to the
name to reflect that it involves the mover handler.
|
|
|
|
I differentiated getRelativePosCentering() and
getRelativePosCentering2() since one was using
the raw Pose and one was using the regular Pose.
|
|
|
|
I fixed this previously for star2, I thought the
overshoot for star3 locking might have also been fixed
since I hadn't observed it in a while.
I applied the same workaround by setting the old position
to be the new position.
|
|
|
|
|
|
More swapping of functions in the Orientation and Transform classes.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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
|
|
|
|
Add negatives to star camera turning rotations so view turns correctly
when no stars are marked and 1 star is marked.
|
|
|
|
It does a rotation around the X axis then Y.
|
|
|
|
It does a matrix product with a vector and a z translation
|
|
This changes the starview manual camera movement using semicolon.
Before it slowed down the ship. To make it more like the original
game it now adds negative velocity so that it slows down then
speeds up in the backward direction.
The functions were renamed accordingly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
