Age | Commit message (Collapse) | Author |
|
|
|
|
|
This is a simpler fix than the one I committed to the 1.3 branch,
but since it carries a theoretical risk of regressions it's so
much more macho.
|
|
GetNextObject().
Signed-off-by: Max Horn <max@quendi.de>
|
|
OBJECT** for a pointer to the head.
Signed-off-by: Max Horn <max@quendi.de>
|
|
|
|
Commit 43ca9c86ab causes segfaults when trying to start a game in tinsel.
However, the code in question still should be investigated, as it
casts OBJECT** pointers to OBJECT*. Very fishy.
|
|
This also removes the dependency of engines on the event recorder header
and API, and will make it easier to RandomSources that are not properly
registered.
|
|
This unifies the engine names in MetaEngine::getName() and the
credits. In particular drop "Engine" or "engine" from the names when
it was present and use expanded names in credits when the
MetaEngine uses it (e.g. "Beneath a Steel Sky" instead of "BASS").
|
|
|
|
|
|
|
|
For further discussion check here:
https://github.com/scummvm/scummvm/pull/16
Conflicts:
graphics/png.cpp
|
|
Some backends may break as I only compiled SDL
|
|
|
|
|
|
|
|
See https://github.com/scummvm/scummvm/pull/12 for more information.
|
|
byte depth.
|
|
|
|
|
|
|
|
differently.
|
|
|
|
MKID_BE relied on unspecified behavior of the C++ compiler,
and as such was always a bit unsafe. The new MKTAG macro
is slightly less elegant, but does no longer depend on the
behavior of the compiler.
Inspired by FFmpeg, which has an almost identical macro.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also should fix some regressions from the previous
commits, related to MidiParser's either being leaked,
or being deleted and then used again (i.e., crashing).
I tested as many games as I had available, but further
testing of all affected engines is called for anyway.
|
|
|
|
|
|
The regression affected AGOS and maybe some others; specifically,
the real MidiDriver would have been deleted twice -- I previously
missed that the Engine instances takes care of freeing the real
MidiDriver, not the MidiPlayer wrapping it.
This commit should clarify the ownership of the real MidiDriver for
most pseudo MidiDrivers.
|
|
Many engines follow the advice in audio/midiparser.h and create a
"pseudo-MidiDriver" subclass. But MidiParser really only needs a tiny
subset of the MidiDriver capabilities, namely those found in
MidiDriver_BASE. So we try to subclass from that whenever possible; this
allows us to remove many stub methods, and enables further future
simplifications.
|
|
|
|
This in turn enables modifying MidiDriver_MPU401::close() to allow
it to be called on a midi driver that has not yet been opened.
The specific issue that triggered me to make these changes was a
crash-upon-quit in HUGO, caused by it instantiating a midi driver,
then encountering an error (missing hugo.dat) *before* having
opened the new midi driver; the general cleanup code then tries
to close the (not yet opened) midi driver -> kaboom
Also fixed some engines which were leaking MidiDriver instances.
|
|
re-release of DW1 (bug #2827022)
|
|
This is done by converting the internal RGBA palette data to RGB before
calling setPalette. This might not be the best solution, but looking a bit
into the engine it seems like changing all the code to work with RGB instead
of RGBA might require some bit of work.
|
|
svn-id: r55850
|
|
svn-id: r55818
|
|
svn-id: r55806
|
|
This is a regression from r55256. Apparently, SCUMM has issues when sending a sustain
off on a notes off event. Thus, this has been turned into a feature, which is disabled
by default. Since MADE, SAGA and tinsel all share the same music code and play regular
MIDI files, and this feature fixes hanging notes for them, it has been enabled for them.
Also, applied a patch for a bug regarding the notes off event in MADE and tinsel,
which has been applied in SAGA already
svn-id: r55746
|
|
This fixes the leak from the COR0_BEGIN_CODE macro's CoroContextTag allocation.
Setting the _sleep value to negative values prevented the deallocation of these.
Have tested for obvious regressions, but a full DW/DW2 playtest should be done to confirm that this doesn't cause any issues.
Thanks to fingolfin for indicating this solution.
svn-id: r55671
|