OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 13:00

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 6 ] 
Автор Сообщение
СообщениеДобавлено: Воскресенье, 05 Февраль, 2023 15:12 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Тема сделана по просьбе arisu, чтобы не потерять разные полезные идеи, которые слишком революционны на этапе подготовки беты 2.0, но могут пригодиться как в творческих проектах, так и для решения разного рода проблем в текущей сборке или следующей версии Блэкбокса — инструмента, дающего неограниченные творческие возможности!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 05 Февраль, 2023 15:24 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
спасибо! постараюсь кидать сюда мысли, которые не очень вписываются в планируемый консервативный релиз 2.0, и остальных приглашаю делать то же самое. go wild, как говорится! идея такая, что сюда кидаются «сырые» мысли, и если они оформляются во что-то интересное, то потом для них можно будет заводить отдельную тему с обсуждением.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Февраль, 2023 02:00 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
очередное предложение: добавить в 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 — то рано или поздно придётся это сделать. лучше рано.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 11 Февраль, 2023 03:21 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
я таки реализовал это в 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, а я его не знаю и знать не хочу. ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 15 Май, 2023 22:55 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
кстати. у меня появилась идея, как решить проблему с `f.Input()` раз и навсегда: надо всего лишь добавить в неё параметр `timeout`. если -1, то возвращаться только если было событие с пользовательским вводом. если 0, то просто опросить текущее состояние и выйти. а если больше нуля — ждать пользовательского ввода не дольше указаного количества миллисекунд.

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

в подавляющем большинстве случаев таймаут будет -1, потому что почти во всех циклах проверяется, двигался ли курсор/отжалась ли кнопка.

при положительном таймауте `Input()` не обязательно прождёт всё время: может вернуться и сразу: это на усмотрение реализации. такой таймаут нужен для каких-нибудь анимашек, например.

попробую в LC, посмотрю, что получится. надо только в ссаном готэка найти эту самую процидурку «ждать события с таймаутом» — на иксах-то я бы просто `select()` влепил, а тут…


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Май, 2023 00:56 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
предварительно впилил. `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.: кстати, перестали противно моргать рамки, когда таскаешь несколько выделеных элементов на форме, и выделение, когда копируешь атрибуты текста при зажатой средней мышекнопке.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 6 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB