Age | Commit message (Collapse) | Author |
|
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: r10939
|
|
svn-id: r10923
|
|
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
|
|
global variable which will hopefully be dealt with later.)
svn-id: r10734
|
|
svn-id: r10728
|
|
svn-id: r10720
|
|
be changed, but it seems to work well enough to put it into CVS
svn-id: r10687
|
|
and made some other minor cleanups.
svn-id: r10614
|
|
the main code (maybe putting this into the Engine constructor would be better, though?)
svn-id: r10611
|
|
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
|
|
svn-id: r10496
|
|
play that music for cutscenes that have subtitles.
svn-id: r10460
|
|
detection when the game is either a) on CD b) in a bunch of seperate directories in a structure like that of the CD. Of course pointing ScummVM at such things with the normal target via command line or config file work fine. As everyone awake at the moment only has the sold out version, this is specific to that. I don't know what files are at the root of the original CD we can use for detection purposes
svn-id: r10423
|
|
message functions with our own.
We still need to go through them and assign sensible debug levels to them.
svn-id: r10422
|
|
but say who added what when. (No disrespect intended, but this information
means very little to us.)
svn-id: r10413
|
|
svn-id: r10391
|
|
svn-id: r10383
|
|
make screenshots.)
svn-id: r10382
|
|
characters. Hopefully this will make things work smoother on the Mac, but I
have no way of testing that.
svn-id: r10376
|
|
make the 'C' key run the credits. I haven't yet implemented the credits
function, but it does play the music at least.
svn-id: r10366
|
|
and we want them to go all the way up to eleven.
svn-id: r10362
|
|
This pretty much concludes the first stage of the engine cleanup. All of
the files, except for console/debugging stuff and possibly some header
files, have been changed to use the ScummVM brace style.
As for the console, that one could probably do with some rewriting, in
which case cleaning it up first would just be unnecessary work.
The next stages of the cleanup should include renaming of variables and
functions to follow the ScummVM coding standards, and turning everything
into C++ classes. And so on.
Of course, the driver directory should go through a similar cleanup as
well.
This has all been enormously tedious, so don't count on me doing any of
these things at the moment. Particularly not turning everything into C++
classes. I'm really not that familiar with C++. :-)
svn-id: r10340
|
|
modules; right now only work on OS X; once we add more build rules, other systems with dlopen() should work, too (e.g. Linux); Windows support may come later. This is still very much WIP
svn-id: r10304
|
|
(this removes the need for an ugly hack in the build system, and is also conceptionally cleaner)
svn-id: r10282
|
|
simplify some code; added a global g_sound pointer in bs2, this cuts down on uses of g_sword2 (of course both should be removed on the long run); some other minor tweaks/fixes
svn-id: r10278
|
|
svn-id: r10256
|
|
svn-id: r10255
|
|
if we have the focus, so there's no need to check.
svn-id: r10130
|
|
members; added GameDetector::findTarget; made launcher use that new method; some initial preparations for Plugin code
svn-id: r10092
|
|
warning messages about uninitialised sound handles.
svn-id: r9972
|
|
svn-id: r9932
|
|
fine but you don't hear anything) newStream, and appendStream doesn't work but playRaw works for music
svn-id: r9923
|
|
svn-id: r9903
|
|
do for the other game engines.
svn-id: r9880
|
|
sprites are drawn, but I think that's how it should be.
1: No bells or whistles.
2: This setting adds sprite blending, e.g. the smoke at the docks or the
display cases at the Glease Gallery.
3: This setting adds light map support, e.g. when walking under the shack
at the docks.
4: This setting adds better scaling algorithms.
The first three settings should work fine now. In fact, the third setting
is what we used to implement. The fourth setting still needs work and
testing. I've added code for downscaling case, but frankly I'm not
convinced the result is any better than with the simpler scaler. I usually
can't even tell the difference.
Of course, my translation of the original code could very well be buggy.
svn-id: r9867
|
|
for the making it a timer handler. This should eliminate the occasional
glitches I've been seeing with fades not being completed.
I'm also hoping that it will fix the problem where the game would sometimes
hang when moving between rooms. I know that at least once when I had that
happen to me the game was busy-waiting for the palette to fade.
At the very least, it's one place less to worry about thread-safety in.
svn-id: r9854
|
|
than telling it to load a slot as it validates the saves and doesn't try to load a non existent save etc, its also similiar to what the original did (any command line params at all would load the restore menu)
svn-id: r9843
|
|
svn-id: r9828
|
|
svn-id: r9822
|