GUI & 2D drawing rectangle
struct rect { ivec2 start, end; };
24%
struct rect { ivec2 pos, size; };
76%
Poll ended at .

@cancel More of an aside (I'm not recommending it at the API level) but one representation that's often forgotten is center and radius (half-extent) per axis. The center/radius representation of intervals is nice for overlap checking since an interval is just a 1-dimensional disk/ball. So for 2-dimensional rects:

abs(a.cx - b.cx) <= a.rx + b.rx && abs(a.cy - b.cy) <= a.ry + b.ry

Mentioned here, for example: https://fgiesen.wordpress.com/2011/10/16/checking-for-interval-overlap/

Checking for interval overlap

This’ll be a short post, based on a short exchange I recently had with a colleague at work (hey Per!). It’s about a few tricks for checking interval overlaps that aren’t as well-k…

The ryg blog
@cancel One slightly annoying thing is that you have to work in "half-units", e.g. the center of the interval [0..1] is at 1/2. So for integers/grids it's more of an internal representation than something you'd expose.
@pervognsen this might actually come in handy for me later! thanks
@cancel @pervognsen I was going to say exactly this, center and half_extents is good apart from that gotcha for pixel coords.
@skylark13 @pervognsen multiplying by 2 doesn't seem too bad

@cancel @pervognsen Each has their ideal use case...

pos, size and min, max are good if you're drawing pixels. Which one you like most largely depends if you prefer having -1 in some cases or +1 in others. min, max could be better because you never have to check for zero size (max = pos+size-1).

For bounds like in culling, center, half_extents is convenient.

@skylark13 @pervognsen hmm why do you have to add or subtract 1?

@cancel @pervognsen

min,max is inclusive
pos,size is exclusive

Let's take for example with integer pixel coords:
min=4
max=6

You would expect a loop over this interval to hit pixels 4,5,6
So it would be for(x=min; x<=max; ++x) {...}

That's equivalent to
pos=4
size=3 (there are 3 pixels in the interval)
And a loop would be for(x=pos; x<pos+size; ++x) {...}

So min=pos, max=pos+size-1
Or pos=min, size=max-min+1

Hope this explanation makes sense...

@skylark13 @pervognsen

i wouldn't expect that to hit pixel 6. i write my loops like,

for (x = min.x; x < max.x; x++) { ..}

@cancel @pervognsen max is max, not size... you're using it as if it were a size.

If you think just of the name, min is the first pixel you loop over, and max is the last one, inclusively. As an analogy, if I say I can pay a maximum of 50$ for something, and someone sells that thing for precisely 50$, then I can buy it, it doesn't have to be 49.99$

So if I say the min pixel is 4 and the max pixel is 6, then I expect to loop over 4,5,6. But yeah, I'm particular about terminology hehehe

@skylark13 @pervognsen I don't see why it has to be that way? max is the max value of the end of the rectangle, in this case, if you want to call it max. in my original toot i called it start,end.
@skylark13 @pervognsen it's not being treated as a size because it's not relative to the start position.

@cancel @pervognsen

You're treating it as exclusive. It's fine, as long as that's your convention. I thought my analogy with money was a good one. For me, the term max implies that it is inclusive.

@skylark13 @pervognsen is there an advantage to the inclusive convention? having to add or subtract 1 at various times seems troublesome

@cancel @pervognsen

Depends on the case, I don't use it everywhere but in some cases it's simpler. Processing tiles where you need the last tile of the previous interval for the next one, and don't want overlap, for example.

@skylark13 @cancel @pervognsen wouldn't you need to add 1 to prevent overlap with max being inclusive?
while with [start,end) you can use end as the start of the next tile and they would implicitly not overlap

@maliusarth @cancel @pervognsen yeah, you're right.

I realize I was being pedantic about terminology, which is not useful at all. You can use what you want as long as it's clear to you and you handle the boundary conditions. It's just different words...