Age | Commit message (Collapse) | Author |
|
We can easily rely on the FS path resolving.
|
|
|
|
In SSCI, strchr is called against a hex string with a duplicate 0
("01234567890abcdef") to determine the decimal value of hex digits,
which means the values A-F are incorrectly interpreted as 11-16
instead of 10-15.
All versions of SSCI with support for hexadecimal escape sequences
in messages (starting somewhere around Feb 1993) are buggy.
The native save/load dialog of SCI32 relies on this defect to
render the up and down arrows of the game selector.
Fixes Trac#9582.
|
|
|
|
|
|
|
|
|
|
|
|
It was storing filenames of length 12 in a char[12] buffer.
Fixes bug #9627.
|
|
ANDROIDSDL: Changed logic for back button & getting sdcard storage location
|
|
|
|
|
|
|
|
Previous fix for CID 1364205 was actually for CID 1364306.
|
|
|
|
|
|
CID 1364219
CID 1364223
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libSDL wrapper
|
|
call scummvm in-game menu. CONTROL key now can be uses with games
|
|
The issue could occur when adding or removing widgets to a tab, and then
not switching to a different tab before the destructor or reflowLayout() were
called. In such a case the firstWidget of the current widget in the _tabs list
could be out of date. Accessing this first widget from the destructor or from
reflowLayout() could then cause a crash, or random issues caused to access
to free'ed memory. In theory this could also lead to a memory leak, although
I don't think this could occur in our current code.
Usually we add several tabs to a TabWidget and then switch back to the first
tab after building all the tabs. So in such a case the issue would not occur.
But because we are deleting and reconstructing the clear buttons for the
MIDI and Path tabs of the options dialog from reflowLayout(), if the current
tab is the Path tab, it would be kept as active tab after adding and removing
widget to it and the issue would occur.
This fixes bug #9618.
|
|
A value of 0 is valid for tab ids, so the correct initialisation at this
stage is -1. However only one constructor properly initialized all the
tab ids to -1 in its initialisation list, but it was then changed to 0 in
init(). I have added the missing ones to the other constructors and
removed the incorrect ones in init(). But maybe all tab ids should be
initialised in init() rather than in the constructors initialisation lists.
|
|
|
|
SSCI transitions code sends a large number of small show rects
to the graphics manager, one at a time, for each division of a
transition. Each time a rect is submitted, a call to showBits
is made. This design was used when transitions for SCI32 were
first implemented in ScummVM, and it worked OK because the
hardware surface was updated by EventManager::getSciEvent,
not showBits, so the large number of calls to showBits from the
transitions code did not adversely affect engine performance.
Later in SCI32 engine development, hardware surface updates
were changed to occur in showBits so that the hardware surface
would be updated at frame-out time, instead of at input-in time.
This change meant that now the large number of calls to showBits
from transitions became very expensive, and the engine would
stall constantly refreshing the entire hardware surface.
To fix this problem, the transitions code now (1) maximises the
size of rects coming from transitions, when possible, and (2) only
calls showBits when all the rects from one frame of a transition
have been calculated and added to the show rects list.
Additionally, there were some arithmetic errors in the
implementation of pixel dissolve that have been corrected in this
changeset.
Fixes Trac#9614.
|
|
|
|
Fixes a couple of issues reported by valgrind and clang
sanitizers.
In particular, the initialization of Actor::_inCombat means that McCoy
no longer randomly has his gun out at the beginning of the game. In
SliceRenderer::drawInWorld, the assert of _sliceFramePtr has been
moved to after the call to setupFrameInWorld which is the method that
initializes the field. This misplaced assert caused the game to crash
for several people.
|
|
|
|
The original starts a movie for the Doorbot taking his cloak off,
but then plays a cutscene of the doorbot first appearing. Because of
this delay, our VideoDecoder wasn't correctly playing the movie after.
To fix that, new movies are initially paused when started, and then
resumed the first time we try to do events checking for it
|
|
|
|
|
|
|
|
We now require GCC 4.6, where this bug has been fixed.
|
|
|
|
|
|
Fixes Trac#9584.
|
|
|