Jakowlew

Я, конечно, ни на что не намекаю, но за 23 дня дальше лицензии ничего не продвинулось :))

Для С++ использовал прекрасную библиотеку sol. Это очень удобная и функциональная обертка над сишной либой

Пожалуй это и сделаю

Это решается кодированием Хаффмана. Можно реализовать, если это востребовано

Как писал выше, можно сделать урезанный аналог ворда с урезанным .rtf, ну или своим форматом. Но ценность сомнительна, да и у того же ECS есть редактор с подсветкой Lua кода. Вот это можно доработать и будет прикольно

Так играть то не интересно. Я вообще сам майнкрафт как игру не люблю, как бы странно это не звучало. Мне очень нравится хардкорное программирование. Тут есть кривой язык (Lua, конечно, крутой скриптовый язык сценариев для игр, но полноценный софт на нем писать не надо), ограничения по памяти, дравколлам, процессору. И сообществу по факту предлагается написать свою инфраструктуру, свой софт, который является пародией на реальные аналоги. Это интересно как отдых, развлечение, не больше. Никакой практической ценности, чистый фан. И мне автоматизировать робота скучно. Это ближе к игре, чем к чистому программированию. А вот решать сложные задачи в таких спартанских условиях действительно весело.

Да ну, уже столько сетей написали. Даже на этом форуме видел несколько реализаций. А настоящий браузер в ОС не реализовать. Просто не хватит ресурсов, причем катастрофически. Можно сделать отображение голого HTML, мб с некоторыми стилями CSS, не более. Но это тогда получается текстовый редактор, а-ля кастрированный .rtf для майнкрафта. Интересно, конечно, софт из реальной жизни переносить в мод, но по большей части это невозможно, к сожалению.

Ну почему, можно сделать полосы прокрутки, это не критично Картинки ужимать. Самое сложное - реализовать DOM и прикрутить JS. Вроде есть компилятор JS в Lua, но сколько это все памяти будет кушать - неизвестно, но явно больше 4мб

Да что такое :с Все уже написано. Даже для мода на майнкрафт. Я разочаровался :с И что, нет никаких нереализованных проблем? Серьезно?

Да? Ну, ладно. За 40 секунд просмотра кода я этого не понял. Печально. Хотел крутую новую фичу запилить, а ее до меня сделали :с Мб что-то еще есть крутое и нереализованное? А то руки чешутся, а копировать кого-то смысла большого не вижу. З.Ы. Браузер тоже сделали?

Я вообще на C# планировал, питон не знаю. А какие проблемы с аудиодорожкой возникают? Так же команды для звуковой карты отсылать, и сойдет. Хотя из-за фризов звук может отставать или вперед убегать

Вот, спасибо. Я забыл. nil выкидывает ошибку, я имел в виду NaN.

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

Писал же, что знаком с модом месяц, и практически ничего не знаю о наличии внешних библиотек. Но все же, как обстоит дело со стримами и SLI?

Привет, месяц назад случайно наткнулся на OC, очень доставляет возможность изобретения велосипедов и экстремальной оптимизации. Не знаю, насколько актуальна тема, но все же. Как вы относитесь к воспроизведению видео в OC? Я хочу написать веб-сервис/десктопную утилиту, которая будет перекодировать видео в последовательность вызовов для GPU. Т.е. на вход подается гифка, или видео с ютуба, на выходе - максимально оптимизированная последовательность вызовов отрисовки GPU. Можно сделать кучу настроек, типа цветности, набора символов, разрешения, вывода команд для GPU в SLI/нескольких компах, подключенных к одному экрану, и т.д. А в случае веб-сервиса можно это на лету делать, организовывая своеобразный "стрим". Под все это могу и плеер на Lua под опенось написать. Можно будет на серверах проигрывать видосики, мб даже со звуком, если руки дойдут. Но это требует достаточно больших усилий, а в случае веб-сервиса еще и материальных вложений. Насколько это востребовано? Будете ли вы лично пользоваться этим? Если много человек нуждается в подобном, то это придаст мотивации, и заставит реализовать задуманное, иначе в этом смысла нет.

Разве? Вроде nil трактуется как ложное значение, и результат операций с ним будет всегда ложный, нет?

Можно сделать транслятор в Си код, который потом компилируется, вопрос в том, насколько это надо. Код все же для опенкомпов писался

Ой как не хочется мучаться с сетью и параллельным выполнением. Я по фану написал за 20 минут интерпретатор brainfuck, чтобы запустить на нем интерпретатор brainfuck, написанный на brainfuck, а в нем еще один, и еще, и еще. А потом посмотрел, как это все работает, сказал себе "малаца" и запостил сюда

Brainfuck? Почему бы нет? Если вы не знаете, что это, то вот ссыль: https://ru.wikipedia.org/wiki/Brainfuck А вот и сам интерпретатор: https://pastebin.com/DVNbB7Rf Текущая версия: 1.0 Документация:

@eu_tomat@ECS Упаковал минифайером, чтобы скрипт меньше места занимал. Залил полную версию. Судя по тестам, при кол-ве элементов около 1000 все происходит буквально мнгновенно, при кол-ве около 10000 - за сотые доли секунды. Тестил все не в опенкомпах, а на своем стареньком ноутбуке, Pentium dual-core, 1.3Ггц на ядро. Но в целом, упаковка/распаковка происходят в ~20-25 раз медленнее, чем при работе с обычными таблицами, причем время вроде как должно линейно расти при увеличении элементов чанка. Но, думаю, даже опенкомпы разницы при размере в 1000-2000 не заметят. Касаемо памяти, тут все не однозначно. В пиковом потреблении памяти тратится больше примерно в 2-3 раза при небольшой длине массива. При n = 100000 память даже в пике тратится в 2.2 раза меньше, при n = 23000-24000 затраты одинаковы. В нормальном состоянии при записи 8-битных данных выигрыш начинается уже при n = 20-25 На данный момент библиотеку целесообразно использовать при хранении реально большого кол-ва данных или там, где эти данные читаются/пишутся не очень часто. Я думаю, как можно уменьшить пиковое потребление, возможно хранить неизменяемые данные в строках, или отказаться от чанков и хранить только однородные данные

Эта библиотека может быть полезна, если вы работаете с большим количеством числовых данных. Основная цель - сэкономить память при хранении данных в небольшом диапазоне. Как известно, в Lua целое число занимает 64 бита и может принимать значения от -2^32 до 2^32-1. Такой огромный диапазон практически никогда не нужен и память расходуется впустую. Что если мы попробуем упаковать несколько маленьких чисел в одно большое? Скачать библиотеку можно здесь: https://pastebin.com/WLmJ19QJ Возможны изменения и доработка, так что проверяйте время от времени пастебин на наличие новой версии Текущая версия: 1.1 1.0: Первая версия, добавлены все основные методы 1.1: Добавлены методы barr:writeArray(array:table) и barr:readArray(pos:number, n:number):number Пример: Пример 2: Если вы еще не устали, то вот подробная документация для задротов: Когда использовать barr? Каждый пустой экземпляр barr занимает как минимум 48 байт и 544 как максимум (если порция состоит из 64 1-битовых полей, в таком случае лучше использовать порцию из 1 1-битового поля, тогда размер barr будет 48 байт). Таким образом barr помогает при достаточно большом объеме данных, выигрыш от экономии которых нивелирует затраты на размер пустого экземпляра и 8 байт на каждую новую порцию. Как и писалось выше, можно максимальная экономия памяти составляет практически 64 раза. Если это кому-то понадобится, то библиотека будет развиваться и обновляться. Все изменения буду дописывать сюда. Актуальная версия библиотеки тоже будет отображаться Тесты: Тесты проводились на чистом Lua 5.3 Код самого теста: Результаты тестов:

Объясните дураку, как скачать библиотеку? Я потратил 15 минут и не нашел в четырежды просмотренном посте ссылку на саму либу, только на зависимости. И такое почти во всех темах с библиотеками. ГДЕ ОНИ ХРАНЯТСЯ? ОТКУДА ИХ КАЧАТЬ?

Примерно так я и собирался это реализовать "A GPU can only be bound to one screen at time" - Одна гпушка может быть привязана только к одному экрану. Про привязывание нескольких гпу к тому же экрану ничего не сказано. Собственно отсюда мой вопрос и вытекал, вроде можно, а вроде и нет. А черная магия непонятно что делает

На самом деле вопрос производительности вторичен. В крайнем случае можно с двух разных компьютеров рисовать в один экран. Проблема остается такая же: как несколько видеокарт / разных компьютеров подключить к одному экрану?

Привет. Два дня назад я наткнулся на чей-то гайд по OpenComputers. Я майнкрафт не очень люблю и последние лет пять в него не заходил, но я люблю программировать, а полноценные компьютеры в игре мне очень понравились Но перейдем к делу: как заставить две видеокарты работать с одним экраном? Я храню компоненты в массиве и это не работает: for i = 1, #gpu do gpu[i].bind(screen.address) gpu[i].set(1, i, tostring("GPU ", i)) end В документации написано, что нельзя одну видеокарту подключать к нескольким мониторам, но про обратное действие ничего нет. Проблему решить хотелось сильно, и опытным путем я установил, что вот так все работает gpu[1].bind(screen.address) gpu[1].set(1, 1, tostring("GPU ", 1)) -- WTF??? -- print("") gpu[2].bind(screen.address) gpu[2].set(1, 2, tostring("GPU ", 2)) Что за черная магия здесь происходит? И вообще, есть ли смысл привязки нескольких видеокарт к одному экрану ради обхода ограничения на отрисовку?