Raph Levien придумал JIT-рендеринг битмапных шрифтов для микроконтроллеров
JIT bitmap text rendering for microcontrollers
Raph Levien показал, как рендерить пропорциональный битмапный текст с кернингом на RP2350, укладываясь в жёсткий бюджет — около 6 тактов на пиксель. Вместо фреймбуфера он заполняет видеобуфер построчно «в гонке с лучом». Для каждой строки JIT генерирует ARM-код, который собирает глифы из плотно упакованного шрифта (всего 960 байт) в 1-битный буфер, а затем разворачивает его в RGB565 со скоростью 1,75 такта на пиксель.
Rust не справляется с требованиями по производительности, поэтому я начал писать на языке ассемблера ARM.
- drfuchs
По поводу предшествующих связанных работ обратите внимание на патент US-6377261-B1 «Compiling glyphs into instructions for imaging for execution on a general purpose computer», поданный в 1996 году. Основная идея в том, что каждый символ превращается в последовательность инструкций «Load Immediate» / «Shift» / «OR to Memory»; так что больше нет выборки из сохранённого битмапа шрифта, поскольку пиксели неявно содержатся в данных Immediate в сгенерированном машинном коде. Затем можно и поизощряться, когда одна строка пикселей совпадает с предыдущей строкой в символе, так что даже не нужно выполнять Load Immediate. И т.д. Эта схема использовалась в FrameMaker для Macintosh в былые дни, в реализации Гаса Фернандеса (который пустился во все тяжкие с дополнительными оптимизациями).
- karmakaze
Это действительно отличный проект. Столько ретро-компьютеров сейчас настолько мощны, что могут использовать большие фреймбуферы, и программирование для них уже не ощущается как близость к железу, как раньше, когда это было более интимно.
Эта реализация напоминает мне два моих ранних опыта: программирование display lists на Atari 8-bit и интерпретатор HP PCL 5e (с коротким буфером растровых полос). Я не особо вникал в VCS/2600 с гонками луча на 128 байтах, но сделал немало кодинга на лету с прерываниями display-list для самодельных игр и демо. Я считал систему display list Atari Antic потрясающей — спасибо Jay Miner, который также сделал Amiga — и не видел ничего похожего до OS/2 Presentation Manager или Java FX.
У интерпретатора PCL, вероятно, была самая близкая форма с использованием циклического буфера в несколько сотен строк. Он «рендерил» в объекты, отсортированные по y, которые нужно было позже рендерить/растеризовать. Каждый объект обрезался так, чтобы быть не выше 255 пикселей (0,85 дюйма), и использовался обратный порядок по максимальному y, поскольку его нельзя было рисовать, пока луч не пройдёт строку развёртки, всё ещё рендерящую Y - buffer_height.
- codazoda
Я работаю над BASIC32, ретро-интерпретатором BASIC для микроконтроллеров, чтобы прошить его один раз и легко создавать множество новых проектов.
Что вы теряете при подходе автора — это «чтение». Экран становится доступным только для записи. Есть лишь несколько функций, требующих чтения: получение текущего цвета пикселя и выполнение операций вроде заливки или рисования.
Поскольку я стремился к ретро-ощущению BASIC, я хотел поддерживать их, поэтому выбрал фреймбуфер. Это не так технически круто. На RP2350 это требует низкого разрешения и низких битрейтов, потому что там часто RAM ограничена килобайтами.
Если перейти на варианты ESP32-S3 с 4 МБ или 8 МБ RAM, фреймбуфер становится гораздо проще.