Take a look at this equation, please?

[Ricardo C]

Imagine a grid made up of 64-pixel wide squares. It's a 3D world, but z is always zero. The squares start at 0,0 and occupy only the +x/+y axes, no negative values are involved. There is a player standing on a random spot on the grid. I have a function that is in constant use by every square of the grid, in order to determine whether the player is on it or not. To do this, I'm using the following variables:

holder.x and holder.y, which will store the squares x and y coordinates.

my.x and my.y, which hold the square's coordinates

player.x and player.y, which hold the player's position

At the start of the function, I copy my.x and my.y's values to holder.x and holder.y. Then, I substract player.x from my.x and player.y from my.y. I compare the results with the original values stored in holder.x and holder.y. The formula I'm using is this:

if(my.x < holder.x)&&(my.x >= holderx-63)&&(my.y < holder.y)&&(my.y >= holder.y-63)
{
do stuff;
}

The idea is that if the above conditions are true, then the player is within the square's boundaries, and so the function may proceed.

The code compiles without errors, but the "stuff" isn't getting done, which makes me think I screwed up elsewhere in the code, but I wanted to ask as many people as possible to have a look at this, in case it's the formula that is wrong.

If anyone could help with this, I'd be most grateful. And I'll give you a free copy of the finished game :D

[Geom]

That sounds more complicated than necessary. Couldn't you just do

if (my.x <= player.x && player.x < my.x+64 && my.y <= player.y && player.y < my.y+64)
{
do stuff;
}

The first two conditions test if player.x is between the left & right edges of the square. The 2nd two conditions test if player.y is between the top & bottom edges of the square. No need for any other variables.

Geom

[Ricardo C]

Wow, do I feel stupid. Like, in need of "math for dummies" stupid.

Thanks so much for showing me the proper way :)

EDIT: I just tested it, and it worked! I think the needless complexity of my version led me to screw up the structuring of the function, and the vector that needed to be updated if the equation was true, was never altered. Your version worked like a charm. Not only do I want to send you a free copy once I'm done, I'd also like to add you to the credits, under a heading like "pretty much saved Ricardo's sanity" :D

Again, thanks!

[digriz]

I have a function that is in constant use by every square of the grid, in order to determine whether the player is on it or not.

Wouldn't it be better if you got the player code to notify the relevant square that it's currently occupied? It'd be quicker.

[EDIT]Oh and looking at the code you supplied, you're comparing the grid co-ordinates against each other, your code says :-

if(my.x < holder.x)&&(my.x >= holderx-63)&&(my.y < holder.y)&&(my.y >= holder.y-63)

my.x & holder.x are the same value and because you're saying (my.x < holder.x) the if statement would never be true.

I think if you replace the holder variable in the IF statement with the player variable...it would work.

But seeing as how the problems solved, i'll shut up now :D

[Nikster]

I agree with digriz, any reason you don't do x>>6 y>>6 and just call the needed function ? would save lots of wasteful comparisons. Unless of course there is a reason for it.

[Ricardo C]

The my.x and my.y in the equation are post-substraction. Holder represents the original values, because my.x and my.y have been changed by having player.x and player.y substracted from them.

I think the reasons why my version was so convoluted would make more sense if you could see it in context, but I already trashed it in favor of Geom's version, and I really don't wanna rebuild the Frankenstein's monster the original was :o

[hanford_lemoore]

I know you already solved it, but I noticed your second condition was missing a period (notice the bold text):

if(my.x < holder.x)&&(my.x >= holderx-63)&&(my.y < holder.y)&&(my.y >= holder.y-63)
{
do stuff;
}

Was that the problem?

[James C. Smith]

In the future, please try to make a title for your thread that is somewhat related of your question. Obviously you can’t fit the whole question into the title. But at least give me enough so that if I read your question, and tomorrow I see this thread again, I will be able to correlate the thread title with the discussion I read yesterday. Every tread in this forum could be name “Please help me with this question” or “Hey check this out”, and they wouldn’t be wrong, but they sure would be annoying.

[Ricardo C]

I orginally had "This code compiles without a hitch, but doesn't work" as a title, but I actually thought it was too vague. I thought "equation" was a good indication of the thread's contents, but obviously it could have been more so. Sorry for any confusion.

[James C. Smith]

my bad. I thought it said take a look at this question. I guess I should slow down and think before I speak.