But why?

[Rainbow]

scarfyPos.x = windowwidth/2 - scarfyRec.width/2; centres the image to the middle of the screen… why? Is this just maths? How could I know that halving the width of scarfyRec would move the x in just so such a way that places the rest of the image in the centre. Seems to me that the x wouldn’t move at all and i’ve just cut the image width in half. Making a shape smaller doesn’t mean every corner (especially in this case the top left corner) moves… obviously it does in this… but why?

I don’t want just an answer, I want to know why the answer is that way (No point telling me the destination without the way to get to it).

Also: Why isn’t this ground check a double dip?

If I have already declared that scarfyPos.y = windowheight - scarfyRec.height; then when ground checking if (scarfyPos.y >= windowheight - scarfyRec.height) hasn’t scarfyPos.y already once before had its windowheight reduced by scarfyRec.height. Why is this not causing something unintended.

[BH67]

@Rainbow

Seems to me that the x wouldn’t move at all and i’ve just cut the image width in half.

You’re actually not changing windowwidth or scarfyRec.width at all here; both of those are just numbers being plugged into an equation, the result of which is being assigned to scarfyPos.x. That X is the only thing you’re changing.

As an example, suppose your screen is 500px wide and your Rec is 40px wide. If you want to center the Rec to that screen, you would start with this:

• Set X equal to half the screen width
• To substitute in: X = 500/2

But there’s a problem: the Rec is a little off-center. That’s because the position of the Rec as a whole is represented by the position of one corner pixel (not the Rec’s middle. And I’ll refer to that as ‘middle’ just to avoid confusion). The above formula would work if the position pixel was in the Rec’s middle, but it’s not; it’s on the left, and therefore, the Rec is too far to the right because you’ve dragged that left position pixel all the way to the center.

The extra offset you have at this stage runs from the Rec’s left border to the Rec’s middle, so if you want to reverse that, you need a way to represent it mathematically. [Rec left border to Rec middle] is exactly equal to [Rec middle to Rec right border], and together, they form the Rec width. We know exactly what the Rec width is because you’ve already got a variable representing it, so by dividing that in half, you’ve got your offset. Accounted for like this:

• Set X equal to half the screen width, minus half the Rec width because we went too far
• To substitute in: X = (500/2) - (40/2), = 250 - 20, = 230. You can even test this yourself really quick-and-dirty using something like MS Paint.

Your question about the ground checking will likely also be answered by understanding the above logic, as the situation is really similar =)

[Tuomo_T]

Couldn’t have said it better myself!

[Rainbow]

Aha, thank you for this rather elaborate answer; I’ll have to look your response over once again while I look at the code to cement this in my head. But this makes sense now, tank you again.