| Age | Commit message (Collapse) | Author |
|---|
|
File::exists method
svn-id: r15913
|
|
that change is reflected everywhere
svn-id: r15911
|
|
'directory' parameter from SaveFileManager::openSavefile and listSavefiles (they always use getSavePath() now, which is what we did anyway)
svn-id: r15901
|
|
svn-id: r15890
|
|
There are plans to add some brains to GameDetector class, which will let us
avoid passing detector to init() method.
svn-id: r15873
|
|
svn-id: r15865
|
|
objections)
svn-id: r15849
|
|
svn-id: r15835
|
|
svn-id: r15826
|
|
in his mail to scummvm-devel. (Though "a discussed a while ago change"
sounds like sort of thing Robert Jordan writes whenever there is danger of
anything actually happening in any of his more recent books. Tantalizing,
yet non-informative. ;-)
It's still rather messy. I'll look into cleaning it up later.
svn-id: r15818
|
|
svn-id: r15810
|
|
itself. :-)
svn-id: r15789
|
|
svn-id: r15701
|
|
svn-id: r15612
|
|
svn-id: r15609
|
|
svn-id: r15594
|
|
svn-id: r15532
|
|
svn-id: r15526
|
|
svn-id: r15473
|
|
svn-id: r15332
|
|
svn-id: r15297
|
|
svn-id: r15277
|
|
svn-id: r15193
|
|
They're generally the largest resources in the cache by far (though some
ANIMATION_FILE resources are about as big).
I still don't know how much benefit there is to resource caching, but some
of it is definitely needed, or the game won't work properly. Oh well, as
long as no one complains about the extra memory usage...
svn-id: r15079
|
|
sorted it to output the biggest memory blocks first.
svn-id: r15078
|
|
command, would close the global script variables and player object
resources, without reopening them again. This made them fair game for the
resource expiration mechanism. The player object is probably referenced
often enough to stay alive, but the variables died on me pretty quickly,
causing ScummVM to crash.
I've also added a "reslist" debug command to make this sort of things
easier to spot. By default it only lists resources with refCount > 0. Use
"reslist 0" to see all the cached resources as well.
svn-id: r14958
|
|
svn-id: r14951
|
|
new memory manager didn't have the concept of the NULL pointer. Now it
does.
If ScummVM ever crashed for you when using the phone early in the game,
this patch hopefully fixes that bug. (If it didn't crash for you, memory
block zero was still allocated, so 0 still decoded to a valid pointer.)
svn-id: r14937
|
|
svn-id: r14898
|
|
perhaps less clever than the old one I wrote, but should be much easier to
read. Besides, the old code had a small memory leak in it.
svn-id: r14897
|
|
svn-id: r14888
|
|
to fix, but it should work well enough for now.
In this rewrite of the music code, I removed the "save/restore music state"
function, since it just complicated things for a very small gain. It wasn't
in the original engine, and I added it just for the credits, so that the
previously playing music could be resumed afterwards. I might re-add it
later, but probably not.
svn-id: r14887
|
|
implement it - personally I don't see the need - they can get it from CVS.
svn-id: r14819
|
|
clusters. (No, that doesn't mean compressed music is support yet. This is
just a tiny little step closer.)
svn-id: r14794
|
|
problems. Perhaps this will fix it?
svn-id: r14762
|
|
class, so they are handled the same way as the compressed clusters.
The next step will be to migrate the music playback to use the same class,
which means the fade-in/out logic needs to be separated from the decoding.
Once this is done, adding support for compressed music should be a piece of
cake.
svn-id: r14740
|
|
sprites on exit. As far as I can tell, the only case when this makes any
difference is when there is text on screen when you quit ScummVM, so it's
not really a memory leak, but Valgrind will report it as one.
svn-id: r14738
|
|
speech. (Apparently it was just an accident that MP3 worked.)
Unfortunately I had to change the file format of the compressed files to
include both the compressed and uncompressed size, but since the tool to
create these files has only lived as an item in the patch tracker, no one
should have exptected it to be the final, working version, right? Right.
svn-id: r14698
|
|
The equally experimental compression tool is in patch #854561.
Support for compressed music will require some restructuring first.
svn-id: r14684
|
|
malloc() nowadays! (This only affected the "dummy" player.
svn-id: r14638
|
|
Allow object_labels config option in COMI
svn-id: r14408
|
|
this once. :-)
The parameters to drawLine() aren't clipped to the screen size, which meant
that it was accessing memory out of bounds when marking the screen as
dirty. The function now uses plotPoint(), which does the bounds checking
and screen dirtying for us. Apart from being a little easier to read, it
dirties only the parts of the screen the line actually passes through,
instead of a rectangle defined by the line's end points.
Since drawLine() is only used for debugging, I wouldn't consider this a
particularly serious bug.
Next change is that only the pixels inside the original parallax layer are
considered when creating the block surfaces. This may make the drawing
slightly more efficient, since fewer surfaces will be labelled as
transparent.
Plus some other minor cleanups.
svn-id: r14340
|
|
by accident, and could cause bad noises during music cross-fades.
This wasn't a problem in 0.6.0 since all music is sampled at 22050 Hz,
which is the most likely output sample rate for ScummVM, so the converter
didn't actually have to do anything. Now, however, the output sample rate
could be anything.
I've given the music streams one converter each. In BS1, which uses similar
music code, it was already necessary to do this since some of its music is
sampled at 11025 Hz.
svn-id: r14237
|
|
arbitrary many default search directories
svn-id: r14095
|
|
more getGameDataPath() calls
svn-id: r14090
|
|
svn-id: r14058
|
|
svn-id: r14057
|
|
svn-id: r13959
|
|
svn-id: r13956
|
|
yesterday.
svn-id: r13955
|
