Slick Forums

The circle class has a very odd interface, that uses the center point for position when calling the constructor, but then uses, for all purposes, the top left corner of the bounding box as coordinates. Thus, if you call the constructor using Circle c = new Circle(x,y,r) and then call c.getX(), you'll actually get x-r back.

I'd like this to be changed, or perhaps (even better) extra functionality to handle both points (setCenterX, getCenterX, etc).

I also noticed recently that the points generation stuff (used for rendering circles and collision of arbitrary polygon) essentially makes circles impossible to use for collision - since every time you move the circle (to coincide with the entity thats moving) all the points are regenerated. It's the first time I've seen a GC performance in 3 years.

Kev

I personally would love to see the old geom back, possibly in a separate package. These "BoundingShapes" (or whatever they should be called) would be very lightweight and non-renderable. They'd really only be used for collision checking. But it would definitely create some conflicts with the current geom package...

Just my two cents...

The points aren't used for collision checking. They are only used for rendering. The old Circle collision checking code is still there. Circle on Circle and Rectangle on Circle are still streamlined for collisions checking. But those classes on any of the newer ones will do more complex collision checking. The reason the points are regenerated every time is because it was requested in this thread: http://slick.javaunlimited.net/viewtopic.php?t=462

I am not sure what you want to do about this. The main reason for this way of doing things is the Transform class. If you want to remove complex transformations and implement simple scale, rotate and translate into the shape classes, it might make things more manageable.

Yeah, the points regeneration on move is the overhead for me. I like what we have atm, it's increadibly flexible - I'm also not sure how to fix this. Let it soake for a bit and we can work something out I'm sure

Kev

Personally, I've little need for complex transformations at the moment, but I suppose it's good to have it in there. In either case, the coordinate handling is still not uniform, and in my opinion is the more important issue here

Updated to resolve this, in next build:

- Left complex transforms as is
- Added special case code to morph the points array when setX() or setY() is called (just adjust based on the change)
- Added getCentreX() getCentreY() to the circle

Kev