One of the changes, I'm not quite sure about: buildDisplay() used to open
and close the _thisScreen.background_layer_id resource for each layer it
processed. In particular, it used to "release the screen resource before
cacheing the sprites".
I have no idea why, because I can't see any trace of a sprite cache, and I
can't think of any harm in keeping the resource open during the whole
render cycle. The resource is probably loaded into memory already anyway,
though its reference counter may be 0.
svn-id: r13401
it's Logic::_scriptVars[ID] instead of just ID. Apart from looking cool, it
makes it much easier to tell the difference between variables and constants
when looking at the code.
Of course, this sort of sweeping changes is jolly good for introducing
truly weird regressions, which is why I waited until after 0.6.0.
svn-id: r13331
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
etc. to the different opcodes. Until now it has done so by casting the
pointer to an int32 (opcode parameters are represented as arrays of int32)
and then the opcode function casts it back to whatever pointer it needs.
At least in C there is no guarantee that a pointer can be represented as an
integer type (though apparently C99 may define such a type), so this has
struck me as unsafe ever since I first noticed it.
However, since all such pointers appear to point to the memory block owned
by the memory manager, we can easily convert them to integers by treating
them as offsets into the memory block. So that's what I have done. I hope I
caught all the occurences in the opcode functions, or we're going to have
some pretty interesting regressions on our hands...
svn-id: r11241
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
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
touches a lot of the code, of course, and adds yet another global variable
(temporarily, I hope), but everything still seems to work.
Knock on wood.
svn-id: r10806
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
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
unnecessary stuff from our own Surface class. The former allows the in-game
dialogs to at least sort of work, and the latter gained me a few frames per
second, according to the built-in FPS counter.
svn-id: r9825
