OberonCore https://forum.oberoncore.ru/ |
|
Смелые размышления под впечатлением https://forum.oberoncore.ru/viewtopic.php?f=134&t=6894 |
Страница 1 из 1 |
Автор: | Иван Денисов [ Воскресенье, 05 Февраль, 2023 15:12 ] |
Заголовок сообщения: | Смелые размышления под впечатлением |
Тема сделана по просьбе arisu, чтобы не потерять разные полезные идеи, которые слишком революционны на этапе подготовки беты 2.0, но могут пригодиться как в творческих проектах, так и для решения разного рода проблем в текущей сборке или следующей версии Блэкбокса — инструмента, дающего неограниченные творческие возможности! |
Автор: | arisu [ Воскресенье, 05 Февраль, 2023 15:24 ] |
Заголовок сообщения: | Re: Смелые размышления под впечатлением |
спасибо! постараюсь кидать сюда мысли, которые не очень вписываются в планируемый консервативный релиз 2.0, и остальных приглашаю делать то же самое. go wild, как говорится! идея такая, что сюда кидаются «сырые» мысли, и если они оформляются во что-то интересное, то потом для них можно будет заводить отдельную тему с обсуждением. |
Автор: | arisu [ Четверг, 09 Февраль, 2023 02:00 ] |
Заголовок сообщения: | Re: Смелые размышления под впечатлением |
очередное предложение: добавить в bottleneck вместо DrawRect/DrawOval/DrawPath — универсальные пути с командами, как сделано во многих 2d рисовалках. то есть, что-то типа такого: Код: VAR pt: ARRAY 128 OF INTEGER; ppos: INTEGER; x, y, w, h: INTEGER; PROCEDURE Command (cmd: INTEGER); BEGIN pt[ppos] := cmd; INC(ppos) END Command; PROCEDURE Coords (x, y: REAL); BEGIN pt[ppos] := SHORT(ENTIER(x + 0.5)); INC(ppos); pt[ppos] := SHORT(ENTIER(y + 0.5)); INC(ppos); END Coords; Command(pathMoveTo); Coords(x + rw, y); Command(pathLineTo); Coords(x + w - rw, y); Command(pathBezierTo); Coords(x + w - rw*(1 - KAPPA90), y); Coords(x + w, y + rh * (1 - KAPPA90)); Coords(x + w, y + rh); Command(pathLineTo); Coords(x + w, y + h - rh); Command(pathBezierTo); Coords(x + w, y + h - rh * (1 - KAPPA90)); Coords(x + w - rw * (1 - KAPPA90), y + h); Coords(x + w - rw, y + h); Command(pathLineTo); Coords(x + rw, y + h); Command(pathBezierTo); Coords(x + rw * (1 - KAPPA90), y + h); Coords(x, y + h - rh * (1 - KAPPA90)); Coords(x, y + h - rh); Command(pathLineTo); Coords(x, y + rh); Command(pathBezierTo); Coords(x, y + rh * (1 - KAPPA90)); Coords(x + rw * (1 - KAPPA90), y); Coords(x + rw, y); Command(pathClose); f.DrawPathComplex(pt, ppos, s, col) остальное реализовать через этот интерфейс. что даёт: возможность рисовать сложные фигуры, собирая их из единообразных кусочков. один интерфейс вместо кучи вызовов. упрощение портов на что-то типа AGG (там используется похожий механизм). возможность использовать пути повторно (например, для контура и заливки, без копипасты). возможность в будущем расширять пути новыми командами (например, задавать паттерны для заливок, без сочинения нового апи, просто складывая их в путь как данные команды. предварительная версия — как обычно — реализована в Lament Configuration, будет чиститься и допиливаться. кстати, вот вам и бинарный формат картинок заодно. ;-) также (ещё не сделано, но будет) предлагаю передавать в райдер HostPorts hunit и vunit, вместо пересчёта координат в Frame. пусть bottleneck получает координаты с максимально возможной точностью, и пересчитывает их сам. полезно для реализации бэкэндов со сглаживанием, например, потому что такие бэкэнды могут хотеть координаты в REAL, например, и лучше их считать прямо на месте, чтобы терять как можно меньше точности. ну да, можно играть с unit, но я всё равно вижу смысл делать финальные пересчёты в bottleneck. два юнита — на всякий случай и на будущее: горизонтальный и вертикальный. пока что они будут равны, но мало ли. p.s.: рисовать сглажено, собирая из тех примитивов, что сейчас есть в BBCB — неправильно технически. сглаживание делается не так, и работает иначе: рисовалка для корректной работы должна иметь полный путь. который может включать в себя безьерки, и безьерки эти надо переводить в линии уже на уровне bottleneck. так что если мы хотим нормальный aa-rendering — то рано или поздно придётся это сделать. лучше рано. |
Автор: | arisu [ Суббота, 11 Февраль, 2023 03:21 ] |
Заголовок сообщения: | Re: Смелые размышления под впечатлением |
я таки реализовал это в 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, а я его не знаю и знать не хочу. ;-) |
Автор: | arisu [ Понедельник, 15 Май, 2023 22:55 ] |
Заголовок сообщения: | Re: Смелые размышления под впечатлением |
кстати. у меня появилась идея, как решить проблему с `f.Input()` раз и навсегда: надо всего лишь добавить в неё параметр `timeout`. если -1, то возвращаться только если было событие с пользовательским вводом. если 0, то просто опросить текущее состояние и выйти. а если больше нуля — ждать пользовательского ввода не дольше указаного количества миллисекунд. введение таймаута позволит нам проинформировать райдер, чего именно мы от него хотим. и практически в любой оси есть API для ожидания события с таймаутом, которое не выжигает CPU. так и код станет чище (мы будем прямо указывать, чего именно хотим), и `Input()` сможет на основе запроса решать, как и сколько ждать. в подавляющем большинстве случаев таймаут будет -1, потому что почти во всех циклах проверяется, двигался ли курсор/отжалась ли кнопка. при положительном таймауте `Input()` не обязательно прождёт всё время: может вернуться и сразу: это на усмотрение реализации. такой таймаут нужен для каких-нибудь анимашек, например. попробую в LC, посмотрю, что получится. надо только в ссаном готэка найти эту самую процидурку «ждать события с таймаутом» — на иксах-то я бы просто `select()` влепил, а тут… |
Автор: | arisu [ Вторник, 16 Май, 2023 00:56 ] |
Заголовок сообщения: | Re: Смелые размышления под впечатлением |
предварительно впилил. `f.Input()` теперь ожидает событий, если нажата какая-то мышекнопка. также добавил `f.InputWithTimeout()` и `f.QueryInput()`. в bottleneck всё тот же один `Input()`, с таймаутом. странное поведение при ненажатых кнопках потому, что в основном циклы пишут так: `REPEAT f.Input(…) UNTIL ~isDown`. соответственно, если на входе у нас уже `~isDown`, то не надо ничего ожидать. эффект наблюдаю: пока мышь не двигается, цпу сидит в 0.0 (чего не удавалось добиться слипами). посмотрю, что сломается. ;-) в принципе, при таком изменении почти весь старый код будет работать, только немного лучше. редкое исключение — когда `Input()` используют, чтобы спросить текущее положение курсора или нажатые кнопки. это надо заменить на `f.QueryInput()`, иначе будет ой. в оригинальном коде среды такое один раз в Controllers. ещё есть в StdDocuments, StdStdCFrames, StdTabFrames. в некоторых местах (StdLinks) `f.Input()` вызывается до того, как зовут `f.MarkRect()`, это надо починить: оно работает, но некрасиво выглядит. p.s.: кстати, перестали противно моргать рамки, когда таскаешь несколько выделеных элементов на форме, и выделение, когда копируешь атрибуты текста при зажатой средней мышекнопке. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |