I think it would be helpful to be able to optionally specify an offset into these tiling functions so I can scroll an image or pattern easily. This would have been especially helpful with this infinite scrolling control I just finished up.
Just a thought.
Or should I be setting draw offset before calling this then resetting it afterwords?
I've been rotating the pattern definition to animate it. Also not ideal.
OK, nevermind!
Something like this works fine it seems. Completely forgot about setDrawOffset(x, y) which of course works within an image's draw context.
local list_position = math.fmod(self.scroll_offset, list_image_height)
local repeat_count <const> = math.max(math.ceil((self.view_height / list_image_height) / 2), 3)
graphics.setDrawOffset(0, list_position - (math.floor(repeat_count / 2) * list_image_height))
self.list_image:drawTiled(0, 0, self.width, list_image_height * repeat_count)
graphics.setDrawOffset(0, 0)
I think—I think—it would still be handy to have optional offset for setDitherPattern however.
playdate.graphics.setPattern(image, [x, y])
Appears to take an optional offset when passing an image. Not when passing a table however. The C API function void playdate->graphics->setColorToPattern(LCDColor* color,LCDBitmap* bitmap, int x, int y) appears to support offset params when passing in a table.
I wonder if this is mostly just an oversight.
And setDitherPattern doesn't exist in C API (I think?), but that too would benefit from optional offset params.
Actually, hmm, the offset doesn't wrap when drawing when setting a pattern offset when passing an image. Strange!
Also, for whatever reason, drawTiled with an 8x8 image appears to be quite a bit slower than setPattern/fillRect of the same area.
Sorry to revive an old thread, but I wanted to +1 this feature request. It would be very convenient to be able to pass a offset parameters without having to mess with setDrawOffset.