Log In  

The fifth parameter of clip() controls whether to make the previous clip smaller, or replace it. For instance...

clip(16, 16, 16, 16) -- small box in upper left
clip(64, 64, 32, 16) -- wide box in middle-ish
rectfill(0, 0, 127, 127, 12) -- fill clipped region with blue

This only fills the second region, since the first one was replaced with the second. But if I put true as the fifth parameter, like this:

clip(16, 16, 16, 16, true)
clip(64, 64, 32, 16, true)
rectfill(0, 0, 127, 127, 12)

This draws nothing, since the second clip didn't intersect with the first, and therefore canceled it out. So my question is, can I add on to the clipped region rather than subtracting from it or replacing it? Like maybe...

clip(16, 16, 16, 16, "add")
clip(64, 64, 32, 16, "add")
rectfill(0, 0, 127, 127, 12) -- fill both regions with blue

If there isn't an equivalent of this already, then this is a suggestion. True and false could still be accepted as arguments for backwards compatibility, but additionally, "replace", "intersect", and "add" could be accepted. Possibly 0, 1, and 2 also.

@zep, you better add this, OR ELSE.

P#120400 2022-11-09 22:04 ( Edited 2022-11-11 17:15)

Well then you could add clips down to the pixel, which would mean a bitmap mask under the hood. That would open a bunch of new possibilities if you could set its address in user mem... (though you can already do this with the palette and draw tricks, in eight colors)

P#120443 2022-11-10 11:25

Edited to make suggestion more clear.

P#120485 2022-11-11 17:16

Hi @ooooggll and @ultrabrite.

I had to really think about this for a moment. Here is multiclip() done through coding.

Cart #multiclip-0 | 2022-11-11 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

I can make a much smaller one via @ultrabrite's superb suggestion, but it may not be very fast.

P#120499 2022-11-11 20:20

Here is the one I think @ultrabrite had in mind, making use of pixels - as fast I can get them.

Cart #multiclip2-0 | 2022-11-11 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

While the first one I wrote uses 62% of the CPU, this one uses 92% - however the code as far simpler to understand.

I think this once again points to - Pico-8 can run faster. If we can have billions of polygons for a game like Resident Evil Revelations I was playing last night, surely we can have the almighty maximum speed for Pico-8.

I realize it's a fantasy console but do we REALLY want it to run slow just to get that nostalgic feeling ?

@zep, please pull out the stop. Let Pico-8 run billions of frames per second. Obviously limit visual output to 30- or 60fps, but something like reading and writing every pixel on the screen should be able to be done in millionths of a second. Or calculating a move for chess. There should be no instance where Pico-8 is EVER slow is what I'm getting at ...

P#120502 2022-11-11 21:22 ( Edited 2022-11-12 01:06)

[Please log in to post a comment]