Лидеры

Для теста видеобуферов набросал максимально упрощенный рендерер для майноськи. Без поддержки изображений, прозрачности и транзиций - оставил лишь суровые прямоугольники и цветной текст: Плюсы: расход RAM упал до 25% на полностью инициализированную систему с загруженными (но не отрисованными) иконками. Для слабых машин это очень хороший показатель, и освободившиеся ресурсы можно было бы направить на прикладной многозадачный софт. Минусы: оно лагает сильнее, чем софтверное решение с графоном!11 Но, будем честны, я натягиваю сову на глобус. Концептуально фича крайне сочная, API удобное и не ломает старые проекты, написанные под прямую работу с GPU. Думаю, она будет идеальным решением для узкозадачных юишных софтин типа мониторилок реакторов, кнопочных контроллеров для умного дома, текстовых чатов или рисовалок - иными словами, для всего, что могло слегка подлагивать из-за прямой отрисовки. И если раньше надо было извращаться с порядком операций, экономя каждый тик, то теперь можно кодить гораздо комфортнее. Хотя мне все равно чуточку обидно. Но лишь чуточку.

Честно говоря, не очень понял, что имеется в виду. Поэтому на всякий случай проясню, что имел в виду я. Если замена in-Lua буферов на VRAM привнесла задержки на порядок, то виноват, скорее всего, некто из следующих элементов: Lua. Нативные либы собраны с -O0.... и заметно тормозны. Сюда же пойдёт хук для TLWY. Оверхед из-за интерфейса Lua ↔ Scala (об этом ниже). Бюджет вызовов, который могут потреблять прямые вызовы get на ненулевой буфер. Каждый прямой вызов, даже если он бесплатный (а он должен быть практически бесплатным, если активен ненулевой буфер), проходит через слой Lua ↔ Scala. Это значит запаковать аргументы, проверить их, передать в сишную функцию от JNLua, которая для каждого аргумента создаст жвм-объект, найти колбэк по адресу компонента и имени метода, сожрать 2-32 единиц бюджета, произвести диспатч в колбэк, внутри него обработать вызов, потом принять результаты, их нормализовать в поддерживаемые JNLua, отдать в нативную сишную функцию от JNLua, которая каждый принятый жвм-объект преобразует обратно в луа-значения и вернёт их, потом полученные значения запаковать, проверить, распаковать и вернуть. Я надеюсь, что даже при таком длинном описании на деле это займёт не особо длительное время (думаю, порядка сотни микросекунд; источник оценки — потолок), однако если произвести 16 тысяч таких вызовов, то оверхед может стать достаточно существенным. Именно про этот оверхед я и говорил. Я предполагаю, что софтверное склеивание тормозит из-за него. Если гадать ещё безбашеннее, то можно сказать, что хук для TLWY вообще практически бесплатен на фоне него. Аргумент против этой гипотезы: ожидаемая задержка (0.5–1.5 секунд) от полученной (3 секунды) отличается разительно. А bitblt действительно пожирает очень много единиц бюджета вызовов. Если точнее, то для копирования из буфера 160×50 на основной гпу третьего уровня сожрёт 1.5 единиц бюджета (то есть практически точно положит комп на тик). Если копировать из буфера, площадь которого больше максимального основного разрешения соответствующего уровня, комп вообще будет спать несколько тиков. P. S. В довольно древней версии оцелота есть гпу-буферы в том виде, в каком они оказались в OC 1.7.6, и график бюджета вызовов. Можно протестить прогу там.

Идея занятная, но тормозит люто. Подправил либу, после склейки дело дошло до рендеринга лишь спустя ~5 сек, то есть комп фактически виснет на процессе поиска пикселей со схожими цветами на тоннах вызовов setActiveBuffer/get. У меня вообще зародилось смутное подозрение, что все операции над буферами ни разу не zero cost даже с поправкой на искусственный троттлинг хука вызовов в machine.lua. И ладно бы вывод на экран - сам процесс рисования в буфер через setBackground/setForeground/set явно кушает бюджет. Как говорится, численно доказать не могу, но эмпирически чувствую

Поясни, в чем конкретно состоит проблема. Что именно не получается реализовать? Я не могу понять из твоих постов, что именно вызывает трудности. Предположим - у тебя каждый раз при старте консоль системы оказывается на непредсказуемом мониторе, и не факт что на том, где клавиатура. В таком случае можно просто положить в корень диска файл autorun.lua, который будет жестко биндить нужный монитор к основной видеокарте. Адреса можно вписать вручную, используя первые четыре уникальных символа адреса, и далее автоматически получая полный адрес в программе через команду component.get("xxxx"). (Будет полезен этот сайт: http://ocdoc.cil.li/api:component) Эвенты от мониторов (события touch/drag) и клавиатур (key_down/key_up) вообще обрабатываются вне зависимости от наличия привязанной видеокарты. Адрес компонента, который отправлил эвент, всегда идет вторым параметром в этом самом эвенте (как ты несомненно знаешь). На этом принципе работает моя программа Smart Lock. Она использует всего две видеокарты - одна привязана к "консольному монитору", через который пользователь может вводить команды с клавиатуры. Вторая видеокарта в любой момент работы программы может быть привязана к любому из нескольких десятков мониторов-замков в системе. В тот момент, когда пользователь "звонит" в дверь, программа определяет адрес монитора, с которого пришел "звонок" и биндит в нему видеокарту номер 2. Далее уже идет отрисовка графики через эту видеокарту на нужный монитор. Соответственно, когда приходит следующий звонок, видеокарта "перепривязывается" опять.

Если мониторы принадлежат разным компьютерам - можно разнести их распределителем или свитчем. Если мониторы и карты принадлежат одному компьютеру - надо биндить. Загвоздка в том, что если написать просто component.gpu.bind() - он обратится только к одной видеокарте - той, которую считает "основной". Поэтому сначала надо получить список видеокарт компьютера - их компонентов, точнее. local component = require('component') -- создаем таблички для хранения адресов компонентов local gpu = {} local screen = {} -- получаем список видеокарт for address, componentType in component.list("gpu") do table.insert(gpu, address) end -- получаем список мониторов (можно и вручную составить в принципе) for address, componentType in component.list("screen") do table.insert(screen, address) end -- биндим попарно -- (контрольные проверки не делаются, поэтому, во избежание ошибок, -- мониторов и карт должно быть одинаковое количество) for number, address in pairs(gpu) do component.proxy(address).bind(screen[number]) end Есть еще один путь - можно оставить в компьютере только одну видеокарту. И биндить ее к нужному монитору перед рисованием. Но тогда надо следить за разрешением (разрешение монитора при биндинге карты изменяется на разрешение карты).

эксперементальным путем выяснил, что используя метод use робот ставит блоки не только из руки но из первого слота своего интенторя, причем не зависимо от выбранного и приоритетьнее самой руки для которой казалось бы метод use и предназначен, и если аккуратно стать в перед робота, и использовать use то блок из руки поставиться на расстоянии один блок от робота, а если робот будет ставить тем же use из первого слота инвенторя, то так не пракатит и вернеться false, неужели первый слот инвенторя у робота работает как левая рука?

будет ли клавиатура в роботе работать без монитора(я могу проверить сам но шас дебажу(занят я кароч))