Will the publicly available SDK resemble 1.7.0 to a great degree?
Is public availability still expected next month?
Will the publicly available SDK resemble 1.7.0 to a great degree?
Is public availability still expected next month?
Yes, we're just focused on bug fixes until then, no big new changes coming that I can think of. If there's anything you want in the public release that we've missed please let us know! We're very much in narrow focus mode right now, haven't had the time to step back and look at bigger picture stuff in a while. I'm sure there are plenty of things we'd planned to have done by now but got pushed aside along the way.
Sorry it took me this long to figure out the simple--and obvious, in retrospect--way to make this work.
It's not a one-liner, but it'll be easy to make a function that does what you want: What I added was imagetable:setImage(n, image), and it's pretty simple to get a copy of a subrect in an image. I think there's a function in CoreLibs? setImage() will also let you replace images in any image table, not just ones allocated for loading data into. I have no idea what anyone would need that for, but there it is.
Dumb question: Can you dither it ahead of time? ![]()
My hunch is doing one big dither and then 2000 slices at run time wouldn't be much faster than doing 2000 small dithers separately, but I might be wrong. I'll give it a try if I ever get the time. If the slice widths are 8-bit width aligned it'll be a bit faster because we can copy the data directly, don't have to shift it around..
As for getting a separate copy of the table as a single image, you'd have to duplicate the file and remove the -table-w-h suffix.
Also, have you tried drawing the collider frames with a stencil to make the shadow instead? Either at run time, or ahead of time to generate the shadow frames.. That should be considerably faster than fadedImage().