This may be "hiding" a bug in the use of sound/midiparser.cpp in SCI i.e. incorrect use of parseNextEvent(), so this should be reviewed, but this patch initialises _next_event at object construction, which corrects this, should not break anything else and is good practice.
svn-id: r49445
Unlike in the branch-1-1-x I did not restore the old RawMemoryStream
code in the trunk. Instead I stripped out the pre-buffering of the
RawStream code. I still decided to add some in-place buffering
in RawStream::readBuffer to at least not rely on super-fast disk I/O.
This is currently an experimental change. There might be need to
reconsider the buffering (even though backends with slow disk I/O
should actually do buffering for file I/O on their own).
svn-id: r48919
Currently we have an assert checking that the framerate of an
Audio::Timestamp is always > 0. Since MAD might return "0"
(and maybe even other illegal values) in case the MP3 stream is
invalid we need to check that before we setup the _length
Timestamp of MP3Stream.
svn-id: r48904
It is not a good idea to supply an SubLoopingAudioStream with the start
and end time to be exactly the same time. Clarify that in the
SubLoopingAudioStream documentation, add an assert in the
SubLoopingAudioStream constructor for that case and also prevent
make8SVXStream from doing so.
svn-id: r48356
We need to use a namespace Common { } there to make strict C++ compilers
like clang++ and comeau happy. I also added a slight comment about why
that is needed to the macro definition and a note that you need to use
it from the global namespace.
svn-id: r48254
My previous commit which tried to support this does not work correctly when
using QueuingAudioStream; it then just leads to nasty crashes. Hence I am
removing this again for now, until I get around to implement one of the
better alternatives.
svn-id: r48239
* now takes a SeekableReadStream *pointer* like (almost) all other
audiostream factories
* fix potential memory leak in it
* rename takeOwnershipOfStream to disposeAfterUse for consistency
svn-id: r48184
The new DBOPL emulator we are using should support multiple instances though. We *might*
consider allowing as many instances as the user wants. Of course since the original
games only had one OPL chip available, that should not be required. Also just in case
we might allow real hardware as playback device that would be out of the question again
too.
svn-id: r48183
In addition, the code got simplified considerably. Its behavior changed
slightly due to this, but I think the old behavior was wrong. In any
case, this may fix some bugs, or introduce regressions, or both. We'll
see ;).
svn-id: r48058
