Hi there, I've been scratching my head over this a little and I thought someone might know the answer to this, my trigs a little rusty...

I want to know what the measurements would be (ie. how to calculate) a bounding rectangle around a rotated rectangle.

A pictures worth 1000 words....

http://www.angelfire.com/funky/feartheweasel/pics/Rotate.jpg

Thanks!

One way could be to rotate the 4 points of the rectangle, then get the min and max values of x and y, and then compute the bounding rectangle width and height.

I recommend the same approach. Find the corners of the rectangle to enclose and use the smallest XY values for the top-left corner of the bounding rectangle, and the largest XY values for the bottom-right corner.

However, I'm a little perplexed as to why you want to use a bounding rectangle instead of a bounding circle. A bounding circle is much easier to calculate. All it takes is a little Pythagorean Theorem magic.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Would this work?

size = MAX(w, h);
new_w = ABS(size * cos(a));
new_h = ABS(size * sin(a));

Better, for rectangles, is to take two points on one side, since you can mirror the others across the fulcrum. This should save you two sin/cos calls.

If the angles are whole numbers (integers), then these 'expensive' sin/cos calls could be turned into a lookup table (array).

Okay, but using two out of four points still saves you 4 lookups

You can also multiply the values of the sin/cos in the table by 128, then just >>7 the number after multiplication. This saves on use of floating point math.

(note: I have been working with this stuff [rotation] for a couple months, so I have learned much )

Cheers, I've got it doing what I want now. I was mainly trying to cut down on calculating all four points and just doing two. In the meantime I also constructed some lookup tables. I shouldn't be worrying about speed to much, it's only really for previewing things accurately. (see below)

Cheers for this pointer Kikaru:

I was just thinking about doing something like this to help accuracy...

The reason I'm not using a bounding circle is that this is for a quick routine I wrote to draw a transparent rotated sprite in standard Allegro (only has trans_sprite OR rotate_sprite....). My game uses Openlayer (or Allegro if you want about half the framerate, wasn't hard to do both) but my Animation editor can only use Allegro because I use the Allegro GUI.

Here's a pic anyway if anyones interested. It's all based on 2d skeletal animation with interpolation between frames (can't see animation in a screenshot though...). Each bone supports it's own skin animations too (the flower bobs up and down in a happy way).

All the programming for the game is nearly done, just starting to draw graphics and make other game content now.

BTW I'm not sure what's up with the guy being a cactus, I just drew the skins quickly for testing...

http://www.angelfire.com/funky/feartheweasel/pics/GRIM_ScreenShots_3_2_2007.jpg

[off-topic]
Where can I download GRIM?

I like the cactus. You should make it a bonus special character.

Haha yeah, 'Bonus Character!' is what I thought too when I chucked the skin on the bones!

As for downloading I guess I could put the GRIM editor online. I don't imagine it would be much use for anyone other than having a look and a play but I don't mind. I'll start a thread in the proper place...

EDIT: Download available in this thread if anyones interested.

That's the kind of thing that I'm working on too.

Cool! I've wanted to do this for a while and had a brief tech demo going mid last year but never did anything more for 6 months. I completely rewrote the first attempt into a proper extendible structure and started the editor last week. If you want to compare notes or anything I don't mind at all! Something I've learnt might help you out or vice versa. How are you handling skin drawing order?

Matt.

Whatever the furthest is from the camera is drawn first. Use glDepthFunc(GL_LEQUAL) to draw things in order (like as if the bitmaps would do it).

Cool. I meant more in terms of structures, it was a bit of a problem I had originally because I use a linked list tree structure to hold all the bones with their lengths and relative angles to each other. I originally just drew the skins as the bone position was calculated when iterating through the tree but of course the order wasn't perfect all the time. In the end I made a seperate linear linked list of pointers to the bones which is the draw order, it makes it easy to change. Under the 'Bones' section in my editor is actually the list of all the bones where you can click and drag the order all around.

Screenshot:
{"name":"591141","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/1\/c14d25c3004e231b1d8b637b779353ab.jpg","w":541,"h":422,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/1\/c14d25c3004e231b1d8b637b779353ab"}

Since you said "bounding circle," I remembered a neat little trick for copying that:

//for collision at a known distance
if ((x_diff < d1)&&(y_diff < d1)&&(x_diff + y_diff < d2))
     hit = true;

This creates a "bounding octagon," which works a bit like a circle.

//for estimating distances
if (x_diff > y_diff)
     dist = (x_diff+x_diff+y_diff)>>2;
else
     dist = (x_diff+y_diff+y_diff)>>2;

this is a fairly accurate distance check, least accurate around 45^o or so. Best for checking "which is closer" than actual distances.