Note: @zep, please have patience reading this, as I think there's more than one thing going on here.

I had to fix @Reload's "Pico-Sprint" cart here.

For whatever reason, they were choosing to make empty-arg func() calls as func"", possibly in an obsolete attempt to save a token.

The problem is, the call to clip"" screwed up the clip rectangle, because apparently clip() is interpreting the single blank string argument instead of ignoring it. I'm not sure if that qualifies as a bug, since Lua and PICO-8 expect strings to be coerced into numbers in many instances, so it may just be expected behavior that wasn't previously working as expected. I checked to see if maybe the single-argument format was meant to work with a table, e.g. clip{0,0,128,128}, but that did not seem to work.

However, there's more... ← and here begins the second thing

In the process of debugging this, I tried getting the existing clip rectangle from clip()'s return value. I tried these:

x,y,w,h = clip""
x,y,w,h = clip()
x,y,w,h = clip(0,0,128,128)

In each case, only 'x' received a value. On examination, it seemed to be all four x,y,w,h values encoded into one 32-bit value: 0xhhww.yyxx. This is at least valid in a way, but it made me wonder if that's why clip() is now accepting a single argument: is it possible to pass a value like that back into clip to set the rectangle with a single value?

Well, no, it isn't, at least not in the version I have.

So, is this an incomplete feature? Should clip() be returning a 4-tuple or the single value? Or maybe a 4-tuple if called with 4 args, and a single all-in-one value if called with one arg? But then which type should no args return? Right now it always just returns the single all-in-one value.

Personally I expected it to be a 4-tuple, and I suspect most people would. That would also make it much easier to manipulate the resulting values. Anyone using the all-in-one value might as well just poke4 or peek4/$ the corresponding memory registers directly.

TL;DR:

Report #1: clip("") does something, possibly the equivalent of clip(0,0,0,0). This may or may not be expected behavior for a single improper argument.

Report #2: clip() returns an encoded tuple in one value instead of a proper lua tuple, which while useful, cannot be fed back into clip().

Thanks -- fixed in 0.2.0d

I was worried about pushing too many things onto the call stack for what can be a high-frequency function, but of course there's no difference in the resulting bytecode when the ret values aren't actually assigned to something. So I scrapped the encoded single number, and clip() now returns 4 values (consistent w/ other draw functions). Also, good point about just using a peek4 if needed.