Age | Commit message (Collapse) | Author |
|
|
|
Fixes Trac#9761, Trac#9844, Trac#9850, Trac#9851.
|
|
To move data from one SpanOwner to another, use `moveFrom`.
Thanks @waltervn for pointing out the problem.
|
|
|
|
|
|
|
|
This fixes bug 9786. Thanks to m_kiewitz for verifying with disasm.
|
|
This may be masking another bug, but at least what happens in
Phant1 is that the mouse does not get redrawn after being moved
programmatically to the fast-forward button when deviceMoved
returns early.
|
|
|
|
Videos in GK2 use this flag (e.g. the chapter 6 intro).
Now that GfxPalette32::updateHardware no longer calls
OSystem::updateScreen (only GfxFrameout::frameOut does this now),
every time a palette swap occurs during playback, there is a frame
of blackness that should not exist. This is because the order of
operation is:
1. Send black palette
2. Call frameOut (which updates the screen)
3. Send new, correct palette
4. No frameOut (so the screen is not updated with the correct
palette)
OSystem::updateScreen cannot be called multiple times for the same
frame due to vsync, but also, there does not appear to be any
reason to send a black palette, since it seems to be intended to
avoid temporarily rendering video frames with the wrong palette on
a hardware device that cannot guarantee simultaneous application
of a new palette and new pixel data. ScummVM does not have such
a problem, so this feature appears to be unnecessary for us.
For the moment, this 'feature' remains hidden behind an ifdef,
instead of being removed entirely, to avoid potential confusion
when comparing VMD code from SSCI.
|
|
More than one call to OSystem::updateScreen per frame on systems
with vsync ruins performance because the call is blocked until
the next vsync interval.
This also fixes bad rendering performance with the OpenGL backend.
|
|
|
|
|
|
The approach to video benchmarking used by SCI engine does not
translate very well to modern video devices -- it will either be
so slow that the games think the system is not capable of showing
normal visual effects, or so fast that the benchmarks overflow
their counters. So, game scripts that perform video benchmarking
are now patched to unconditionally return the highest speed value.
A pleasant but subtle side-effect of this change is that the extra
time sitting at a blank screen before the start of a game (while
benchmarks ran) is now gone.
Fixes Trac#9741.
|
|
This reverts commit c02f2674ad3533aebd6c5dbcaf47f3e1d20904a4.
Two minutes after committing this, the author of the ticket
resolved the problem, which was caused by missing VMDs.
|
|
Refs Trac#9740.
|
|
This flag was used in SSCI to read from VRAM instead of from the
back buffer when a mouse interrupt was received in the middle of
a back buffer update. Since ScummVM controls when mouse events
are received via polling, it is not possible to receive a mouse
event in the middle of back buffer updates, so this code is
unnecessary for the engine to work properly.
This also fixes Valgrind warnings about use of uninitialized
memory at the start of the game, caused by not filling the cursor
memory buffers because `_frameNowVisible` was false until the first
frame was rendered.
|
|
This is necessary for at least Lighthouse, which maintains the
state of Robots across save games.
|
|
This happens e.g. on the About page in LSL7 because of an
interpreter problem where bitmap handles are destroyed and then
reused without a kFrameOut call to remove old screen items from
the visible plane list before a kIsOnMe call that causes the
engine to try to read from reused bitmap handles with different
contents and dimensions.
This replaces bad memory reads on the About page in LSL7 with an
assertion failure, until the problem with the About page can be
properly addressed.
|
|
This code branch, existing since at least SQ6 but apparently never
used by any SCI2/2.1 game, is in fact the algorithm used by SCI3.
This fixes (at least) doubled rendering of transparent surfaces
like the background of the inventory window and conversation
choices panel in LSL7.
|
|
This was causing uninitialised garbage data from the scale buffer
to be drawn to the screen.
|
|
|
|
Used by RAMA, when playing a video at the Hub Camp computer at the
beginning of the game (room 1004).
|
|
In Phant2, when going to email on Curtis's office computer, a
screen item that contained a bitmap on the last frame was updated
to contain a view on the next frame. This crashed the engine when
it tried to reuse the old disposed bitmap instead of the new view
because the cel type was never changed from kCelTypeMem to
kCelTypeView.
|
|
The boost is intended to compensate for the darkness caused by the
black lines, so should not be applied when there are no black
lines. This fixes too-bright videos in at least LSL7.
|
|
In at least RAMA, when using the pocket computer to view a mail
and then pressing the "return" button, the ScreenItem containing
the VMD will be destroyed before the VMD player is told to close
the video, resulting in a use-after-free trying to access the
bitmap ID through the deleted ScreenItem.
|
|
The typo was `if (kCelTypeColor)` instead of
`if (type == kCelTypeColor)`. Changed to use a switch instead for
improved clarity and code intelligence.
|
|
|
|
Fixes text scaling gone mad in Phant2.
|
|
Sometime during SCI2.1mid, the palette manager was changed to
save and restore the source palette, and to add in-game gamma
correction. Previously, only the vary start and target palettes
were saved, and gamma correction was only configurable in SSCI by
editing RESOURCE.CFG.
|
|
_delayedRestoreGame is always set and cleared at the same time as
_delayedRestoreGameId, and _delayedRestoreFromLauncher is written
but never read.
|
|
|
|
Fixes bad scaling of text when switching between games with
different script resolutions.
|
|
Fixes the non-interactive Lighthouse demo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes the ego disappearing behind the castle doors in MGDX.
|
|
|
|
In PQ4CD, when leaving the shooting range through the front door,
some transition screen items will be generated that have invalid
dimensions. SSCI simply clips these rectangles to zero.
|
|
PQ4CD and several other games contain a hack in two renderer
methods to avoid rendering invalid screen items with zero or
negative-dimension target rects. This prevents PQ4CD from
crashing during the fifth phase of target practice.
|
|
|
|
|
|
This is most noticeable at the beginning of the game during
benchmarking, where the benchmarking loop used to cause the mouse
to get stuck for the duration of the benchmark.
|
|
|
|
|