On Sat, 28 Jul 2001, Christoph Reichenbach wrote:
> Hi,
>
> > The real real *real* problem seems to be that somewhere before
> > gfxwop_dyn_view_draw(), the cel passed goes wrong. The cel
> > parameter passed into this function contain different values after
> > a certain point, as indicated by the asteriks below:
> >
> > This makes no sense to me, I would assume that memory corruption is
> > happening somewheres? Here is some output from a print statement that
> > prints the loop and cel parameters at the copy protection scene in LSL2.
>
> The copy protection scene in LSL2 contains several semi-random cels and is
> inappropriate for testing this.
The data looked consistent to me -- what would you recommend for testing?
I chose LSL2 because it was easy to execute the same test case without
variance. (start LSL2, enter "9999", press enter, press enter.) I'll try
the KQ4 copy protection, but I don't think that exhibits any bugs in
fullscreen.
> Anyway, even if the cel was invalid, the gfx subsystem should fail
> gracefully. It shouldn't write over the border of the visual area either,
> since we're supposed to do clipping in the operational layer.
I agree. The end problem is that, in the crossblit_32 function,
priority_buffer is read beyond it's bounds because the loop is iterated
through too many times. That happens because yl is a larger value (for
some reason) in fullscreen mode.
I'll try some other games.
--
http://www.clock.org/~matt
