convert images to binary and link them in

[gordonjcp]

Instead of storing the images as binary-converted-to-C-source with big lists of numbers, it's possible to turn them into a "linked library" which is just a blob with symbols that the compiler can recognise.

This PR is a proof-of-concept but it needs the Makefile written to create the binary image.

To use it, run "makeimage.sh" in the Nekobi plugin directory.

Everything will look the same.

Do something to the background graphic, re-run makeimage.sh, and recompile. The background will have changed.

[falkTX]

as far as I know this does not work on macOS.
plus a similar approach to this can already be used with the res2c.py script if needed, but that is a bit pointless since it is not the raw png images that the plugins use but the raw bitmap bytes so simply converting the png into a binary wont work here.

[falkTX]

what I meant to say is that https://github.com/DISTRHO/DPF/blob/5b7670584d16e76a27cf0d6575b8bf9921de2714/utils/png2rgba.py is the script that generates these.
nothing stops us from deleting the generated cpp file and have its generation be part of the build, alike your idea.
it is just more convenient to have it in code directly, because otherwise we need extra dependencies to handle the png -> raw image conversion

[gordonjcp]

But then the problem is that it doesn't scale, because a 64kB binary blob - like one of the four wavetable ROMs in a hardware synth I built that I'd like to do a plugin of - becomes a 400kB source file with tens of thousands of lines.

Why doesn't it work in Mac OS?

[falkTX]

But then the problem is that it doesn't scale, because a 64kB binary blob - like one of the four wavetable ROMs in a hardware synth I built that I'd like to do a plugin of - becomes a 400kB source file with tens of thousands of lines.

the extra space is only used when coverting to code, when it gets into the binary it should take exactly the same size as the blob plus a few bytes for pointers and size storage.

Why doesn't it work in Mac OS?

macOS can make use of "fat" binaries that include multiple architectures in one single object file, which is the approach used by dpf as it makes everything much easier (the alternative is doing the same build twice and then combine the objects together, too much hassle). a single ld invocation breaks this.

Also the linker used in macOS is a custom apple one, based on LLVM/clang but not directly upstream version.
I tried this myself before and it was quite tricky to get it to work, dont recall details now.
But I know VCV has had to deal with the same problem and they dont even use fat/universal binaries, their approach can be seen in https://github.com/VCVRack/Rack/blob/v2/compile.mk#L97