Age | Commit message (Collapse) | Author |
|
loop if ScummVM failed to find a file in the demo. (Now it should error out
instead, which is marginally preferable.)
svn-id: r11298
|
|
svn-id: r11290
|
|
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
|
|
svn-id: r11266
|
|
for which CD to look for: 0 (both CDs - not used?), 1, 2 and 3 (not used?)
svn-id: r11263
|
|
game expects to find the various cluster files. I plan to look into making
the game playable from CD, and this should help during the testing.
svn-id: r11262
|
|
svn-id: r11260
|
|
svn-id: r11259
|
|
renamed the Display class Graphics for no better reason than me liking the
phrase "sound and graphics" better than "sound and display".
svn-id: r11258
|
|
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
|
|
svn-id: r11239
|
|
svn-id: r11212
|
|
svn-id: r11210
|
|
svn-id: r11209
|
|
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
|
|
svn-id: r11177
|
|
svn-id: r11175
|
|
svn-id: r11156
|
|
svn-id: r11129
|
|
svn-id: r11128
|
|
svn-id: r11107
|
|
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: r11069
|
|
for the mouse stuff, but I need to think about that a bit more. I have a
feeling the code could be cleaned up a bit anyway...
svn-id: r11060
|
|
promise I will get rid of g_sword2 later.)
svn-id: r11057
|
|
events.cpp, so there could be regressions.
svn-id: r11053
|
|
svn-id: r11046
|
|
Widget::findWidget (preparing to add support for nested widgets, for the tab widget)
svn-id: r11045
|
|
function that creates the panning table. The difference is that you now
have to tell whether you want one for normal or reverse stereo, so you are
not dependent on the previous state of the table.
(I still think it may be possible to get rid of the panning table
completely, but that's for later cleanups.)
svn-id: r11027
|
|
svn-id: r11026
|
|
svn-id: r11025
|
|
svn-id: r11024
|
|
svn-id: r11014
|
|
file, plus some other cleanup. I don't know how the config manager decides
if/when to save the settings to file, but we can worry about that later.
svn-id: r11001
|
|
svn-id: r10997
|
|
svn-id: r10995
|
|
svn-id: r10990
|
|
svn-id: r10984
|
|
svn-id: r10982
|
|
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
|
|
svn-id: r10945
|
|
svn-id: r10939
|
|
svn-id: r10923
|
|
svn-id: r10907
|
|
svn-id: r10885
|
|
svn-id: r10882
|
|
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
|
|
svn-id: r10769
|
|
reevaluate this): 'target' is what is in your config file; 'game' is what a frontend provide. E.g. the scumm frontend provides the game 'monkeyvga', and my config file has target 'monkeyvga-ger' configured to use that game
svn-id: r10766
|
|
analogous to the SkyAutoRoute class.
svn-id: r10754
|