Re: [cc65] TGI preview

From: Ullrich von Bassewitz <>
Date: 2009-11-20 01:40:07
On Thu, Nov 19, 2009 at 03:12:38PM -0800, Fatih Ayg√ľn wrote:
> > Now the question is how to handle this stuff. Having the line clipper hang is
> > ugly, but handling (or checking for) integer overflows withing the line
> > clipper eats memory and performance. Any votes?
> Can the clipper cope with small negative values?

Yes, that's no problem. It does signed 16 bit arithmetic, with a 32 bit
intermediate result when multiplying, so even coordinates far outside the
visible screen should be ok. The problematic code was:

    tgi_outtextxy ((XRes - tgi_textwidth (Text)) / 2, Y, Text);

XRes and the result of tgi_textwidth() were both unsigneds, but the latter
larger than the former, so the result of the subtraction was negative.
Dividing by two was done for unsigned, not for signed and so the result was
something like 0x7FD8. This caused an integer overflow in the clipping code,
because even a small increment made the value negative. Casting to int before
the divide makes the code work.

> If so, I'd vote for faster & smaller code.

Ok. Vote taken:-)

> What's the maximum resolution for tgi targets anyway? If documented
> properly, tgi_line being unable to cope with coords larger than say,
> 1024 shouldn't hurt anybody.

The limits cannot be given as definite values, because a formula like

  tgi_clip_y1 += (tgi_xmax - tgi_clip_x1) * tgi_clip_dy / tgi_clip_dx

is calculated. So larger X values are acceptable if the Y values are small and
vice versa. But possible coordinates are definitely much larger than +/- 2^10.
My estimate is that anything up to 2^14 is safe. In my case I had generated a
value near 2^15 because of the error.

What I don't like is the idea that the routine just hangs for these values.



Ullrich von Bassewitz                        
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Nov 20 01:40:13 2009

This archive was generated by hypermail 2.1.8 : 2009-11-20 01:40:15 CET