The fifth parameter of clip() controls whether to make the previous clip smaller, or replace it. For instance...
cls() 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.
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)
Hi @ooooggll and @ultrabrite.
I had to really think about this for a moment. Here is multiclip() done through coding.
I can make a much smaller one via @ultrabrite's superb suggestion, but it may not be very fast.
Here is the one I think @ultrabrite had in mind, making use of pixels - as fast I can get them.
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 ...
[Please log in to post a comment]
