I'm making a a top down car game (how original huh?) to teach myself some Java and game programming.. it's going ok so far (in fact, I've already made a lot more I ever thought I could pull off) but I'm now facing my biggest problem so far: collision detection.

I'm trying to use an Area made from the bounds of my car sprite, rotate it the same way as my sprite and move them together and then I would use the Area to check for collisions. My problem I guess is that I don't really understand affine transformations, I originally just rotated the Image holding my sprite but as I started to realize I might have to go for Areas to get the collision detection working, I switched into using an AffineTransform to rotate my car.

I got it rotating the sprite correctly into the correct coordinates by trial and error but for some reason it's not working for the Area - the Area rotates but the coordinates are no where near the car itself.

Here's the code for my car's draw method, I put the area code there as I'm already messing around with affinetransformations. If you forget about all the Area stuff, it works the way it should (i.e. it rotates the car correctly and draws it to the correct location). But the area gets drawn in funny places.. the fact that I don't understand my affine transformation code aside, I further don't understand why it works for the sprite but not for the area..

Could you clarify what you mean by "funny places"? Is there some sort of pattern to where the area is drawn (such as always offset by x or rotated around y). Finding where the area is incorrectly being offset should help you to debug.

Hmm - what's the getBounds() call return? I think maybe you're pre-translating the bounds, resulting in them getting moved twice (once in getBounds(), once by the transform).

"translate" just means "move to location". So you can think of your affine transform as doing this, in order:1) move to location2) rotate <some amount of radians> around anchor point (anchor point being relative to location that was moved to).

For it to work correctly on the bounds, the bounds need to be defined relative to the origin.

Hm yes it's something to that effect - commenting out the translate line, the area is initially drawn in the correct place (the sprite however is not) and it moves correctly for as long as I don't rotate, but rotating makes it go haywire.

So, I guess easiest/best would be to separate the sprite and area transformations and figure out the correct translation / rotation for the area so that it behaves correctly..?

Then to figure out what's going wrong with the rotation. The getbounds as far as I can tell returns a rectangle with the x and y coordinates (on the whole "play area") of the sprite's top left corner pixel, and it's width and height in pixels.

next up, use it for collision detection (hm I'm going to want to detect in what angle and what point the collisions happens as well), and when that's done my next bigger goal I think would be a scrolling game world. Having fun so far

Your problem with your earlier code was that your Area was already translated! You were translating it a second time with the AffineTransform. You can still use the same AffineTransform for the car and Area if you set your area to (0,0,width,height) and transforming it with "atCar".

You *might* run into trouble down the line if your rendering gets out of sync with the collision area (say, you update one but not the other - an example might be if you decide that different cars have a different center, and only update the render). Probably not worth worrying about now though.

Main thing is to understand exactly what both those methods are doing and why

Yeah, that crossed my mind too when I realized I now have these hard coded values in two separate places in the code - I shrugged it off with "I'll just make two more integer variables representing the rotation point for the car and these methods can then use those variables", I'll just have to remember to actually do it (takes like 2 minutes but I didn't get around to it yet)

Aw no, it was kind of meant as a reply to you - I already separated the two, as I want the area "detection" (for a lack of a better word) to be separate from the drawing anyway. I guess I could create the AT elsewhere and use it in both of the methods though, would at least save me one very frequently used "new AT" call bu I don't think efficiency will play too big of a role in a game like this (although I have big plans and a vivid imagination but I'm sure my programming skills will be a huge bottleneck in what I can actually do)

Right on, thanks. Seems the result of clone() needs to be cast as an Area (returned Object otherwise) but otherwise it works just like that, small modifications and it's another method for my car class:

It makes sense to do a quick bounding circle or bounding box check(*) before intersecting Areas if you're checking for collisions between lots of entities. But either way, if it works and it doesn't show up as significant in the profiler, why worry about it?

It makes sense to do a quick bounding circle or bounding box check(*) before intersecting Areas if you're checking for collisions between lots of entities. But either way, if it works and it doesn't show up as significant in the profiler, why worry about it?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org