OberonCore

Тема сделана по просьбе arisu, чтобы не потерять разные полезные идеи, которые слишком революционны на этапе подготовки беты 2.0, но могут пригодиться как в творческих проектах, так и для решения разного рода проблем в текущей сборке или следующей версии Блэкбокса — инструмента, дающего неограниченные творческие возможности!

спасибо! постараюсь кидать сюда мысли, которые не очень вписываются в планируемый консервативный релиз 2.0, и остальных приглашаю делать то же самое. go wild, как говорится! идея такая, что сюда кидаются «сырые» мысли, и если они оформляются во что-то интересное, то потом для них можно будет заводить отдельную тему с обсуждением.

очередное предложение: добавить в bottleneck вместо DrawRect/DrawOval/DrawPath — универсальные пути с командами, как сделано во многих 2d рисовалках. то есть, что-то типа такого:


остальное реализовать через этот интерфейс.

что даёт: возможность рисовать сложные фигуры, собирая их из единообразных кусочков. один интерфейс вместо кучи вызовов. упрощение портов на что-то типа AGG (там используется похожий механизм). возможность использовать пути повторно (например, для контура и заливки, без копипасты). возможность в будущем расширять пути новыми командами (например, задавать паттерны для заливок, без сочинения нового апи, просто складывая их в путь как данные команды.

предварительная версия — как обычно — реализована в Lament Configuration, будет чиститься и допиливаться. кстати, вот вам и бинарный формат картинок заодно. ;-)

также (ещё не сделано, но будет) предлагаю передавать в райдер HostPorts hunit и vunit, вместо пересчёта координат в Frame. пусть bottleneck получает координаты с максимально возможной точностью, и пересчитывает их сам. полезно для реализации бэкэндов со сглаживанием, например, потому что такие бэкэнды могут хотеть координаты в REAL, например, и лучше их считать прямо на месте, чтобы терять как можно меньше точности. ну да, можно играть с unit, но я всё равно вижу смысл делать финальные пересчёты в bottleneck.

два юнита — на всякий случай и на будущее: горизонтальный и вертикальный. пока что они будут равны, но мало ли.

p.s.: рисовать сглажено, собирая из тех примитивов, что сейчас есть в BBCB — неправильно технически. сглаживание делается не так, и работает иначе: рисовалка для корректной работы должна иметь полный путь. который может включать в себя безьерки, и безьерки эти надо переводить в линии уже на уровне bottleneck. так что если мы хотим нормальный aa-rendering — то рано или поздно придётся это сделать. лучше рано.

я таки реализовал это в Lament Configuration пошире, добавил ещё установку паттернов для заполнения, и красиво отрендерил мак-картиночки в документации с заливкой. остались ещё WMF: похоже, их омики использовали чтобы всавлять растровый битмап с пояснениями. неясно, зачем, потому что в мак-картиночках тоже есть коды для вставки растров (которые игнорируются рисовалкой). странная конверсия.

прелесть схемы с complex path в том, что добавление новых команд не требует изменений в API, и не ломает старый код. ну, добавились новые константы — и всё.

кстати, может кто в курсе, что это за формат такой, и чем его на маке делали? просто в исходниках рисовалка называется `DrawMacPicture`, и совершенно отчётливо является реверс-инжинирингом чьего-то формата пикчей (кстати, похоже, не совсем корректным). может кто знает, что это? я просто в маках ваще ничоникак, а любопытно.

p.s.: посмотрел в исходник мак-версии. это, похоже, внутренний формат QuickDraw. и да, рисовалка некорректная. цитата: «QuickDraw coordinates referred to the infinitely thin lines between pixel locations. An actual pixel was drawn in the space to the immediate right and below the coordinate.». потому в картинках регионы отсечения начинаются с `(-1, -1)`. теперь ясно. не то чтобы это имело значение в нашем случае, но забавно.

а ещё, похоже, QuickDraw рисует последний пиксель линии, в отличие от винды. поэтому на картиночках иногда один пиксель пропадает. впрочем, виндовый юнит как-то умудрился попасть так, что почти все линии мутировали в два пикселя (мой линуксовый не попал), поэтому не видно.

и частичное описание формата есть в исходниках QuickDraw. которые в остальном бесполезны, потому что это асм для 68k, а я его не знаю и знать не хочу. ;-)