OberonCore

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

списочек нужен затем, что мы можем иметь такое:


здесь в момент `SomeCall()` компилятор ещё не в курсе, что дальше есть `UP`, и спокойно такой код пропустит; так что проверять надо в конце. в подавляющем большинстве случаев в списочке NIL, так что особо ничего не портит.

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

добавил отвратительный, но полезный хак: команду компилятору быстренько зарезолвить все forward type declarations. надо попросить `TYPE:RESOLVE;` — и он сделает. хак недокументирован специально, потому что не надо его использовать.

зачем такое? а вот зачем, например:

без принудительного резолва тип поля `ClusterHeader.next` в момент объявления константы неизвестен, и `SIZE()` не получается.

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

форсить резолв по встрече CONST/VAR нельзя, потому что некоторые стандартные модули приходят в экстаз. например, интерфейс к libc довольно грязно сделан, и объявляет переменные посреди описания типов.

чота я с этим хаком поторопился — привычка пихать хаки как первое решение. можно ведь намного проще: при встрече VAR/CONST просто вызывать разрешалку типов с флагом: «а не кидай ошибки, дорогой, молчи!» тогда и хак не нужен: что не смогли починить — оставлять в списке на починку, который потом обработается правильно. там в разрешалке всё так и делается, а ошибки кидаются отельным циклом в самом конце — который можно спокойно обернуть в условие.

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

пора дизайнить полезное. поскольку одна из целей разработки LC — писать ретровидеоигори и прочее бесполезное (гыг), надо делать для LC аналог SDL.

по плану это будет отдельный интерфейс в HostBackends, плюс апи повыше в подсистеме Quackerjack (Qjack). оно, собственно, и будет уметь только необходимый минимум: сделать окошко с OpenGL-контекстом, получать события от клавомыши, да показывать задний буфер OpenGL по команде. само окно даже не View, и View'ы туда складывать нельзя, конечно. а, ещё окну должна быть возможность установить желаемый FPS, чтобы сообщение «готовь новый кадр» посылалось с нужной частотой (которая может быть меньше, чем квант внутри Loop).

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

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

самая неприятная проблема, кстати — это обработка мыши. если надо, чтобы мышью управлялась какая-нибудь камера в 3д, то сразу возникает куча граблей. начиная с того, что мышь надо постоянно центрировать в окно (нет, просто грабать нельзя, тогда в иксах на другую задачу не переключиться), и дальше по проспекту «блин, дайте мне relative motion без системной акселерации, у меня своя акселерация!» до тупика отчаянья.

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

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

а к OpenGL обращаться будем через стандартные бинды, которые я сгенерю из хроносовых xml, и положу в Host. зря я, что ли, генератор пилил.

А если TYPE MyArray = ARRAY SIZE(MyRec) OF Something или типа того?

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

p.s.: но вообще, есть хак: просто пустое `CONST` без ничего. на удивление, парзер позволяет `CONST TYPE A = …`.

что-то у меня настроение плохое. переведу LC полностью под GPLv3 поэтому. официальному 2.0 официально разрешаю брать код под старой MIT^w 2-clause BSDL, а остальные пусть склоняются перед GPL. такие дела.

а. и само собой, добавил code of conduct. без него никак.

it seem that the DevCPP.Type need a fixup:

i don't get it. what it fixes, and why? i mean, could you give a code sample which needs this fix, please? incomplete types should not work in SovietPony's case, this is not a bug.

p.s.: oh, and i forgot. you can take any my code too, it is still BSDL for you. ;-)

I test this code with bbCenter 1.73 after this fixup, it worked;

i see. but i don't fully understand what is going on there, and what unforseen consequences that may have, so i'd better avoid applying that patch for now. but i'll try to get my mind around it later. thank you!

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

заодно докинул импорты для OpenGL разных версий. разделил для уменьшения размеров на разные модули; всё, что выше версии 1.1 автоматически импортируется в момент первого вызова.

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

в общем, ещё немного секса — и можно будет писать 2д платформеры. правда, без звука пока: надо сделать импорты для OpenAL и всяких библиотек-декодеров.

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

на шоте открытое Quackerjack-окошко, в нём зелёный прямоугольник, а поверх текстурный атлас. через OpenGL. атлас загружен из png встроеной читалкой (Raster). вся эта дребедень перерисовывается шыйсят раз в секунду, хоть оно из шота и неочевидно.

естественно, среда в это время вполне рабочая: ей квагга-окошко совершенно не мешает.

ну и кстати: убрал LinGtk и WinMdi. оба устаревшие, оба только добавляют ненужных проблем, оба бесполезны. про mdi и так всё ясно: тяжёлое наследие тёмного прошлого. а X11 сейчас намного круче и фичастей, чем готэка; и дотягивать готэка до этого уровня я смысла не вижу. кто-то может разве что пострадать по (не очень хорошо) сглаженым линиям из панги, но сглаживание можно реализовать и в фрэймбуферной рисовалке. мне просто не надо, но можно — или спереть из A2, или допилить AGGLite (я показывал предварительный порт со сглажеными полигонами).

и приделал экспериментальный mouse warping. хоть я и не собираюсь пока делать AAA-тржиде-шутан. вообще, надо бы делать режим чтения мыши через xi2, но мне так лень туда нырять… короче, понадобится — тогда. а так-то я просто хочу 2д игори в окошечке.

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

тем не менее, API для батлнека более-менее вырисовывается. это, по сути, отдельный бэкэнд; просто главная получалка сообщений от системы должна знать о таких бэкэндах, чтобы сообщения для них обработать иначе. благодаря этому оно и в обычный цикл сообщений встраивается seamless. конечно, штука опциональная: можно просто не реализовывать. именно поэтому я в отдельный бэкэнд вынес.

кстати, НЕНАВЕЗДЬ. почему текстовый контроллер делает вид, что не в курсе про нажатые ctrl, alt и ты пы, и позволяет вставлять в текст такие буковки? в смысле, если, например, Ctrl+T ни на что не забиндена, то оно вставит буковку «t». и зачем мне в тексте вот такое?

я подозреваю, что это тяжёлое наследие винды (и, может, мака — не в курсе, как там): винда отдельно присылает KEYDOWN и CHAR. и для ctrl+x чары не шлёт. в общем, заблокировал такие фокусы, а то надоело: промажешь по хоткею — и сразу в текст гадит.

заодно сделал возможность в кейкомбах второй и дальнейшие кнопочки иметь или без модификатора вообще, или с любым модификатором. потому что, например, я привык букмарки ставить через «C-k C-1», но иногда сбиваюсь на «C-k 1». или ещё какой модификатор нажму нечаянно. почему, собственно, я должен подстраиваться под машину, а не машина под меня?

хочу: переделать TextModel на деревья. сделать lazy sweep в GC. сделать потокобезопасный GC (мне надо). сделать View с OpenGL-контекстом внутри (для всяких редакторов). допилить Quackerjack, сделать бинды к OpenAL и демо-платформер. это не считая нескольких проектов чисто для личного пользования.

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

кстати сказать, реализовать OpenGL View — весьма нетривиальная задача; именно поэтому я сделал отдельное окно. собственно, тут только один нормальный вариант реализации: перевести весь рендер на OpenGL, и вдобавок выделять каждому фрэйму свой задний буфер. иначе композитинг работать толком не будет.

вариант второй, кривой — использовать тот же трюк, который использует BBCB на винде, чтобы показывать нативные контролы, и получить всю кучу сопутствующих проблем. я планирую именно это. конечно, тут куча ограничений, и вдобавок проблема с тем, что поверх такого View нельзя класть другие views. то есть, можно, но их всё равно не будет видно.


и кстати, чтобы два раза не вставать: мне тут в процессе пришла мысль. а почему, собственно, не отказаться от gx, gy, unit, и не использовать вместо этого полноценную матрицу 2д-трансформаций? понятно, что в своё время это было слишком тормозно, но сейчас-то уже можно.

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


p.s.: и кстати, про OpenGL на шинде. в отличие от glX, в шынде динамически полученые адреса OpenGL API (то есть, почти все) могут отличаться для разных контекстов. это потрясающей силы идиотия, которая не позволяет один раз без привязки к контексту получить адрес и запомнить его (как сейчас делают мои бинды). так что технически на шынде возможно иметь только одно открытое окно с GL-контекстом, и по его закрытию все адреса API надо вайпать (такое действие в биндах предусмотрено).

риторический вопрос: почему шында такая удолбищная?