Ok, I think I found the problem (but just you wait, there are more problems coming... ^^)
If I re-flash the FPGA bootloader before I upload my sketch containing a new app.ttf, then everything seems to work.
It seems that I have to flash the bootloader anew before every sketch upload, for the app.ttf to be written.
The tools for re-flashing the bootloader can be found in this thread:
https://forum.arduino.cc/index.php?topic=561393.0Seems like a really convoluted and error-prone workflow... Would be great if the normal "modus operandi" of a sketch would be to use JTAG (or some other "native" method) to flash the FPGA in the first place, and not be dependent on a working bootloader in the FPGA to receive the app.ttf!
Anyway, now I can consistently flash a new app.ttf.
However, the VidorGraphics library is absolutely useless when built from source with the free version of Intel Quartus.
The VidorBitstream repo's README notes that the NIOS2 softcore in Quartus Lite is a crippled version that runs much slower than the one in the paid Quartus Standard.
I can confirm that this causes all graphics commands (like fillRect(), fillCircle() etc.) to run EXTREMELY slowly - you'll watch the picture being drawn pixel-by-pixel, it'll take almost a minute for the VidorDrawLogo example to finish drawing. o.O
Also, I cannot get the VidorEnableCam example to work at all with the source-built library/app.ttf.
First, the screen is (pretty slowly) filled with white. Then, when vcam.begin() is called, the screen is (even more slowly) filled with black (pixel by pixel). This is the VidorCamera library filling the graphics overlay with "transparent" pixels, to unveil the underlying camera stream (see here:
https://forum.arduino.cc/index.php?topic=560517.msg3824792#msg3824792 and check out VidorCamera::begin() in VidorCamera.cpp).
However - there's no camera video underneath, just black. With the precompiled library/app.ttf, again, it does work.
Sigh. I'm starting to very much regret my purchase of the (expensive!) Vidor, that was being touted as an Arduino with a programmable FPGA! Not as an Arduino with a black-box IC (that technically happens to be an FPGA) which cannot be used for anything but a few useless precompiled toy functions.
A good start would be for Arduino to re-write the FPGA parts of the library to be *completely* functional when built from source with the *free* Quartus version.
Even better would be to redesign the board with something like the Lattice ECP5 or Xilinx Zynq-7000 and use the fully open source toolchains available for those!

That would've been awesome.
Also, the "KISS" mentality would serve well: the Vidor FPGA workflow is very convoluted with all the "infrastructure" in the build environment to stitch together different IP blocks and binary images in god-only-knows-what way - it is a very opaque system for the newbies, much harder to figure out than necessary.
Sticking to plain, simple Verilog projects without softcores, bootloaders etc. would be much easier on the beginner.
I was planning to do a pretty simple project based on the QR reader, where I modified the reference firmware to track visual features in a slightly different way.
After wasting many days on just trying to get this crazy build workflow going, I have now pretty much decided to scrap my project, as it doesn't seem doable unless I rewrite the whole FPGA part from scratch. That was NOT part of my intention, and is also way harder to do for a beginner, than what I was planning to do.
For anyone reading this who is thinking about purchasing the Vidor to get started with Verilog/FPGA development, I would very strongly recommend against it. Go get a Lattice Icestick, Xilinx/Digilent Zybo board or the ULX3S Lattice ECP5 board instead, use the open source toolchains, and you'll likely have a
much better time!
