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
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
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
so that it gets properly redrawn. Only the debugging code uses these
drawing primitives, so it's no big deal, but it's still the right thing to
do.
svn-id: r13811
renders the entire screen every frame, but it tries to update (i.e. copy to
the backend) only the parts of the screen that actually changed. At least
approximately so.
svn-id: r12142
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
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
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
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
available, since they are separate from the Smacker files themselves.
Next step will be to play the voice-over sounds as well, and to make sure
subtitles settings etc. are taken into account (if they aren't already).
svn-id: r10099
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
already reached its scroll target. This keeps BS2 from using all available
CPU time all of the time.
It may still be that we need a mechanism for throttling the frame rate when
the scene is moving towards a scroll target, but my computer isn't really
fast enough to test that.
Two other bugs fixed in the process:
* I think the last frame of the render cycle was rendered, but not
displayed. If so, that should be fixed now.
* I discovered that there are cases where we do need to clear the screen
(e.g. at the "Meanwhile..." message when George has found out about the
Glease Gallery), so I've re-enabled the function and disabled it in the
render cycle.
svn-id: r9904
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
I don't know if I got it right - the result doesn't look that great to me -
but at least the infrastructure is there.
This, I think, marks the point where BS2 graphics is pretty much done. Some
functions haven't been unstubbed yet, but I believe they're used for
debugging and/or profiling. I'm not sure they're worth the trouble.
Of course, there is still testing and clean-ups to make. For instance, I'd
like DrawSprite() to use malloc() a bit less.
svn-id: r9879
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
unnecessary stuff from our own Surface class. The former allows the in-game
dialogs to at least sort of work, and the latter gained me a few frames per
second, according to the built-in FPS counter.
svn-id: r9825
under the shack), plus some other cleanups. The s->blend & 0x02 case looks
bogus to me, but I don't know where it's used and I can't see that the
original did it differently.
svn-id: r9819
