Age | Commit message (Collapse) | Author |
|
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
|
|
svn-id: r16580
|
|
svn-id: r16397
|
|
svn-id: r13933
|
|
our other engines do this, so there is little reason for BS2 to. I did add
a filtering mechanism so that mouse button releases and scroll wheeling is
ignored during normal gameplay, but I don't know if that was necessary
either.
Since this left little more than an empty husk where the Input class used
to be, I've eliminated that class and buried its remains in Sword2Engine.
svn-id: r13812
|
|
resource manager. All new code! All new bugs!
svn-id: r13603
|
|
svn-id: r12181
|
|
svn-id: r12141
|
|
and it now fades both up and down.
Plenty of cleanups, simplifications and just moving code around to group it
in what I hope is a more logical fashion.
Fixed a long-standing bug where spot effects would eventually use up all
available sound effect handles. (I may have introduced this when I removed
the expiration of sound effects from FxServer().)
svn-id: r12108
|
|
"StandardHeader" instead of "_standardHeader".
svn-id: r11997
|
|
few other hitherto harmless bugs, which I've hopefully managed to fix.)
svn-id: r11762
|
|
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
|
|
svn-id: r11363
|
|
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: r11266
|
|
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
|
|
svn-id: r11212
|
|
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: r10659
|
|
and made some other minor cleanups.
svn-id: r10614
|
|
Moved some stuff out of driver96.h. Eventually I'd like to get rid of this
file completely. Or at the very least most of it.
svn-id: r10589
|
|
headers. Most (all?) of the ones we need should probably come from stdafx.h
instead.
svn-id: r10588
|
|
svn-id: r10581
|
|
whatever you prefer to call it) the GCC_PACK problem in Doxygen
svn-id: r10569
|
|
svn-id: r10544
|
|
svn-id: r10484
|
|
play that music for cutscenes that have subtitles.
svn-id: r10460
|
|
individual files, into what I hope are doxygen ones.
svn-id: r10431
|
|
svn-id: r10427
|
|
svn-id: r10391
|
|
cluttering up the files anyway. (Though I do feel a slight twinge of guilt
for removing historical records like this. :-)
svn-id: r10384
|
|
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
|
|
svn-id: r10368
|
|
the time to do much testing yet, but it seems to work for me.
svn-id: r10361
|
|
svn-id: r10308
|
|
barebone ScummVM (or maybe I just want to increase our CVS stats? <g>)
svn-id: r10287
|
|
svn-id: r10277
|
|
svn-id: r10236
|
|
svn-id: r10234
|
|
svn-id: r10204
|
|
througout the code.
svn-id: r10127
|
|
load). The new code is smaller, hopefully a bit easier to read and doesn't
use up all the CPU time.
Of course, it may some new and exciting bugs too. ;-)
svn-id: r10079
|
|
init sound data to class sound
svn-id: r9980
|
|
fine but you don't hear anything) newStream, and appendStream doesn't work but playRaw works for music
svn-id: r9923
|
|
block surfaces. (A block surface is a 64x64 tile of a parallax layer.)
I've also done a few things to try and optimize the drawing:
* The back buffer is no longer cleared between frames. This may cause
regressions, but I do believe that the entire picture area is always
completely re-rendered for each frame.
As a result of this, the menu code is now responsible for clearing the
icon areas itself.
* A few unnecessary copy_rect() calls were commented out in favor of one
big copy_rect() in ServiceWindows().
* Completely opaque block surfaces are copied with memcpy(), one line at a
time.
Unless we manage to add intelligent screen redrawing, I don't think it will
get that much faster than this, though there is some unnecessary data
copying in DrawSprite() that could be removed.
And the game is still a terrible CPU hog. I believe the animation runs at
approximately 12 fps. If there's still time left, it will pump out further
frames to get smooth scrolling. We ought to put a cap on that, and if it
has already reached the scroll target it should sleep for the rest of the
render cycle.
svn-id: r9886
|