| Age | Commit message (Collapse) | Author |
|---|
|
svn-id: r39928
|
|
svn-id: r39927
|
|
svn-id: r39926
|
|
custom insert() operation. It's only used in one place now (in _drawOrderList)
svn-id: r39925
|
|
svn-id: r39924
|
|
svn-id: r39923
|
|
svn-id: r39922
|
|
resulting &* uses can be removed if references are used instead of pointers everywhere, which would be a good idea anyway)
svn-id: r39920
|
|
svn-id: r39919
|
|
that are block waiting
svn-id: r39915
|
|
svn-id: r39914
|
|
more cases of mutually contained rects are deteceted here now, too).
svn-id: r39910
|
|
into 0.13.1 as well.)
svn-id: r39906
|
|
clicking on items inside the hangar"
svn-id: r39664
|
|
used. Also, make sure that the resource data pointer is initialized to zero
svn-id: r39655
|
|
svn-id: r39651
|
|
variables. This fixes another Valgrind warning when SndRes::load() tries to
access the file names. (I could also have made the variables static, but I've
never been very fond of static variables.)
svn-id: r39641
|
|
svn-id: r39638
|
|
We tried to implement the list iterators in a clever way, to reduce code
duplication. But this is essentially impossible to do properly, sadly --
this is one of the places where the ugly drawbacks of C++ really show.
As a consequence, our implementation had a bug which allowed one to
convert any const_iterator to an iterator, thus allowing modifying
elements of const lists.
This rewrite reintroduces code duplication but at least ensures that no
const list is written to accidentally.
Also fix some places which incorrectly used iterator instead of const_iterator
or (in the kyra code) accidentally wrote into a const list.
svn-id: r39279
|
|
some other tweaks
svn-id: r39255
|
|
svn-id: r39237
|
|
- Some initial work on Dinotopia's intro sequence
svn-id: r39234
|
|
svn-id: r39208
|
|
svn-id: r39205
|
|
svn-id: r39203
|
|
svn-id: r39184
|
|
the meaning of the returned string, as discussed some time ago in scummvm-devel
svn-id: r39132
|
|
svn-id: r39003
|
|
implemented by calling the existing init&go methods; to be cleaned up by engine authors
svn-id: r39002
|
|
which will cause crashes under certain conditions, and probably makes SAGA games non-completable.
When a script thread is waiting for another thread, the current instruction offset should not be modified. The thread processing function would incorrectly continue in some special cases, and would incorrectly alter the current instruction offset. This becomes apparent in some special cases only, which made it hard to spot - plus, SAGA games have not been tested for 0.13.0, so there weren't any reports for this.
This change SHOULD go to the 0.13.0 branch, but we've already tagged...
svn-id: r38581
|
|
svn-id: r36210
|
|
svn-id: r36132
|
|
svn-id: r36103
|
|
svn-id: r36101
|
|
svn-id: r35967
|
|
svn-id: r35915
|
|
svn-id: r35884
|
|
svn-id: r35883
|
|
svn-id: r35828
|
|
- Split the video player from the video decoders. It's now possible to have one video player for multiple decoders
- Added the palette weight calculation from the BS1 engine into VideoPlayer::setPalette. It's now possible to find the values of the white and black colors via getWhite() and getBlack() (useful for subtitle overlays)
- Adapted FTA2's movie playing code to the new changes to video player
- Fixed a slight bug in the DXA decoder (_videoinfo.startTime was not initialized)
svn-id: r35816
|
|
- Added a new class, VideoPlayer(), from which both the SMK and the DXA player inherit. This class provides generic functions and public methods for the inherited video classes. Default implementations have been made for these public methods, and the virtual ones can be overriden in inherited classes
- There is now a default implementation of the function that sets the video palette
- A basic video player for inherited classes has been added with method playVideo(). This is able to play a fullscreen non-interactive video, which can be skipped with events set by the caller. Postprocessing methods, which draw upon each frame (e.g. subtitles) can be done by implementing performPostProcessing()
- The FTA2 movie player now uses the new playVideo() method
- The new video player code is compatible with the old one (i.e. no changes to the existing engine code are necessary), but it's now possible to reduce engine code for video playing considerably
svn-id: r35772
|
|
svn-id: r35763
|
|
svn-id: r35762
|
|
statements
svn-id: r35754
|
|
svn-id: r35750
|
|
svn-id: r35749
|
|
svn-id: r35727
|
|
svn-id: r35724
|
|
svn-id: r35705
|
|
svn-id: r35704
|
