This patch also cleans up the GK2 audio map blacklisting code to
reduce the number of redundant checks being made during audio map
processing.
Fixes Trac#10172.
This can happen during game restores in at least Lighthouse, which
has a Robot on the menu screen whose plane is deleted prior to
a call to kRestoreGame32 (which closes the Robot).
Lighthouse audio.225 in RESSCI.002 (US English 1.0C) triggers this
condition; the audio resource says its data is one byte larger
than the recorded size in the volume. In this case, just use the
smaller of the two values for the size, to avoid overreads.
This is needed for 8.VMD in Lighthouse (room 380, the credits
room), which is rendered partially off the bottom of the screen.
OSystem does not accept rects that are offscreen.
Technically this video probably should not have been doubled
vertically by game scripts, but there is not enough space to fix
the rendering with a regular script patch, and it is a very
unimportant video.
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.
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.
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.
