| Age | Commit message (Collapse) | Author |
|---|
|
svn-id: r20088
|
|
files marked as being on both CDs (I haven't seen any such file -- ever),
treat it as if it's on the hard disk.
Also, the "cd" field of the ResourceFile struct now holds 0, 1 or 2, not
the bit flags from the data file. (This last change is not in the 0.8
branch.)
svn-id: r19884
|
|
supposed to be reading data from. Maybe this will help track down the
mysterious missing speech problem reported on the forum.
svn-id: r19823
|
|
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
|
|
svn-id: r19142
|
|
svn-id: r18037
|
|
svn-id: r16859
|
|
"restore" other times.) The save/restore dialog now has two separate
classes, though they both inherit from the old combined class of course.
svn-id: r16848
|
|
index tables in memory instead of accessing them over and over again, which caused major slowdowns with cd accesses.
Also, the caching of datafiles depends on the memory usage now, not on the number of screens that the player entered in the meantime.
The old behaviour made the engine run out of memory on the PS2.
svn-id: r16843
|
|
svn-id: r16580
|
|
svn-id: r16397
|
|
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
|
|
resource manager. All new code! All new bugs!
svn-id: r13603
|
|
svn-id: r12181
|
|
"StandardHeader" instead of "_standardHeader".
svn-id: r11997
|
|
Added tentative workaround for the bug (a script bug, I think) that causes
the game to hang when examining the lift at the top of the pyramid.
And, of course, some misc. cleanup.
svn-id: r11359
|
|
over the past few weeks, except for g_sword2. (Of course, this doesn't
necessarily make the code any prettier, but we can work on that later.)
svn-id: r11309
|
|
If a cluster file isn't found the resource manager will first check if it's
one of the files that it expects to find on the hard disk. If so, it's
considered a fatal error.
Otherwise it will present the user with an "Insert CD1" or "Insert CD2"
message, just like the original did. Unlike the original, the user will
have to press a button or click the mouse to indicate when he's done. I
don't know if we even can detect the CD automatically in any portable way.
As far as I can see, we'll need at least two separate path settings for
this to actually work: one for the HD install directory, and one or two for
the CDs. The file that are supposed to be found on the HD are only on one
of the CDs, so the amount of CD swapping would probably be unbearable
otherwise.
As a consequence, I haven't actually tried running the game from CD yet.
By the way, the old caching code has been removed completely now. All it
did was to copy the cluster file to HD for faster access. ScummVM never did
that, but so far no one has complained.
svn-id: r11273
|
|
and removed some of the references to global variables.
At this point I believe everything in the main game engine has been moved
into classes - not necessarily the correct ones, but still... However,
there is some stuff in the driver directory that need to be taken care of
as well.
svn-id: r11207
|
|
Renamed the resource manager's open/close methods openResource() and
closeResource() to avoid confusion. (It was I who originally shortened
their names to open() and close(), but I've changed my mind now.)
Moved more stuff into Sword2Engine.
svn-id: r11088
|
|
svn-id: r10997
|
|
console from the SCUMM engine. I decided that would be easier than to clean
up the original console code.
Unfortunately there's a bunch of code that I just copied - a pretty lousy
form of code-reusal. It'd be nice if the console could be made part of the
Engine class, or something like that.
Most of the debug commands seem to be working. Some aren't relevant for
ScummVM, and some are a bit obscure so I'm not quite sure what they're
supposed to be doing.
svn-id: r10978
|
|
headers. Most (all?) of the ones we need should probably come from stdafx.h
instead.
svn-id: r10588
|
|
usage); renamed Sword2State to Sword2Engine
svn-id: r10583
|
|
svn-id: r10581
|
|
suggestion, but I prepared the patch long before reading the mail :-).
Also, the remaining parts of the control panel etc. have been moved into a
class of their own.
This is still work in progress. I'm well aware that some of the classes
aren't as well separated as they ought to be, and that using global
variables to keep track of the different classes probably isn't pretty.
svn-id: r10561
|
|
debugging levels). This needs further cleanups, but I believe I have
reached a stable point where I can commit it without too much anxiety.
svn-id: r10502
|
|
svn-id: r10499
|
|
but say who added what when. (No disrespect intended, but this information
means very little to us.)
svn-id: r10413
|
|
svn-id: r10194
|
|
svn-id: r10192
|
|
svn-id: r9211
|
