Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


theJ89

Member Since 04 Sep 2006
Offline Last Active Jul 29 2011 04:12 PM

Posts I've Made

In Topic: AABB - Line Segment intersection test

15 July 2011 - 09:55 AM

I stumbled upon this ancient thread the other day looking for a solution to the same problem, and I've been reading through it and all the related materials that jyk had posted. It's been a great amount of help to me so far, but I'm having trouble understanding a few things.

Looking on Wikipedia's page for the Seperating Axis Theorem, it mentions that this is an intersection test for convex polygons, but doesn't that imply that the two shapes must contain at least 3 vertices each? A line segment would only contain two vertices; is the line segment being treated like a collapsed triangle?

Second, for the cross products I noticed you posted:
boxExtents.Dot(abs(axisi))

I understand that (for the purposes of finding the box "radius") you are making the axis vector's components all positive, but wouldn't this result in an axis pointed in a different direction in some cases? I figured that you would have to change the sign of the x/y/z/ values of the box extents vector depending on what octant the axis vector was located in to get the "radius", but by making the axis vector all positive, and keeping the box extents vector constant, you're acheiving the same result with less work?

Third, if this test was being performed in 2D (i.e. a 2D AABB and a 2D line segment) wouldn't you have to test the axis perpendicular to the line segment? Why does this not have to be done in 3D? Do the cross-products take the place of this test (since they're all perpendicular to the line segment)?

Fourth, can you give an example of a line segment and AABB that only the cross product tests could detect a non-collision on?

Thanks,
theJ89

PS: jyk, if you're still around, you might want to change the metanet tutorial link: http://www.metanetsoftware.com/technique/tutorialA.html

In Topic: Window using up 50% of my processor?

22 January 2007 - 12:54 PM

Thanks guys, I'll try them out and see what the results are.

Edit:
Doing sleep worked fine. Thanks for the help, guys!

[Edited by - theJ89 on January 22, 2007 8:54:32 PM]

In Topic: Help me with my application?

26 September 2006 - 02:52 PM

Oh! Yes, one last thing if you will. I am having trouble using diffusion to color my quads. For some reason, they become a jumble of red and black lines. For the time being, D3DFVF_DIFFUSE has been removed from the FVF. Do you know a possible solution for this?

In Topic: Help me with my application?

26 September 2006 - 11:44 AM

Quote:
Original post by Serapth
Keep in mind, alot of what im about to say is nitpicking. Just the little stuff you might not see or care about. First of, you really should consider using STL classes instead of fixed sized containers, you would make your code a whole lot easier.

Thanks for the reply. I am considering using Linked lists or vectors, which ever is faster.

Quote:
Original post by Serapth
That said, for the most part it all looks good. This is going to sound like an odd compliment, but your commenting style is very good. You actually write comments that might help you, as opposed to doing it "because your supposed to" or *shudder* not doing it at all.

Thank you, when I was working on a game project written in javascript (it was a scripted game created with HTML) I made sure that I commented each function specifically so that if someone else were to read it, it would help them out. I'm kind of being slack on this because I'm not taking it as seriously as I should be.

Quote:
Original post by Serapth
#defines are nasty evil. Switch them to const strings. This makes a night and day difference when debugging, and for other people working with your code.

I've been wondering why this is. From what I can tell #define just replaces all instances of the keyword with the given code when it's building the source files. I can see how this would considerably increase the size of the file if, say for example you defined a string and then used the keyword all over the file, thus creating the same string in several places in the file which would be un-necessary. From what I understand consts are just read-only memory. The reason I was using defines is that I didn't want to take up unnecessary memory for things that were not called very often.

Quote:
Original post by Serapth

*** Source Snippet Removed ***
Is a bug waiting to happen. In debug mode, the compiler zeros all memory, however in release it doesnt. If you dont implicity ZeroMemory() or memset() to 0 cImages array, this code could lead to a hard to find bug down the road. ( Another reason to use vectors [smile] )

Also, this is a matter of opinion, but move oIndex out of the for loop and replace it with a break statement. Its much easier to read and maintain:
*** Source Snippet Removed ***


I havent gotten to where cImages[index] was called ( Aka, the call to new Image() ), but if you newed the Image() this is a memory leak.

Image::~Image()
{
cImages[index]=NULL;
}

EDIT::: NOPE, not a memory leak, you statically declared every Image. Still leaving this comment in as an object lesson to others that might read this, or for yourself if you decide to go more dynamic in the future.

Actually, cImages is not used for dynamically allocating images in. It's used for keeping track of images in the program. Now that you mention it, I should use break. I don't use break very often. Plus, that's one less condition check I need to do in that loop.

Quote:
Original post by Serapth
Potential gotcha bug or exploit:
strcat(message, "Cannot load texture ");
strcat(message, pszImgPath);
strcat(message, " - No available slots.");
Alert(message);

If pszImgPath ends up being really long, you can have a buffer overflow here. Probrably not a big deal, but still worth checking the size of pszImgPath before copying to an memory buffer with a fixed sized limit ( 255 ). Youu repeat this behavour a few times.

Ahhh, yeah, I noticed this here! I couldn't come up with an acceptable solution so I just left it that way. With other languages I don't have to worry about buffer sizes so I don't really know a solution to it offhand.

Quote:
Original post by Serapth
Call me Mr Anti compound logic in an if statement guy, but I would break this into two tests. Keep in mind, the compiler compiles it down to the same code in the end:

if(cImages[i]!=NULL&&cImages[i]->show)

I figured it was just a matter of style. According to a book on C++ I read if the first condition is false none of the other conditions are even considered - but, the way you mentioned is usually the way I do it.

Quote:
Original post by Serapth
Finally:

Image MyImages[100]={
Image(0,0,32,32,dx3d.d3dTextures[0]),
Image(32,0,32,32,dx3d.d3dTextures[0]),
Image(64,0,32,32,dx3d.d3dTextures[0]),
Image(96,0,32,32,dx3d.d3dTextures[0]),
<snip><snip>

My god man, put that in a loop! ;) You could drop about 70+ lines of code easily there. Also, ill use this time once again to recommend vectors :)


Oh god I know. I was hoping to use a default constructer and then manually move them in a loop but then C++ threw the whole "you can't a default constructor with arguments" crap at me. Oh well.

Quote:
Original post by Serapth
for(int y = 0; y < 10; y ++)
{
for(int x = 0; x< 10; x++)
{
Image(x*32,y*32,32,32,dx3d.d3dTextures[0])
}
}

Only problem I can see here is that "Image" isn't stored in a variable. It needs to be, the only thing that cImages does is point to existing images.

Thanks for all of the help, I'll be working on my code to see if I can improve it.

In Topic: Help me with my application?

26 September 2006 - 10:27 AM

Quote:
Original post by Serapth
You will probrably get alot more responses if you post the code in with your posts instead of getting people to download it. Just paste it into [ source ] and [ / source] blocks in your post ( loose the spaces though ).

From your description, is there a reason you are using fixed sized arrays instead of Vectors? If not, without having read your code that would be my first suggestion. I will have more if you post the code in [smile]


Thank you for the reply! I'll post the code in source tags now.

I have been told Vectors are slow for fast access purposes, so I have been using arrays.

PARTNERS