ECS

А, тогда понятно. В майноси чутка иная сериализация - вот и крашится, угу.11 Когда-нибудь, когда горы полетят по ветру, как опавшие листья... возможно, появится мыслишка с этим поколупаться. Но не сейчас точно. Чертовы Вексатосы!

Предложения годные, спасибо, учел в недавнем обновлении. Обнова вообще довольно жирная, кардинально меняющая принцип работы с библиотекой - все подробности в документации по ссылке выше. Метод удаления дочерних объектов имеется - object:delete() Поддержка Lua 5.3 также имеется в новой версии, однако учти, что округление катастрофически снижает производительность в тяжеловесных приложениях при расчете прозрачности и подобных операциях. Поэтому я лично остаюсь на шустренькой 5.2 Ресайз лейаута также реализован в новой версии - layout:setGridSize(int rowCount, int columnCount) Скроллинг сделаю чуть позже, а баг с экраном пофикшен, благодарочка Теперь что касается либ: крайне странно, что каким-то образом у тебя затронулась либа сериализации: инсталлер ее не устанавливает и никаким косвенным образом не затрагивает, да и все устанавливаемые либы имеют названия, не пересекающиеся с системными, что вдвойне удивительно. Далее об OpenPrograms - нет. Просто нет. Категорически-критичное "нет". Тысячу и один раз натыкался на проблемы, созданные авторами ОС и от меня не зависящие, тысячу и одну ночь ждал мержа фиксов, залитых к ним в пулл реквестах - и ни одного слова благодарности в ответ не получил. Нет, нет, нет... связываться с этим дерьмом себе дороже, а нервишки надо беречь. Только через свой инсталлер или вручную по ссылкам, только так.

Ах ты ж чертов педант. Ладно, ладно, исправил хд

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

Хочу поделиться с вами конвертером изображений, позволяющим использовать ограниченное пространство мониторов наиболее эффективным образом, а также библиотеками для быстрой отрисовки результата. Поддержка шрифта Брайля позволяет получать изображения размером до 320х200 визуальных точек при физическом ограничении мониторов в 160х50 символов, а алгоритм дизеринга помогает избавиться от визуальных ограничений 256-цветной палитры. Ссылка для загрузки конвертера: https://github.com/IgorTimofeev/OCIFImageConverter/raw/master/out/artifacts/ImageConverter_jar/ImageConverter.jar Команда для установки ПО для отрисовки: pastebin run ng73uZqT Практический пример: Чтобы отобразить картинку на экране, для начала ее необходимо сконвертировать и скопировать любым удобным образом на диск комьютера (напрямую в папку мира, через файловый хостинг и т.п.). В моем случае картинка называется Triss.pic: Затем напишем следующий код или запустим установившуюся программу draw.lua с аргументом "Triss.pic": local args = {...} local image = require("image") local buffer = require("doubleBuffering") -- Очищаем экранный буфер черным цветом buffer.clear(0x0) -- Загружаем и рисуем изображение в буфер buffer.image(1, 1, image.load(args[1])) -- Отрисовываем содержимое буфера в принудительном режиме buffer.draw(true)Результат не заставит себя ждать: Также привожу в качестве демонстрации несколько отрисованных изображений:

Хочу поделиться с вами объектно-ориентированной библиотекой, которую я использую повсеместно для написания программ с графическим интерфейсом. Все приложения со скриншотов выше реализованы с ее использованием, и если вам вдруг захочется накодить нечто подобное - то милости прошу. Подробная иллюстрированная документация, способы установки и множество практических примеров доступны по ссылке: https://github.com/IgorTimofeev/GUI/blob/0fadb161469d404d477dd9babfdc9a5aa42ff203/README.md

Здесь уже используется схожая концепция. Такой метод прост и надежен, однако в код добавляются избыточные данные - и если тебе захочется получить значение всех переменных из файлика, скажем, в пару тысяч строк, то и число маркеров будет соответствующим. Поэтому я ограничил просмотр значений переменных строкой текущего брейкпоинта.

Небольшая обновка: Добавлена алфавитно-типовая сортировка в файловом древе Улучшено удобство комментирования выделенных участков кода Улучшен алгоритм вывода стека ошибки и подсветки ошибочных строк Добавлена поддержка нескольких брейкпоинтов с возможностью продолжения/остановки выполнения программы

Сам с этой проблемой бился, толкового решения так и не нашел. Казалось бы, самый разумный вариант - это использовать функцию debug.getlocal для нужного уровня стека, которая недоступна в моде, либо использовать окружение в качестве аргумента к load, но, как ты и сказал, доступно лишь глобальное. Поэтому и пришлось делать выбор между двумя вариантами: либо выводить в качестве данных брейкпоинта только глобальные переменные, либо парсить выбранную строку. В качестве альтернативы можно разбить весь сырец на слова, исключив из них синтаксические - и отрисовывать жирную таблицу из всех существующих переменных с их значениями, однако загвоздка в том, что в этом случае будет получена куча переменных, которые могут быть вообще не объявлены на момент существования брейкпоинта. В общем, спорно все, спорно, надо думать.

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

Годнотища! Лабиринт особенно доставил.

При попытке открытия файла через io.open выдается либо файловый хендл, либо false с строковой причиной невозможности открытия файла (в нашем случае "not enough space"). Это и есть "адекватная ошибка". Судя по всему, в этом эмуляторе используется лишь один экран в блочном эквиваленте. Система старается избавиться от "черных полос" и подогнать разрешение экрана для комфортного использования. Пожалуй, выпилю эту фичу, добавив поддержку изменения разрешения вручную. UPD: Готово, так должно быть удобнее.

И не будет. Суть в том, что для создания прозрачности у меня используется функция блендинга цветовых каналов, впоследствии "упаковывающая" результирующие каналы в один цвет вида 0xRRGGBB. К сожалению, в Lua 5.3 бинарные операции работают исключительно с целыми числами, в то время как библиотека bit32 в Lua 5.2 поддерживает дробные. Пришлось делать выбор между увеличенной втрое скоростью отрисовки или вставкой округляющих операций с возможностью использования Lua 5.3. Я выбрал первое, не жалею.

Занятно. Саму синтаксическую опечатку исправил, однако причина неверной URL мне не ясна. Только что без каких-либо проблем поставил программку на абсолютно чистую опенось: Как вариант - на эмуляторе ОС иным образом работает интернет-компонент, иных причин не вижу.

Команда для установки: pastebin run z7S75BBP Чтобы запустить программу после того, как инсталлер загрузит все необходимые компоненты, используйте ​/MineCode/MineCode.lua или /MineCode/MineCode.lua open <путь к файлу> О программе: Честно говоря, первый раз увидев дефолтный редактор опенкомпов, у меня задергался левый глаз. Поэтому, недолго думая, мы с товарищами решили написать полноценную среду разработки, заточенную под удобство использования и максимальное быстродействие. Итак, первое и самое главное на мой взгляд - это подсветка Lua-синтаксиса. Теперь кодер может хотя бы визуально отличать одну часть кода от другой без напряжения зрения. Все цвета являются настраиваемыми, их можно изменять под локальный "вкус и цвет" пользователя. Имеется возможность отключения подсветки при помощи кнопки "◌" если вы играете на низкопроизводительном сервере. Второе в моем субъективном списке "полезности" - это запуск приложений в реальном времени, не отрываясь от процесса их написания. Просто нажимаете на кнопку "▷" и получаете результат: Третья полезность среды разработки - это автоматическое дополнение вводимой информации по аналогии с технологией IntelliSense. Кроме того, все вводимые скобки и кавычки будут также автоматически дополняться их "закрывающими" эквивалентами, с удалением это также работает. Для экономии памяти и увеличения производительности обе фичи можно отключить: При возникновении любой ошибки в вашем приложении MineCode IDE автоматически вернет вас к разработке, выдав подробный стек ошибки и подсветив ошибочную строку: Четвертая наиболее полезная функция - это отладчик. Он позволяет вам выставлять так называемые "брейкпоинты" путем нажатия на кнопку "*" и узнавать, какое значение принимает та или иная переменная в исполняемом скрипте. После каждого "брейкпоинта" выполнение программы может быть продолжено или приостановлено: Пятая фича программы - это возможность полноценного выделения и копипастинга, которого так не хватает в стандартном редакторе OpenOS: Выделенные участки кода можно комментировать, табулировать и детабулировать - все как во "взрослых" редакторах кода. Чтобы выделить слово, достаточно кликнуть по нему дважды. Также имеется удобный инструмент для работы с вводимым цветом в шестнадцатеричном формате. Выделяете его - выбираете соответствующую опцию контекстного меню и получаете результат: Разумеется, мы также реализовали виджет поиска по коду с возможностью переключения чувствительности к регистру: Среди прочих функций стоит отметить удобное древо навигации по файловой системе, возможность загрузки файла из интернета, возможность смены цвета и стиля курсора, возможность отключения всех панелей инструментов, возможность быстрой навигации по различным критериям, возможности изменения разрешения экрана, наличие всевозможных клавиатурных шорткатов и ссылок на них в соответствующих пунктах меню. Также отдельно хотелось бы отметить всех людей, так или иначе принимавших участие в разработке и отладке программы: Вся программа целиком и полностью работает на интерфейсной библиотеке GUI и библиотеке тройной буферизации. Исходный код доступен на GitHub: Библиотека DoubleBuffering Библиотека GUI Библиотека Windows MineCode IDE Напоследок скажу, что, разумеется, куда удобнее и практичнее редактировать большие файлы напрямую в предпочтительном для вас редакторе кода, однако при отсутствии возможности прямой заливки файлов на сервер и для экономии времени MineCode IDE становится незаменимым инструментом для разработки простого ПО.

Не-а, увы. Вершинные шейдеры можно без проблем запилить, на производительности не сильно скажется. С пиксельными уже беда, даже не смотря на то, что в плане оптимизаций тут вылизано все, вплоть до каждой мат. операции. Пробовал, и не я один. Объединение компов в расчетный кластер невозможно по той лишь причине, что низкая скорость обмена данными между компами не компенсируется увеличенной производительностью. Как вариант - можно использовать постоянное TCP-соединение для пересылки информации на внешний сервер и наоборот, это будет значительно быстрее. Аналогичная ситуация с низкой скоростью передачи возникает через обработку информации на внешнем сервере. Кроме того, не забываем, что основная нагрузка не в скорости расчета местных ЦП, а в сильно ограниченных ресурсах GPU. Частично их компенсирует тройная буферизация, но все же магии тут ждать не стоит.

Сложно сказать наверняка, для чего он предназначен. Имхо, если софтина пашет с достаточной производительностью, не вызывая нервного тика - то она вполне пригодна для мода. Хотя тут, конечно, можно довольно долго философствовать.

Команда для установки: pastebin run LcurLpLE Инсталлер загрузит массу необходимых библиотек, а само приложение имеет название "3DTest.lua", загружаясь в текущую директорию. Немного истории: Сидели мы зимними вечерами с товарищами, кодили всякую чушь - и пришла в голову мысля о потенциальной возможности рендера реалистичной 3д-графики на всем нам известном моде. Попотели пару недель, и в итоге получилось вот это. Прежде всего нами была написала библиотека для рендеринга статичных сцен с поддержкой перспективной коррекции, динамического освещения, текстурирования и z-буферизации кадра. Пришлось вспоминать школьный курс векторной математики и немного гуглить, но в целом ничего сложного тут нет. По сути у нас получился упрощенный OpenGL, оптимизированный для работы на низкопроизводительных машинах. Далее мы написали сам игровой движок с громким названием PolyCatEngine, позволяющий создавать произвольные меши любых форм с индивидуальными координатыми системами и свойствами материалов, реализующий виртуальную камеру и триангулярный рейкастинг. Под самый конец мы реализовали воксельную структуру а-ля Minecraft, симулирующую кубический мир с возможностью установки и удаления "блоков". В качестве финального штриха мы добавили приятный пользовательский интерфейс для взаимодействия с возможностями движка, работающий на ООП-стилизованной библиотеке GUI. Сама отрисовка графики реализована на нашей уже выложенной на форуме библиотеке тройной буферизации. Вот несколько примеров визуальных возможностей движка: Как результат мы имеем довольно приятную картинку и сносную производительность на мощных серверах (около 7 реальных FPS в зависимости от конкретной машины). Программа требует всего лишь 1.5 МБ оперативной памяти, однако рекомендуется запускать ее на серверных стойках с 4 планками памяти уровня 3.5 для получения максимального комфорта и увеличения максимального количества объектов сцены. Все сырцы доступны на GitHub, прикладываю основные ссылки для интересующихся: Библиотека DoubleBuffering Библиотека OpenComputersGL Библиотека PolyCatEngine Библиотека Vector Библиотека Matrix Библиотека GUI Библиотека Windows Сама программа Возможности программы: С помощью клавиатуры осуществляется навигация камеры, с помощью мыши устанавливаются и удаляются блоки в мире. В правой части экрана вы можете выбрать различные опции рендера - к примеру, включив полигональную сетку или подсветку вершин. Также вы можете выбрать цвет текущего устанавливаемого блока: Имеется возможность добавления неограниченного количества источников освещения, каждый из которых имеет индивидуальные параметры дистанции шейдинга и яркости: В качестве приятного бонуса имеется возможность мониторинга расхода оперативной памяти и изменения цвета фона сцены. В левой части экрана отображается отладочная информация и описание горячих клавиш программы: Напоследок добавлю, что результирующая производительность сильно зависит от пинга и мощности сервера/домашнего ПК игрока, так что шокирующих результатов от этого ждать все же не стоит. Как бы то ни было, желаю вам приятного пользования.

Самое главное-то забыл упомянуть. По сути каждая библиотека - это банальный массив, который возвращается после исполнения файла. А любая функция, загружающая файлы, будь то require, load или dofile, преобразует содержимое файла в самую обычную функцию и исполняет ее, а из этой функции идет возврат содержимого библиотеки. Это очень тонкий момент, который крайне необходим для понимания сути Lua. А то делаем всякие return'ы, а новички не понимают, для чего оно надо. Также стоит добавить, что функция require("имяЛибы") постоянно хранит загруженную библиотеку в package.loaded.имяЛибы. То есть если ты изменишь исходник библиотеки, то изменения не вступят в силу до перезагрузки компьютера, либо до принудительного присвоения package.loaded.имяЛибы = nil. Это далеко не всегда удобно, и лично я предпочитаю использовать классический load(). Кроме того, вовсе необязательно хранить библиотеку в указанных Neo директориях. Я свободный человек, и могу закидывать свои файлы куда пожелаю, а функция require() поддерживает любой указанный путь. А если файл из указанного пути не найден - она начнет искать его в стандартных путях для библиотек.

В описание добавлены новые и не указанные ранее методы:

https://www.youtube.com/watch?v=Efu0lEsMuMw&feature=youtu.be Решил я на днях потестировать нашу библиотеку двойного буфера в каких-то серьезных задачах, связанных с быстрой отрисовкой. Идеальным примером послужит любая игра, поэтому для теста решил я накодить Flappy Bird. Никаких особых пояснений игра не требует - смотрите демонстрационное видео выше. Команда для установки: pastebin run tsrGcmsa

Большое обновление: Программа полностью переведена на систему двойного буфера и библиотеку image, скорость отрисовки увеличена в 15 - 20 раз Добавлена поддержка нового метода кодирования изображений, суммарный объем файла при сохранении уменьшен в 1.8 - 6.2 раза в зависимости от количества цветов. Ниже представлены два одинаковых изображения, созданных с новым и старым методами кодирования: Добавлены функции обрезки, расширения (изменения размера холста), поворота и отражения изображений: Добавлены функции работы с цветом: цветовой тон/насыщенность, цветовой баланс, фотофильтр: Добавлено центрирование изображения при создании нового файла или открытии существующего:

Небольшое, но крайне емкое обновление: Увеличена скорость отрисовки в 1.5 - 2 раза посредством добавления третьего промежуточного буфера Уменьшено количество обращений к CPU, уменьшено число операций сложения/вычитания Улучшена система конвертации индексов Добавлено больше благодарных комментариев в коде, славящих @Krutoy за помощь в разработке. Ну, и, собственно, демонстрация скорости работы: http://www.youtube.com/watch?v=HrIA9kMjQvg

Небольшой апдейт: Добавлена возможность не подключать проектор и работать только с GUI Добавлена возможность быстрого открытия модели через 3DPrint.lua open <путь к модели> Добавлена поддержка формата .3dm в MineOS: Исправлено некорректное отображение моделей, созданных в других редакторах: Добавлена возможность выбора количества блоков для печати: Добавлена возможность выставлять "отступ" проекции по трем осям, чтобы сам проектор можно было спрятать под полом:

Известный бажок, фиксим, спасибо. Хрен с ними, нечего именовать по-русски. Ишь ты, патриот выискался! Видимо, в 5.3 выпилили библиотеку bit32, надо будет добавить ее принудительную загрузку с гита, годное замечание.