PNG erroring when loading to frame buffer

SDK Bug Reports
1

I have a black and white PNG with a width of 400px and height of 240px
400px * 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]

The bit depth is set to 8, should this be 1?

2

Here are the file properties.

image
image363×509 10.8 KB

3

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.

See Inside Playdate sections 3.2 and 3.3 https://sdk.play.date/inside-playdate/#_structuring_your_project

1 Like
4

Thanks Matt,

I think the structure is correct though:

image

5

Sorry I was making a bunch of edits as this has me a bit puzzled.

What is the contents of your compiled pdx?

6 
C:\...\MECHANISMS.PDX
│   main.pdz
│   pdxinfo
│   SplashScreen.pdz
│
└───images
        title.pdi
1 Like
7

That looks like it should.

I have no idea, it feels like a bug. I'll assign to Dan.

But, meanwhile you can swap this line:
display.loadImage("images/title")

...for this one, that works:
gfx.image.new("images/title"):draw(0,0)

project download:
test.zip (1.8 KB)

1 Like
9

That displays the image correctly.

1 Like
10

Great!

Let's see what Dan says.

11

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.

Thanks for letting us know about this!

2 Likes
12

Good to know. I'll quit trying to debug it myself then.

Thanks both.

13

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? :thinking: Well, at the very least we should note this in the docs.

14

Padding the image manually is quite unintuitive.
Could the load function pad it automatically at runtime?

15

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.

2 Likes
17

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.

18

@bwit,

I was using it because JetBrains is my standard goto (albeit usually WebStorm and Rider), with the EmmyLua plugin, however I moved to VS Code.

With the correct setup, VSCode is a better UX than IntelliJ for Lua.

19

Thanks David. I'm also a big fan of Jetbrains IDEs but was surprised to see you using it for Playdate.