I’ve got some extremely general (user-defined) Polygons, and I want to test that they do not overlap. Is there a clever way to do this? I could crawl along each segment between polygon vertices, checking pixel by pixel whether the line is contained in another polygon, but it seems a bit inelegant. Can anyone point me to a smarter method?
Performance, incidentally, is not an issue here, since I’ll only be doing this at startup - my polygons are map sectors defined in a text file.
I’ve just done Gravity Battle (http://www.cokeandcode.com/grav) which does this. Essentially I created a java.awt.geom.Area from the Polygons and then called intersect(otherArea). If the resulting area .IsEmpty() then they don’t intersect.
Its nasty and slow but seems to be good enough 
It does even appear to do some bounding box type first pass checking even.
Kev
The intersects and isempty tests (and, in fact, most polygon stuff) are very fast in Java2D.
The creation of Area objects is very very slow in Java2D.
Java2D’s intersect( … ) method is broken and creates random 0.01 pixel by 100 pixel areas (or something like that) in random places a long way away from the intersected objects. Hence, isEmpty can and will give unexpected answers because of the broken intersect routine.
Depressing, but all three still the case on 1.4.2.
Is there a bug tracking this issue?
With example geometry that demonstrates the bug?
For simple polygon<->polygon intersections i’ve had no problems.
[quote]Is there a bug tracking this issue?
With example geometry that demonstrates the bug?
[/quote]
I don’t know - the most recetn time it bit me I haven’t had time to do more than verify it’s existence if you do rectangle/rectangle compositions (no funny polys :)). Although I think I’ve experienced it before, a year or more ago, so perhaps I checked/logged a bug back then.
IIRC it seems to be a rounding error - I posted about it on this forum, I think, not too long ago - when it’s rebuilding/building paths.
[quote]Its nasty and slow but seems to be good enough It does even appear to do some bounding box type first pass checking even.
[/quote]
If it’s “good enough” then how can it be slow?
Game programmers worry too much about producing “elite” code!
Its slow in that I suspect if I wrote a bespoke set of classes it could be faster. However, I’m far more keen to reuse existing packages.
Have you not seen any of the code I’ve written? 
I’m the last one to worry about elite performance code! ;D You must be thinking of the demo producers, elegant maintainable code is where its at :-*
Kev