I have a black and white PNG with a width of 400px and height of 240px
I'm trying to load it by file path directly into the frame buffer with display.loadImage("images/title") (the image is at source/images/title.png.
However, when running I get the following error dialogue:
[Window Title]
Loading Failed
[Main Instruction]
The file could not be loaded.
[Content]
main.lua:13: loaded file properties don't match framebuffer's
stack traceback:
[C]: in field 'loadImage'
main.lua:13: in main chunk
[Retry] [Launcher] [Cancel]
Hmm. I think you're trying to load a PNG rather than a compiled PDI?
PNG files (doesn't matter what bit depth, etc) are converted to PDI (Playdate image format) at compile time, when using pdc.
For this to happen they need to be in your Source folder.
And you should refer to them by filename without an extension in your code, but I think you know that judging by your code.
I'm not sure what is going on yet, but it does look like this may be a bug in the current release of the SDK. I was able to reproduce the problem with another image I created, so I don't think it is an issue with this particular image.
Yikes. Turns out I broke that in May of 21 when I removed the 4-byte row alignment for images in order to make font storage more efficient. The framebuffer still has 52-byte rows, but a 400-pixel wide will use 50-byte rows, hence the mismatch. Using image:draw(0,0) will always work, but if you want to test how much faster display.loadImage() is you could pad the image out to 416x240 pixels--but then if I decide to change the framebuffer to 50-byte rows it'll break that.
There's probably a good reason I didn't do that? Well, at the very least we should note this in the docs.
Sorry for the confusion, I didn't mean to imply that was a reasonable long-term solution, it's just a quick workaround if you wanted to test timing. Unfortunately I think adding the padding on the fly will lose the gain we get from decompressing the image data directly into the frame buffer--we'd have to load to temp storage first then copy row-by-row, which is pretty much what you're doing when you draw it with image:draw(0,0).
I think we'll probably drop that function. It's been broken for two years, so obviously nobody's using it.
Sorry, this is off topic but are you using IntelliJ IDEA for Playdate development? If is, how is that working out? What plugins are you using? How is the debugger? Thanks.
It's 2024-02-25, using PlayDate Simulator Version 2.3.1 (165008), Nova 11.8 (Build 573039), and Section 6.16 Display documents the loadImage function. The problem still persists.
And the workaround, playdate.graphics.image.new("images/foobar"):draw(0,0) does as well.
I'd really like to see this function fixed, rather than deprecated or removed.
I'm also curious about the bug details, as it seems like that function could, at least for the time being, be aliased to the one-liner above. Is it trying to do a high-speed copy to the frame buffer?
Well, at the very least we should note this in the docs.