Fixing a little logic bug

[MuriloMir]

I needed to subtract and later add a 1 because otherwise it would return wrong values. Suppose you have a rectangle starting at (0, 0) with size (15, 15), then .bottom and .right must be 14 rather than 15 cause its size is 15 pixels, starting at 0 it goes all the way to 14 and not to 15(the 0 also counts), hence the -1. And therefore its width will be returned 14 - 0 which is 14 and it should be 15 because the 0 also counts, hence the +1.

[adamdruppe]

The current behavior is actually compatible with the way the operating system apis work, so changing this struct would break a lot of drawing routines. On Windows, for example: https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-rectangle

"The rectangle that is drawn excludes the bottom and right edges."

The reason for this related to the mathematical concept of area of this rectangle. Let's think about the case of a 1x1 rectangle. width * height = area, so this should have an area of 1.

If its upper-left point was at (0,0), and its lower-right point was also at (0,0), while this might be able to fill out one pixel on a computer screen, mathematically, its area would be zero since this point is infinitely small, so it doesn't actually cover anything.

To get an area, the lower-right point must be different than the upper-left point. The stuff in between these points now comprises the area of the rectangle, so (0,0) to (1,1) gives us something to fill in.

But since computer pixels are not infinitely small, we can't light up that lower-right point without changing the visible area too much. Thus the bottom and right most pixels are excluded from drawing, while still being specified as end points in code for the math to work.

idk if I explained that well, does it make sense to you?

[MuriloMir]

Yeah, you explained it well, I was able to understand now. I would say they used the wrong logic though cause apparently they calculate area by doing (right - left) (bottom - top), they could change this formula to (right - left + 1) (bottom - top + 1). It is like the coordinates, instead of (0, 0) being the upper left I think it should be the lower left cause that would be compatible with the cartesian system used in math. But well, I am not the one who makes the rules, so I guess I will have to get used to those things I disagree with.

[adamdruppe]

Fun fact, on Windows bitmaps, it actually is lower left. But not on screen (hence the common statements that bitmaps are "upside down"). Mac's Cocoa api does too, and OpenGL can.

But the hardware memory did it top to bottom (following a CRT's electron gun) and the Windows and X11 apis mirrored that, necessary for efficiency back then. So now it is a bit split across OSes.

However, the area formula is older than computer hardware!

Anywho, I'm gonna go ahead and close this since no matter what we think about it, the systems aren't gonna change.

[MuriloMir]

Ahhh, now I fully understand it, you were right, it is because I was not aware of the fact that the final points were not included, I thought if that I told the computer to draw a line from (0, 0) all the way to (15, 15) it would fill all pixels including the one at (15, 15), but it doesn't, it only goes until (14, 14), it is like several other concepts in programming, when using a range in a loop(0 .. 15) it also only goes until 14, 15 is not included. Now it all makes sense, I was confuse because I was thinking that it would actually draw all the way up to (15, 15) and therefore it would be drawing 16 rather than 15 pixels.

[MuriloMir]

Thanks for the help, you seem to be have a very deep knowledge concerning technology and computers.