| Age | Commit message (Collapse) | Author |
|---|
|
svn-id: r20088
|
|
svn-id: r19465
|
|
svn-id: r19404
|
|
svn-id: r19400
|
|
statically allocated one. I hope I'm using it correctly.
svn-id: r19394
|
|
palette glitch that would only happen if the credits were allowed to run in
their entirety.
svn-id: r19371
|
|
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
|
|
more or less serious bugs here:
* The fnResetGlobals() function returned IR_CONT. Since it potentially
kills its own script resource, this can lead to illegal read accesses.
Not it returns IR_STOP instead. This was probably a bug in the original
interpreter as well, but it handled memory allocation quite differently
so it was probably never an issue.
* Since fnResetGlobals() forcibly closes resources, I've changed the
closeResource() function to silently ignore requests to close resources
where the data pointer is NULL. While it could signify an error, it isn't
necessarily so.
* Don't force the screen to fade up after the credits -- let the script do
it instead. This prevents it from fading up the wrong image.
svn-id: r19127
|
|
svn-id: r18604
|
|
that's how we write it in most other places.
svn-id: r18069
|
|
svn-id: r18037
|
|
svn-id: r17897
|
|
Screen. I've also added an unused "splash screen" function that displays
the image that used to be shown by CacheNewCluster() while copying a data
file from CD to hard disk. ScummVM doesn't do that, but it's a nice image
that I wish we could do something useful with, and it's easier to have the
code here for reference than having to dig through old revisions of the
resource manager.
svn-id: r17894
|
|
either very small or, in the case of driver96.h, a disorganized jumbles.
svn-id: r16952
|
|
classes: Screen and Mouse. Screen handles most of the drawing, except the
mouse cursor and in-game menus.
The old Graphics class is no more.
I've also fixed some "reverse stereo" regressions from the first part of
the restructuring.
I'm not sure what the next step will be, but hopefully it will be smaller
than this one was.
svn-id: r16812
|
|
In this first step, I have moved all opcode functions into functions.cpp,
instead of having them scattered all over the place.
To get things to compile again, I had to rewrite the overly complicated
sound effects handling. It's much simpler now.
The next step will be to move any non-trivial code out of the opcode
functions and into the appropriate object. This, I hope, will make it
easier to create well-separated objects, instead of the current mess.
I also want to tear down the artificial boundary between the main directory
and the "driver" directory. We already have a cross-platform layer; there's
no need to have yet another one. (Actually, the rewriting of the sound
effects code took one first step in this direction.)
At the final stage, I'd like to get rid of the "drivers" directory
completely, but I'll probably need some help with that if I want to
preserve the CVS history of the code.
Things will probably be a bit bumpy along the way, but I seem to have
reached a point of relative stability again, which is why I'm commiting
this now.
svn-id: r16668
|
|
svn-id: r16580
|
|
reduced this (total dependencies on system.h went down from 193 to 85 files)
svn-id: r16527
|
|
svn-id: r16397
|
|
svn-id: r15810
|
|
svn-id: r15332
|
|
yesterday.
svn-id: r13955
|
|
or presses a button. This is how displayMsg() was always used, so the only
difference is that the code to check for events is no longer outside the
function.
In the process, it turned out that removeMsg() was probably unnecessary so
I have removed it. May cause regressions, but we can deal with them later.
svn-id: r13953
|
|
found the old name misleading (there is only one array that stores the
palette in the engine, though it could be argued that it's a copy of the
one used by the backend), and removed some code that I'm almost certain was
never used. (I've added assert()s to trigger in the cases where it would
have been used.)
svn-id: r13949
|
|
cache after it's been closed. (Currently it always is, but ideally I'd like
for BS to work even if resource caching is disabled.)
svn-id: r13610
|
|
resource manager. All new code! All new bugs!
svn-id: r13603
|
|
svn-id: r13494
|
|
svn-id: r13405
|
|
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
|
|
svn-id: r12739
|
|
svn-id: r12181
|
|
some other cleanups. (This was a regression caused by the less stupid
screen updates implemented recently.)
svn-id: r12180
|
|
"StandardHeader" instead of "_standardHeader".
svn-id: r11997
|
|
experimental resource dumping code.
svn-id: r11382
|
|
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
|
|
svn-id: r11260
|
|
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
|
|
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
|
|
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: r11025
|
|
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
|
|
svn-id: r10923
|
