Hi,
On Sat, 28 Jul 2001, Matt wrote:
> On Sat, 28 Jul 2001, Matt wrote:
>
> > On Sat, 28 Jul 2001, Christoph Reichenbach wrote:
> > >
> > > > 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:
>
> > > 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.
OK, but then it's not a problem with an invalid cel (although this may be
an _additional_ problem- memory corruption should indeed not be discounted
here), but a problem with clipping failing. No matter what the cel, the
loop and the view and where the interpreter draws it, our clipping
functions are supposed to make sure nothing bad happens there.
> KQ4 logo screen exhibits same behaviour: the cel value between fullscreen
> and windowed mode is different:
Are the values consistant?
I'm not certain whether the sparkles on the KQ4 logo are started randomly
or in a pre-determined fashion, so I wouldn't bet my life (and debugging
resources) on this alone. Especially since may be much harder to find the
place where the cel goes wrong (which may be anywhere in the interpreted
scripts, for example) as opposed to the place where clipping fails (which
could happen only in gfx/operations.c, IIRC).
This is a situation where the on-screen debug console would be a nice
thing to have...
llap,
Christoph
