OberonCore

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

из-за однопроходности JECXZ на метку, определённую ниже по тексту, не фурычит. починить не так сложно, но мне лень.

а вот красивый SSE-код для блита одного битмапа на другой с альфой я, кажется, того-с… не могу найти. или пролюбил, или в своё время поленился написать. жаль, потому что я не готов к подвигу нырять в SSE снова. а код нужен чтобы делать pattern fill с альфой, да и просто блиты. без альфы тоже можно, конечно, но с альфой-то лучше! тем более что альфа для AA нужна.

ладно, может удастся где-нибудь в интернетах украсть, не всё же самому пилить. говорят, сейчас в интернетах всё есть.

во-первых, выражаю благодарности и респекты товарищу luowy за помощь в блохоловле внутри асма, и не только. (thank you for helping with bugs and features, and simply for being a nice person! ;-) JECXZ на метку ниже уже фурычит, и кое-какие другие мелкофиксы сделал. кстати, если будете пользоваться асмом (смешная шутка получилась, откуда у LC пользователи), то учтите, что джампы вперёд всегда long, потому что асм однопроходный. это можно починить, конечно, но лень и оно того не стоит.

накоекакил бленд с альфой на обычном асме. криво, косо, но всё равно быстрее, чем выхлоп компилятора. да, надо бы не забыть референсный код потом положить.

по какому поводу появилась Мысль, и я сейчас на вас буду её думать. что нам, понимаешь, надо, чтобы писать игори на BBCB? ну, кроме слабоумия и отваги, конечно (это у меня уже есть). надо, чтобы гранулярность тика главного цикла можно было более-менее жёстко прибить к таймеру, вот что нам надо.

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

а, ну да, ещё события про отпускание кнопок на клавиатуре, а не только про нажатие. надо посмотреть, можно ли из идиотского готэка это вообще добыть, или эксперимент придётся отложить до избавления от инвалида.

лучше бы, конечно, мне для этого всего кто-нибудь сделал такое, но за неимением гербовой…

p.s.: не, понятно, что можно крутить цикл типа `f.Input()`. но это же не наш метод!

пост по следам недавних личных обсуждений. затрагивалась тема перегрузки операторов, и я внезапно понял, почему мне не нравятся строки в CP.

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

исходя из этого тезиса `$` — это нарушение: там происходит сканирование массива, замаскированое под примитивную операцию. с конкатенацией строк всё ещё хуже: там может неявно выделяться буфер под временный результат. обероновская `COPY()` была более правильна.

конечно, писать с такими строковыми операциями более удобно. но тут мы приходим к Фундаментальной Проблеме Современных Языков имени меня: современные языки затачиваются под написание кода, а не под чтение. на удивление, в сишечке строки вышли лучше: `strcpy()`, `strcmp()`. сразу понятно, что это некое тяжеловесное действие. а `a$ + b$` обманчиво читается как «мгновенная примитивная операция». (конечно, из этой схемы чуть выбиваются LONGINT'ы, но то отдельный разговор.)

увы, убирать `$` из Ultra Pascal уже поздно, но `COPY()` я, наверное, разрешу обратно, и постараюсь использовать побольше. зря омики тут прогнулись: продавать BBCB это особо не помогло, а гадость в язык просочилась.

а пока я думаю над предыдущим — сделал переменную цикла в FOR read-only. технически её изменение внутри цикла — это UB и грязный код. корректный код на CP такого делать не должен, а если делает — это ошибка. так что компилятор и триггерится на это как на ошибку теперь.

быстровхачил «размер шрифта по умолчанию». вхачил исключтельно в HostFonts/Lin (по той же схеме надо и в вин, но мне лень пока): когда хостовая создавалка шрифтов видит вот такое условие размера: `size MOD Fonts.point = 69` — она очень возбуждается, и использует вместо этого «стандартный размер». size в шрифте, однако, остаётся тот, что передали. таким образом, если у нас стандартный размер шрифта 10 пунктов, например, то реально в odc будет записано `10 * Fonts.point + 69`. другие версии BB просто увидят это как 10 (потому что один фиг делят на пункты). хак, конечно, и весьма кривой — но камон, зато обратная совместимость почти идеальная.

пока не сделал апдейт шрифтов в документах, если размер в preferences поменяли: надо после смены все документы переоткрыть. я чот не понял, можно ли документам скомандовать "total refresh" (чтобы они и шрифты обновили), а искать лень.

p.s.: это вот к этой идее.

Как-то Вы слишком вычурно всё сделали, профессиональный Вы наш - впилились в OPT, в OPB зачем-то. Можно было проще.

Чтобы прояснить: вся правка может свестись к только присваиваниям в OPP.StatSeq. Было:

Стало:

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

p.s.: и да, я бы предпочёл, чтобы вы не меняли своё мнение подобно флюгеру, всё-таки не посещали эту тему — и не продолжали со мной.

Представьте, что Вы использовали в FOR переменную, которую импортировали из другого модуля, экспортированную только для чтения. Дело в том, что в BlackBox уже есть механизм работы с такой переменной как r/o. А Вы впендюрили сбоку ещё один. Так что я написал для пользы дела, хотя и без учёта Вашей твердолобости. Критика моих правок? Они не работают? Какие-то побочные эффекты? Или это просто потому, что предложил их я?

Корректность моей правки подтверждается внутренним устройством процедуры CPB.NewLeaf:

Я там говорил Ивану про ворвавшегося гусара, бряцающего шпорами и принявшегося быстро и грязно хачить BlackBox. Так вот это Вы. Гм, Иван, оказывается, наш arisu это Ketmar, с которым я собачился ещё стопицот лет назад. И он ещё тогда хотел "улучшать" BlackBox, ну вот - наконец-то дорвался.

Искренне не понимаю, зачем ругаться. Выскажусь, раз уж Олег меня вовлёк в дискуссию. Если человек делает свою ветку, какое мы имеем моральное право что-то мешать ему делать? Тут в формате блога автор делится своим приключением и внутренним диалогом. Что-то из этого может быть полезно, что-то нет. Думаю, что любой автор будет рад спокойному отношению "а я бы сделал не так, а вот так". Ну а нас ведь не заставляют пользоваться его веткой. Это как я бы или Ketmar в вашу версию XDev пытался энергично и настойчиво что-то внести. Выглядело бы странно.

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

собственно, по этой вот «рекомендации» уровень компетентности рекомендующего полностью понятен. и — вследствие этого — его мнение по какому-либо вопросу мне совершенно неинтересно.

p.s.: Олег, будьте так любезы: уйдите из этой темы и больше тут не появляйтесь. каждое ваше появление тут сопровождается прямым нарушением правил данного подфорума. если вы не хотите успокоиться самостоятельно — я буду вынужден попросить администрацию вас успокоить. так доходчиво получилось?

таки да. вон выше товарищ Comdiv вполне обоснованно покритиковал моё нововведение, и предложил подход намного лучше. почему-то с ним у меня плодотворное обсуждение вполне получилось. может потому, что он не пытался сходу меня оскорбить? да нет, ерунда какая-то, не может это быть причиной…

эвона как. олег у нас, сталбыть, лучше меня знает, что в LC есть, а чего в LC нет, и какие у меня там анализаторы кода, которых в оригинальном CP2 не было (а кое-каких нет и в репозитории пока). и «защищает» свой хак, мотивируя тем, что подобный хак используется ещё и где-то в другом месте. прелестно. если у меня до этого и были какие-то намерения использовать ofront, олегом испорченый — то теперь я точно уверен, что ни к чему, отмеченому печатью его гениальности, я не прикоснусь. недостоин-с.

замечу, что ничего по существу моего патча олег так и не сказал. почему? а потому что он его даже не смотрел: увидел список изменённых файлов — и стриггерился. сами же ODC смотреть нечем, да и много чести. это чтобы опять был понятен уровень, так сказать.

(для тех, кому лень: у Object появилось поле readonly, которое позволяет устанавливать оное же поле в leaf node без хаковых манипуляций областью и типом импорта. весь патч — пять строчек в трёх файлах. введение явной возможности поставить r/o любому объекту без необходимости фэйчить его происхождение — это, как я понимаю, намного хуже и непонятней, чем хак, который меняет область видимости переменной. авторы компилятора область видимости где-то хачили — значит, это Идеальное Решение, думать больше не надо.)

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

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

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

ну и немного по делу, про OP2/CP2. установка r/o путём манипуляции «провенансом» объекта — это именно хак. на самом деле в компиляторе это надо, мягко говоря, очень нечасто, и заводить в структуре DevCPT.Object отдельное поле, которое используется полтора раза на весь код было довольно расточительно: объектов-то в программе довольно много. не забываем, под какое железо писался оригинал. в OP2 подобных хаков есть. не то чтобы весь код ними был усыпан — но есть. ну и дополнительный IF в одной из часто вызываемых процедур, да — а OP2 и так пересобирался около тридцати секунд (это можно выяснить из репорта Региса Кр… Кр… Crelier, короче).

в 2023-м году, однако, можно себе позволить потратить дополнительный байт (четыре, с учётом округлений, ну да ладно) в записи на поле, которое надо один раз в високосную пятницу — не так страшно. в обмен на это мы получаем код, который во-первых, чище, а во-вторых, понятней без хождения по другим модулям. `id.readonly := TRUE;` — это понятно. `id.vis := externalR; id.mnolev := -128;` — это непонятно, и к тому же дезинформирует компилятор о том, что у нас за переменная. подобная дезинформация сбивает с толку один из моих анализаторов кода (которые периодически появляются и исчезают в экспериментальном компиляторе, не попадающем в репозиторий).

я стараюсь не очень переделывать публичный CP2 в LC по некоторым причинам (и потому в нём встречается и ненужная копипаста, и сохраняются старые хаки), но вот конкретно здесь никакого глубокого смысла не перетаскивать readonly из экспериментального я не увидел. чисто, красиво, без хаков.

эти нюансы можно было без проблем и спокойно выяснить, если не влетать на белом ишаке с шашкой наголо, а просто нормально задать вопрос.

портанул (но ещё не закоммитил) рисовалку из обероновых гаджетов. у неё нет сглаживания (и это хорошо! ;-), зато по остальным параметрам она идеально подходит для реализации ports bottleneck. собственно, порты с неё и слизали, я так понимаю, только поддержку масок (ака регионов) выкинули. тестируем, естественно, на любимом векторе Мудрого Козла. порт полный, так что она умеет и в паттерны, и в регионы.

надо чистить и оптимизировать, конечно, но в принципе — уже можно избавиться от каиры в портах.

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

вдолбил по привычке совсем немного ассемблера в рисовалку (а почему бы и да). для скорости, видимо, надо выкинуть нафиг регионы, и оставить только обсечение прямоугольником: порты ничего сложнее не используют. полноценную рисовалку с регионами тоже оставлю, ней можно будет на Ports.Raster рисовать.

если кому-то охота поиграться, то вот PoC. нужен LC, потому что ассемблер и расширеный StdRasters, но адаптировать обратно под mainline не так сложно. это рисовалка с обсечением чисто прямоугольником, без масок, в одном модуле. простите за кривой view с растром — схватил первый попавшийся под руку исходник для теста, и жестоко изуродовал.

сама рисовалка рисует в 32-битный RGBA буфер (A всегда устанавливает в 0FFH), а как этот буфер будут на экран кидать — её не парит. поддержки альфа-канала, собственно, нет, и нафиг он там не нужен: просто с 32-бит буфером работать проще, чем с 24-бит.

ассемблер, на самом деле, там чисто «чтобы было, а то пацаны засмеют». надо бы блитер паттернов тоже на асме переписать, но лень.

портировал на этот рендер DrawComplexPath. это у меня в Ports такая универсальная-рисовалка-всего, через которую, в принципе, можно сделать всё остальное (кроме текста). я её для того и вводил, собственно. завтра, наверное, попробую сделать альтернативный HostPorts и посмотреть, как взлетит. виндорендер надо будет тоже на это же потом перевести, для единообразия.

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

почистил и ускорил код немного, добавил winding rules для залитых полигонов (должно работать, но кто его знает… ;-), сделал более лучшие овощи^w отсечения. также впилил возможность устанавливать pattern origin.

в принципе, эту красоту даже не надо в Host прятать: она ведь совершенно не зависит от хоста. самое ей место в System. из внешнего тащит только Ports, и тот всего для нескольких типов.

хм… интересно, а если заменить заливалку полигонов на другую, из AGGLite? ну, и координаты в fixed point переделать. по идее, этого будет достаточно для antialiasing. может, попробую потом.

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

ладно, это всё равно был эксперимент, понятно, что надо две разных рисовалки писать.