| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In scummvm and the original engine if you try to
unlock/lock stars in photoview/skyview then the
stars will not unlock/lock, but the sounds
associated with unlocking and locking were playing.
Giving a false impression that the
locking/unlocking was happening.
The sounds no longer play when in photoview.
|
|
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.
|
|
|
|
Made camera automover setOrientations not virtual and reduced
arguments also changed name since to differentiate it from
behavior of derived classes.
|
|
There was a setPath() adn setPath2() function took in
different arguments and were doing the same thing, but
not using the different arguments. I made it into
one function that only takes in the arguments it uses.
Also it was marked virtual, but all the derived classes,
CMarkedAutoMover, and CUnmarkedAutoMover were just doing
there own thing and then calling this base class implementation.
Therefore, I made it be not virtual and the derived classes can do
there own thing and then call this, but since they are doing slightly
different things it makes sense to differentiate the names and not have
them all be called setPath. I.e., the derived classes also change
the orientation so that is included in their function names to reflect
that.
|
|
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.
|
|
|
|
|
|
|
|
This allows DAffine and FPose to use a double version
and a float version of matrix4Inv.
|
|
|
|
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.
|
