Menu
▾
▴
#1802 DIG: Graphics glitch when scrolling
The Dig, English DOS version
Latest ScummVM CVS snapshot
In the Dig, when you're at the power station beneath
the Nexus, if you send the repair drone too far to the
left there will be a glitch as the screen scrolls. See
the attached screenshot. See the attached screenshot.
One possible culprit is this line from akos.cpp:
if (v1.x < 0 || v1.x >= _outwidth)
In this case, _outwidth is 328. If I change it to
if (v1.x < 0 || v1.x >= _vm->_screenWidth)
it seems to work. But I'm not certain if this is the
correct fix.
Discussion
Screenshot of the glitch
Savegame at the power station
Logged In: YES
user_id=577918
Assigning to fingolfin since we've already discussed this
glitch on IRC.
Logged In: YES
user_id=12935
Very strange. The "pitch" in that room is 328, so _outwidth being 328
should be just fine. Hm
Anyway, if you change
virtscr[0].xstart = screenLeft;
in camera.cpp to
virtscr[0].xstart = _screenStartStrip * 8;
which effectively turns off smooth scrolling, things work fine again, too.
Put together, those two factlets make up for a very irritating total :-)
Logged In: YES
user_id=12935
OK, I understand it now, and your change was on the right
track. A proper fix is in CVS now.
Some explanation: Initially when I did the smooth-scrolling
code, I imagined that all "backend" drawing code (room,
objects, actors) would work just like now, only perform its
work on a slightly bigger (8pixel wider) canvas. Then to
achieve smooth scrolling, we blit only a portion of the
canvas to the screen. That's still how we do it for the room
background and objects; but for actors, I did things a bit
differently; they still draw on the 328 wide canvas, but the
origin is shifted to match the camera pos (or rather, to
match camera pos mod 8). Problem was, I did the clipping
wrong, neglecting to take that shift into account.
So my fix now is to clip against the visible screen width
(like erik suggested), just that I use the width of the
virtual screen instead of _screenWidth.
This should work since we currently do a full actor redraw
when we scroll. Though we might change it, to optimize
things a little -- if we went through with my original plan
of drawing actors on the "big canvas", too, then we wouldn't
have to redraw actors quite as often. (Note: this probably
requires us to somewhat rework the way the costume drawing
code is invoked).