Updating the cursor's texture is not necessary if it is not going to be drawn.
Fixes glDrawArrays sometimes failing due to using a framebuffer with an
incomplete color attachment. In SCI32 games, the framebuffer is incomplete
because the engine does not define pixel data for the cursor.
In SSCI, mouse events are received through a hardware interrupt
and the cursor is drawn directly to the graphics card by the
interrupt handler. This allows game scripts to omit calls to
kFrameOut without stopping the mouse cursor from being redrawn
in response to mouse movement.
ScummVM, in contrast, needs to poll for events and submit screen
updates explicitly from the main thread. Submitting screen updates
may block on vsync, which means that this call should really only
be made once per frame, just after the game has finished updating
its back buffer. The closest signal in SCI32 for having completed
drawing a frame is the kFrameOut call, so this is where the
update is submitted (by calling OSystem::updateScreen).
The problem with the approach in ScummVM is that, even though the
mouse position is being updated (by calls to kGetEvent) and drawn
to the backend's back buffer (by GfxCursor32::drawToHardware),
OSystem::updateScreen is never called during game loops that omit
calls to kFrameOut.
This commit introduces a workaround that looks at the number of
times kGetEvent is called between calls to kFrameOut. If the
number of kGetEvent calls is higher than usual (where "usual"
seems to be 0 or 1), we assume that the game is running one of
these tight event loops, and kGetEvent starts calling
OSystem::updateScreen until the next kFrameOut call. We also
then start throttling the calls to kGetEvent to keep CPU usage
down. This fixes at least two such known loops:
1. When interacting with the menu bar at the top of the screen
in LSL6hires;
2. When restoring a game in Phant2 and sitting on the "click mouse"
screen.
A similar workaround may also be needed for kGetTime, though loops
around kGetTime should preferably be replaced using a script patch
to call kWait instead.
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 3313916a21.
While this change happens somehow to work on big-endian without
any warning, it also totally breaks little-endian... without any
warning either. I'll go RTFM C++.
As of gcc-6.3.0:
../common/endian.h: In function `float get_float(const char*)':
../common/endian.h:621:49: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
Exposed to command line via --[no-]dirtyrects.
As dirty rectangles make the workload vary a lot between frames, it makes
performance regressions harder to spot. Disabling it produces lower, but
much more regular FPS counts.
32, 16 and 0 (default) are supported, 0 currently falling back to
32 as it was the previous default (should auto-detect eventually).
Only supported by software renderer for now.
There were several issues.
The first one was introduced recently and caused the preferred target
to be used as a game ID, which resulted in an error when this is not
a valid game ID. Thus this fixes bug #9754.
The other issues were here since the auto-detect command was added and
caused other command line options, suh as the path, to be lost. This
usually resulted in a failure to start the game as the data files could
not be found (unless the ID happened to be the same name as a target
previously added). This also caused a reappearance of the old bug
Bastien Bouclet
Paul Gilbert
Colin Snover
Tarek Soliman
Martin Kiewitz
Vincent Pelletier
Retro-Junk
Thierry Crozat
Eugene Sandulenko
Tobia Tesan