| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This should have been done when making changes to it but I forgot.
|
|
|
|
|
|
|
|
|
|
updateInfoFlagViewVisible accepts a property index, not a selector
ID.
Fixes Trac#9583.
|
|
|
|
|
|
|
|
Exports with a zero offset are supposed to point to the start of
the code block in the script hunk, but they were being ignored.
This may also apply to SCI1.1 games, but until that can be
verified, this fixes the zero-offset in only SCI32 games for now.
|
|
It appears that Mac Sparkle does not ignore the Windows binaries,
and offers to upgrade to Windows executable. Thus, in the meantime
we supply binary with the version change only.
|
|
Kind of nit-picky but it was annoying me that it was ALMOST sorted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
