The PS2 versions are not working at all. Furthermore,
the detection entries caused AdvancedMetaEngine to output
a misleading error message when the game executable cannot
be found.
Both the animation components/tracks and the chores itself keep track of
the current time independently:
animation component:
- AnimationStateEmi::_time
- initialized with 0
- after the first update() call, _time is advanced by the frametime
chores:
- Costume::_currTime
- initialized with -1
- during the first update() call, _currTime is set first to 0
- during the next update() call, _currTime is advanced by the frametime
EMICostume::update() updates first the chore and then all components
with the same frame time. This has the effect, that the internal time
base of the chore and the animation has always an initial offset (the
value of the frametime of the first update() call).
For some costumes, the chore will pause the animation by setting the
according key for that animation at the end of the animation. However,
since the animation component has a different time base, it has already
reached that point and may have already disabled itself entirely
(instead of just being paused by the chore).
This bug fix let the animation set _time to 0 in the first update() call, too.
Any consecutive update() call will advance the time by the frametime.
This will keep the two time bases of the chore and the animation component
in sync.
Instead of just ordering the textobjects by their layer, use their
creation time (indirectly provided by the pool ID which is continuously
counting up).
This ensures that if there are multiple textobjects with the same text
ID and the same layer, that the latest is drawn last and overwrites the
previous ones.
That's necessary since the LUA code will create multiple instances of
the same textobject for the color fading effect in the credits.
Enabling quadratic atenuation, even with values as low as 0.1, reduces spot
lighting too much in (at least) sets "do" (see Domino), "al" (see Manny when
walking along the garage door), "hq" (see Salvador).
Disabling is not perfect either, as attenuation can be seen (at least) in
set "tu" (see fire extinguisher), but it should be overall better.
Also, it should be noted that perfect fidelity cannot be achieved with openGL
fixed pipeline, as DirectX spotlight have two angles (0 <= phi <= theta <= pi),
atenuation being null below phi, full above theta, transitioning with a
configurable exponent between both (defaults to angle-linear). OpenGL would
correspond to phi=0 and theta=pi (ie, transition is always done between fixed
angles), plus a configurable hard cutoff.
Determined by enabling a single omnidirectional light (newlight9 in set
"ce", which stands at set entrance toward elevator) and comparing
luminosity level on Manny at several locations in that scene with original
software renderer.
This set is quite convenient for this comparison, as Manny position can be
easily controlled: stick to the wall with the red arrow pointing at the
stairs, making movements one-dimensional.
For spotlight, set "tu" was used with the single spotlight on, walking
from the fire extinguisher to server door, confirming similar attenuation.
From these tests, it seems only quadratic attenuation is used, which makes
sense as it gives a realistic effect.
Determined by keping a single directional light source enabled, as they are
not subject to attenuation (having no position), and comparing with
original software renderer.
Default DirectX material reflects all diffuse light, so 1.0f coefficient is
likely correct.
My initial idea that GRIM would use specular likely came from a difference
between DirectX and OpenGL lighting for spotlights: DirectX allows for an
extra penumbra angle, allowing stronger center spots while maintaining a
smooth fade (which I emulated with a fixed 2.0 exponent).
Also, specular involves an extra light color value and material definition
for specular reflection, which are not visible in game data files.
All this making the use of specular very unlikely to match original renderer.
This patch enables drawing of Layer objects which are
dynamically created by LUA code.
All three sorted lists (background images, layers and actors) are
merged based on their sort-order.
Instead of using the number of sub-images to decide whether bitmaps
should be drawn using TIL information, better use the existance
of texture coordinates which are distinctive for tiles.
