In all but one case I can think of, PICO-8 specifies screen rectangles as X1,Y1-X2,Y2 (inclusive).

The case where it doesn't is clip(x,y,w,h).

This has always bugged me. But worse, I noticed recently that the virtual hardware registers for the clip rect are actually set up like the other API calls: X1,Y1-X2,Y2 (inclusive), which means the API is actually translating between the paradigms.

Now I realize clip() can't suddenly change to work the other way, but...

What if we had a new command next to it called clp(x1,y1,x2,y2) that worked the same as everything else, worked like the virtual hardware, returned the same values you'd get by peeking the virtual hardware registers, etc., and simply marked clip() as deprecated, much like mapdraw() is deprecated?

It would hardly be the only abbreviated API call, e.g. sgn().

What do you think, @zep?

Hmm I don't quite get what is the inconsistency that you mention. I mean the only other API that's related to rectangle is the function rect/rectfill right? so in that case I might as well say that the rect is actually the one that's inconsistent?

But anyway, let's imagine that your proposal got accepted and now we have clp and clip with clip is marked as deprecated soon. Not only clp is a less obvious name, it's really prone to human error as clp and clip both uses the same function signature. That's even messier than the current state.

IMHO, it's not really worth to actually deprecate an API for the sake of this issue (if it counts as an issue, that is). I mean why in python len is a function but the string join is a method of the delimiter string? Why not just add length as the iterable object property and be consistent? or maybe just simply make them all as function and put it in a string utility library just like golang? There are quite a lot more obvious "inconsistencies" across all platforms/languages even until now. These cases existence simply prove that it's too costly to justify the change.

@yukinotenshi

I'll admit that you're right that I overstated the case about other API calls. I'm not sure what else I could have been thinking of, but these are the ones that involve inclusive rectangular screen extents:

• rect()
• rectfill()
• oval()
• ovalfill()

There are other calls involving extents, but they're mostly to do with source sprite size, not screen extents.

Anyway, I was probably conflating these calls with my knowledge that the virtual hardware clip registers also use the x1,y1-x2,y2 format, even though the API doesn't.

It still seems odd that the virtual clip hardware doesn't match the clip API though. If nothing else, it means you can't easily mix peek/poke and api usage for special cases where you need performance.

By the way, PICO-8 is still pre-release. It's still reasonable to change things or deprecate them if warranted. Backwards compatibility is not currently guaranteed. Stuff has been deprecated as recently as 0.2.2, as I recall. Or maybe it was 0.2.1, I forget. On top of that, even the oldest deprecated function I'm aware of (mapdraw()) hasn't actually been removed. In general, @zep is pretty lenient, so it's unlikely anyone will be caught out.

As for the name, well, if clp() is too similar to clip(), then we could use scis() or scissor(). The clip rectangle on PICO-8 is really just a smart scissor rect anyway.

Afterthought: Could also have a vp() that sets both the clip rect and the camera offset for a viewport, but that's getting a bit too deep. I'll just write my own. ;)