Re: Proposed change, fundamental invariant

[Hans Ronne <hronne at pp dot sbbs dot se>]

>So the new rule would be to say that the coordinate system is
>effectively infinite in both directions, to require that conversion
>calculations be accurate throughout the coordinate system, and to
>require that callers do any of the in_area tests that may be necessary.
>I've experimented a bit with a partial change of this form, and
>there doesn't seem to be any bad effects yet.  (A practical
>consequence is that the "attempting to xform" errors go away,
>but of course that just means that the bug(s) responsible
>won't be so easily detected.).

I ran into the same problem a long time ago with the Mac code. I put a hack
in xform_cell_flat that bypasses this annoying error for "wide viewports"
(meaning Macs). What this hack does is to provide a safety margin of 8
cells around the area edge where the error is ignored. Maybe something
similar would be a good general solution? That way you would still catch
most garbage xforms since a random int is unlikely to fall within such a
margin.

>What about cylindrical areas?  I'm thinking about having the
>wrapping apply just to accessing area data, but am not sure
>about that yet - there are perennial bugs in the handling of
>cylindrical areas (and there seems not to be any other body of
>code/formulas for handling hexes on cylinders), and I would
>to adopt a representation that can make those problems go away...

The mac drawing code works fine with cylindrical areas now, though it took
some blod, sweat and tears to get there. Maybe some of that stuff, such as
the UNWRAP macros, could be generalized? Or at least reused in the tcltk
code.

Hans

P.S. The isometric stuff looks nice, but could we have the solid color
option back for those terrains that lack isometric images? Right now,
nothing is drawn in that case.

Hans Ronne

hronne@pp.sbbs.se