Age | Commit message (Collapse) | Author |
|
as much about the text handling functions.
svn-id: r10137
|
|
svn-id: r10136
|
|
if we have the focus, so there's no need to check.
svn-id: r10130
|
|
througout the code.
svn-id: r10127
|
|
trivial to actually play the Smacker voice-overs, but I think the sound
code needs a bit more cleaning up first. (I'm pretty sure it isn't
alignment-safe, and it might not be endian-safe either.)
svn-id: r10123
|
|
svn-id: r10104
|
|
svn-id: r10100
|
|
available, since they are separate from the Smacker files themselves.
Next step will be to play the voice-over sounds as well, and to make sure
subtitles settings etc. are taken into account (if they aren't already).
svn-id: r10099
|
|
load). The new code is smaller, hopefully a bit easier to read and doesn't
use up all the CPU time.
Of course, it may some new and exciting bugs too. ;-)
svn-id: r10079
|
|
svn-id: r10058
|
|
svn-id: r10056
|
|
svn-id: r10023
|
|
svn-id: r10010
|
|
svn-id: r10009
|
|
implementation of music fade-out that makes it a bad thing to close the
music cluster file prematurely.
svn-id: r10007
|
|
svn-id: r10004
|
|
currently don't fade music that ends because we reached the end of the
musical cue, though. Only music that ends because it's being replaced by
another cue.
svn-id: r10003
|
|
svn-id: r9995
|
|
but at least it doesn't seem to do any harm.
Disabled the sound FX "garbage collection" in FxServer(). I'm not really
convinced it's necessary at all, and even if it is, doing it from a
separate thread it just begging for trouble. I've modified OpenFx()
slightly to deal with this, but I may still have introduced regressions.
Temporarily disabled the "goto label1" hack, since it seems to be the main
reason for ScummVM crashing if I allow a piece of music to finish on its
own (i.e. when not terminating it prematurely by triggering another piece
of music).
svn-id: r9990
|
|
the functions which access data manipulated by FxServer().
For instance, FxServer() may free bufferFx[i], which sounds potentially
unhealthy to me.
svn-id: r9989
|
|
never read.
svn-id: r9984
|
|
originaly dsound has 3 seconds buffer fillled with data enought for fading
this hack continue play music for time while fading is going
svn-id: r9983
|
|
svn-id: r9982
|
|
svn-id: r9981
|
|
init sound data to class sound
svn-id: r9980
|
|
stream, in which case the warning about the sound handle being 0 is bogus.
svn-id: r9973
|
|
warning messages about uninitialised sound handles.
svn-id: r9972
|
|
svn-id: r9971
|
|
in-game dialogs.
svn-id: r9969
|
|
channel indexes, we should use stopHandle() instead of stop() to kill the
music channel.
Am I the only one who finds the distinction between channel indexes and
sound handles confusing at times? :-)
svn-id: r9967
|
|
svn-id: r9956
|
|
svn-id: r9951
|
|
svn-id: r9950
|
|
svn-id: r9944
|
|
music channel has faded out, destroy the channel immediately. Don't wait
for the mixer to finish it off.
This seems to fix a problem where the mixer would eventually run out of
slots if you left the Quit dialog showing for too long.
Unfortunately I don't know if it fixes the "out of slots" errors I
encountered once during normal play. Oh well, time will tell...
svn-id: r9942
|
|
svn-id: r9939
|
|
This should also fix the bug where music sometimes didn't start playing.
svn-id: r9938
|
|
svn-id: r9934
|
|
is the only place I can think of where this could have happened, so I've
added a paranoid check to ensure the buffer length is even.
Let's see how that works out...
svn-id: r9933
|
|
svn-id: r9931
|
|
svn-id: r9928
|
|
svn-id: r9927
|
|
fine but you don't hear anything) newStream, and appendStream doesn't work but playRaw works for music
svn-id: r9923
|
|
svn-id: r9920
|
|
already reached its scroll target. This keeps BS2 from using all available
CPU time all of the time.
It may still be that we need a mechanism for throttling the frame rate when
the scene is moving towards a scroll target, but my computer isn't really
fast enough to test that.
Two other bugs fixed in the process:
* I think the last frame of the render cycle was rendered, but not
displayed. If so, that should be fixed now.
* I discovered that there are cases where we do need to clear the screen
(e.g. at the "Meanwhile..." message when George has found out about the
Glease Gallery), so I've re-enabled the function and disabled it in the
render cycle.
svn-id: r9904
|
|
block surfaces. (A block surface is a 64x64 tile of a parallax layer.)
I've also done a few things to try and optimize the drawing:
* The back buffer is no longer cleared between frames. This may cause
regressions, but I do believe that the entire picture area is always
completely re-rendered for each frame.
As a result of this, the menu code is now responsible for clearing the
icon areas itself.
* A few unnecessary copy_rect() calls were commented out in favor of one
big copy_rect() in ServiceWindows().
* Completely opaque block surfaces are copied with memcpy(), one line at a
time.
Unless we manage to add intelligent screen redrawing, I don't think it will
get that much faster than this, though there is some unnecessary data
copying in DrawSprite() that could be removed.
And the game is still a terrible CPU hog. I believe the animation runs at
approximately 12 fps. If there's still time left, it will pump out further
frames to get smooth scrolling. We ought to put a cap on that, and if it
has already reached the scroll target it should sleep for the rest of the
render cycle.
svn-id: r9886
|
|
svn-id: r9885
|
|
svn-id: r9884
|
|
I don't know if I got it right - the result doesn't look that great to me -
but at least the infrastructure is there.
This, I think, marks the point where BS2 graphics is pretty much done. Some
functions haven't been unstubbed yet, but I believe they're used for
debugging and/or profiling. I'm not sure they're worth the trouble.
Of course, there is still testing and clean-ups to make. For instance, I'd
like DrawSprite() to use malloc() a bit less.
svn-id: r9879
|
|
code to be more in line with the ScummVM coding style.
svn-id: r9878
|