| Age | Commit message (Collapse) | Author |
|---|
|
GameSettings::gameName to name; added temporary experimental MD5 hack
svn-id: r11603
|
|
svn-id: r11581
|
|
previous commit.
svn-id: r11551
|
|
aligned, never flipped and never RLE16-compressed. Simplified the code
accordingly. (Displaying the restore dialog when specifying an unused save
slot from the command-line works again now.)
Plus some minor cleanups.
svn-id: r11550
|
|
e.g. it's 'C' or 'c' to display the credits, not some random function key.
svn-id: r11549
|
|
files with a primitive and incomplete tool to present resource information.
(It may evolve into something useful and/or presentable later. Much later.)
I've found no evidence whatsoever that the mysterious blend & 0x02 case is
ever used. Since the code makes no sense to me, I've removed it.
svn-id: r11538
|
|
svn-id: r11528
|
|
To match original version and other games.
svn-id: r11479
|
|
"nosubtitles", let's change this one as well. Of course, it does break
compatibility with old config files, but I guess the worst that can happen
is that we have an unused "nosubtitles" line in addition to the used
"subtitles" line...
svn-id: r11464
|
|
svn-id: r11457
|
|
game engines.
svn-id: r11447
|
|
console a bit earlier so that error messages about missing files will be
more obvious to the user. (If an error happens that early, some of the
debugger commands will cause ScummVM to crash. I might look into that
later.)
svn-id: r11443
|
|
the dreaded Pyramid Bug.
svn-id: r11427
|
|
svn-id: r11384
|
|
experimental resource dumping code.
svn-id: r11382
|
|
svn-id: r11366
|
|
understand the idea was to allow moving objects to take up space in the
scene, thus forcing actors to move around them, or something like that.
However, the number of extra bars/nodes was always zero.
svn-id: r11365
|
|
svn-id: r11364
|
|
svn-id: r11363
|
|
number of parameters to a function would be useful for debugging, but that
information is already available in the script data itself.
svn-id: r11360
|
|
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
|
|
still uses it are the engine's global variables which, on the other hand,
are used *everywhere*.
I'll have to think some more about those. I guess I should take a closer
look at how the other engines handle them. (That goes for a lot of things
by the way.)
svn-id: r11349
|
|
svn-id: r11343
|
|
menu, and wasn't even necessary there so I've removed it. That means the
tony_gsdk.cpp file is no longer necessary. Sorry Tony, but at least you
still have your own debugger command! ;-)
svn-id: r11342
|
|
svn-id: r11318
|
|
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
|
|
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
|
