Add a way for BMFont to have its file path externally referenced

[jimmykingss]

Not sure of a better way of saying it, but I'm loading a .fnt file from memory, which is where the image for it is as well, so I make it a blob and feed it to newFont, and it works, but I get an error for the image not being available in the file system: "Failed to read BMFont image from fontname.png"

But if i do put the physical image where it expects it, then it works

So I'd like a way to somehow reference the image from memory for a BMFont

Hope I'm not asking too much; I figure it should fairly simple with some new APIs or something

[bjornbytes]

Yeah, newFont and newRasterizer could take a second optional argument containing the path/Blob/Image of the BMFont image to use. If it's missing, LÖVR falls back to the existing behavior of using the image path from the BMFont metadata.

[jimmykingss]

Could also somehow get the image in memory automatically since the .fnt file is being called from memory

Or just what you siad is probably better for simplicity

[bjornbytes]

New variants:

• lovr.data.newRasterizer(string|Blob, atlas)
• lovr.graphics.newFont(string|Blob, atlas)

We can check if the second parameter is a number to distinguish between TTF font size vs. BMFont atlas.

One question is which types of atlas overrides should be supported:

• string (filepath)
• Blob (in-memory compressed image file)
• Image (in-memory image data)

I kinda vote for only Image, because you can turn paths/Blobs into images (lovr.data.newImage(string|Blob)), but you can't easily turn Images into Blobs. (You can do it with Image:encode, but that requires an encode -> decode roundtrip, whereas an encoded Blob needs to be decoded anyway). I think Image also lets you more easily use a procedural atlas, compressed atlas, etc.

[bjornbytes]

Added in fd7e874

[jimmykingss]

Lovely, and for the override, I'd say just the image as well. Thanks for the update or i guess artifact for now