>>7565
> phpшники не программисты. Навидался я на них.
Чиочую.
Похапешник - это дизайнер, проектировщик баз данных, проектировщик интерфейсов - кто угодно, но не программист.

Можно я тут потестирую кое-что? С сажей тред не должен подняться. Спасибо

>>7520
10 лет посту!

>>26485
А джаббер еще жив!

>>26485
Я-то думаю чего доска такая живая вдруг. Не написал ОП свой космосимулятор...

>>26500
Просто за него хардкорный космосимулятор написали в Мексике.

>>26500
Возможно, он осилил и перешел на высший уровень бытия. И ему уже не до нас, в солнечной Калифорнии.

Извиняюся, но у меня кнопочка "quick reply" не вставляет ссылку на пост в месседж бокс. И еще когда наводишь мышку на реплаи, то всплывает красненькое окошечко с надписью "500 internal server error".
Что-то криво поставилося?

>>22478
Так же кнопочки "удалить, закрепить, закрыть, открыть" тоже выдает ошибку 500.
Еще кнопочка stuff выдает пик.

>>22478>>22479
Спасибо за багрепорт. Все исправлено (некоторое время назад).
Страница Staff выдавала ошибку из-за того, что не было добавлено ни одной роли (manage/roles), и вместо пустого массива у юзера роли были undefined. По той же причине не работали попапы. Теперь работает и без ролей.
Быстрого ответа просто не было запилено, теперь он есть.

>>22591
Спасибо!
Но теперь оно постить отказывается :3

>>22636
Еще одна тупая ошибка, которая проявляется только на пустой доске. Исправлено.
Добавлена новая фича - редактор стилей. Дополнительные темы можно клепать прямо через админку.
Так же обновлен node.js и все остальное. Контейнеры необходимо пересобрать командой -d --force-recreate --build

>>22641
> docker-compose up -d --force-recreate --build
fix

GJ

>>20392
Чего ещё расскажешь?

Запилено:

• Двухступенчатая архитектура, из брокера подключений и бекенда, реализующего логику.
• Подключение по ssh, после /регистрации своего ssh-ключа в плейнтекстовой моде
• Персистентность, история, мемосерв.

Вот уже пять дней у меня работает tmux с запущенным в нём

nc breathe.network 31337

. Чат пустует и на мои сообщения никто не отвечает. Команда

/list

возвращает

 def#1348 -- 2022-05-15 11:21:4

>>26040
Когда в последний раз смотрел там было много второго.

Самые интересные варианты: Ren'Py и Unity.

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

Второй же осваивается сложнее, дольше, но более вариативен, конечный продукт получится более оптимизированным, порт на мобильные/нинтендо заставляет запариться, но получается более качественным. Да и С# приятнее язык, имхо.

Под Unity есть ассет Fungus, что упрощает создание новеллы в разы. Но всегда лучше сделать что-то свое и чисто под себя, не так ли?

>>26061

>Нинтендо
Это я вброс сделал, никогда таким не занимался и не интересовался даже. Знаю только, что возможность есть такая, но о процессе и связанных проблемах ничего не ведаю.

>>26061
Каво там оптимизирован? Unity по сравнению с рин паем?

Почему все так стремятся создавать игры? Мне кажется, что системное программирование должно быть намного интереснее, т.к. это всякие хакерские штучки, но тут проблема только в том, что требуется большое количество глубоких знаний из разных областей компьютерных наук. Либо я сам себя загоняю, отчего забросил. Но формошлёпание и программирование мышкой меня как-то не привлекает.

Если же брать во внимание какие игры меня интересуют, то тут для создания самолётика нужно тоже знать кучу всего, причём без высшего технического образования не обойтись, — та же работа РПО должна представлять собой симуляцию течения масла + симуляцию работы лопастей винта, а иначе она не будет приближённой к реальности. Собственно, поэтому полноценная реализация вертолётов и винтовых самолётов есть только в одной игре DCS, т.к. там очень хитрый матан (и это же единственный авиасим, где есть износ покрышек как в автосимуляторах, если я не ошибаюсь) Но у меня не такой мощный комп, чтобы играть в этом, а также модули в нём дороговаты + простенького джойстика будет недостаточно, отчего попробовать такое элитарное увлечение можно будет лишь тогда, когда найду оплачиваемую работу, а сейчас остаётся лишь смотреть как летают на "Ютубе", да довольствоваться примитивными в 2022 году "старичком" и FS 2004.

>>26033
> Renpy
Зачем нужен Ren'Py, если можно объектов на форму нашлёпать?

>>26032
Игры - это всё меньше и меньше про разработку. Особенно визуальные новеллы. Тут нужно быть художником, сценаристом, ну и техническим художником (technical artist). А программирование тут дело десятое или двадцатое. При наличии скиллов в 3д дизайне/графике, готовых ассетов, арта, проггера можно найти, чтобы он по косому диздоку всё это слепил вместе. Лепить наверное лучше в ютини, потому что современно, потому что громадное комьюнити, потому что огромный инструментарий, убирающий необходимость кодить каждую второстепенную вещь.

>>26142
Программирование мышкой, короче.

Репозиторий вроде все еще жив
https://github.com/WagonOfDoubt/iichan-extensions
И в контрибуторах есть Мицгол, который еще с нами, так что шансы на починку есть.

>>25694

Эппловскихъ устройств не имѣю, ѿлаживать негдѣ.

>>25693
Учитывая обстоятельства >>25705 получается, надо создавать issue на гитхабе, чтобы хоть как-то обратить на проблему внимание.

Кстати, ни у кого не осталось кода для поддержки ЎэбП, который когда-то постили в /d/? Или какой-нибудь новый кот для этого.

>>25770

http://ii.yakuji.moe/d/res/250303.html#251062

Упомянутая в сообщении >>20993 проблема https://trac.ffmpeg.org/ticket/7613 исправлена разработчиками FFmpeg, и предположительный срок её исправления оказался даже больше того, насчёт которого я мрачно подозревал в сообщении >>21078: не только до середины 2021 года, но даже и до февраля 2022 года поневоле пришлось дожидаться.

Дополнительные подробности я изложил в сообщениях https://t.me/ReadMithgol/476 и https://t.me/ReadMithgol/478 в Телеграме, растровые копии которых я прилагаю и тут, но только по одной (а не то итог склеивания их по вертикали, весьма вѣроятно, натолкнулся бы на препятствие >>/d/2649 при малѣйшей попытке помѣстить его на 410чан).

Второе приложение к сообщению >>26119.

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

Узнал сейчас про object pooling. Если один и тот же объект планируется создавать и удалять много раз, то гораздо оптимальнее будет инстанциировать лист этих объектов и сделать каждый из них неактивным. Далее, в момент когда объект необходим в сцене, из пула берется один из его инстансов и делается активным. При этом могут меняться некоторые из его параметров (например позиция).

Ну и соответственно, если активный объект больше не нужен, но не удаляется, а делается неактивным. Пул всегда возвращает один из неактивных объектов, то есть не используемых в данный момент.

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

Unity вкатывается в настоящую мультипоточность и асинхронность. В то время как в мире микросервисов это давно стандарт, в таких больших проектах похоже не так все просто.

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

Основная фишка тут в том, что подобный подход требует изменений в структурах пользовательского кода и объектов. Для этого были придуманы конверторы, и это вылилось в отдельную версию редактора. Пользователь работает с игровыми объектами и их компонентами, как и раньше. А дальше они сами конвертируются в “новые” сущности и компоненты (Entity Component System) для работы с ними в коде.

Ну и в коде, в связи с этим, уже нет работы с игровыми объектами в их обычном понимании, а с компонентами напрямую, которые в свою очередь уже содержат какие-то данные (например позиция, скорость). Отсюда этот подход получил название Data-Oriented Technology Stack. Классы теперь наследуются не от MonoBehaviour, а от JobComponentSystem.

https://unity.com/dots
Ну и разумеется, все это стало гораздо производительнее, и стало возможным делать сложные сцены, работающие даже на мобилках https://www.youtube.com/watch?v=KgcU2HBOXAw

Погуглил больше про ECS.

Концепция сама существует давно и не является изобретением Unity, но уже DOTS - их термин. Она сама по себе не про производительность, а про подход к описанию игрового мира и взаимодействий в нем.

В ECS игровые объекты не наследуют кучу всего и не создаются со статичной кучей параметров и компонентов, существующих вплоть о момента удаления объекта. В ECS игровые объекты - просто entities, некие изначально пустые "сущности", играющие роль уникальных идентификаторов.

Параметры игровых объектов (например, здоровье, скорость, "прыгучесть", etc) являются самостоятельными компонентами (components), не привязанными ни к какому объекту статично. Они могут назначаться каким-либо entities, если им необходимо данное поведение/характеристика. Причем эта привязка или отвязка происходят в рантайме, что позволяет делать классные вещи в виде изменения казалось бы статичных характеристик игрового мира в уже работающих клиентах.

Системы (systems) содержат уже логику, обрабатывающую данные из компонентов. Можно думать о них, как о контроллерах. Важно то, что системы не завязаны на конкретных компонентах и entities. По крайней мере в юнити, как я понял, системы могу выбирать entities на основе привязанных к ним компонентов (entity query) и тем самым всегда работают с группой entities. Поэтому в коде много foreach :)

В этой концепции Entities, Components и Systems - вещи изначально существующие обособленно друг от друга, и им нужны отдельные средства коммуникации. И тут уже все зависит от конкретной имплементации.

Разобрался со сценами и переходами между ними. Сцена - это некая уникальная инстанция мира. В зависимости от сложности игры может быть отдельным уровнем, может быть целым открытым миром. Или это может быть просто menu screen.

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

Персист данных между сессиями (между разными запусками игры) сложнее. Причем не потому, что надо писать в файл или работать с другими внешними сущностями. А потому что надо постоянно думать, могут ли внутренние структуры быть сериализированы. В шарпе не все так однозначно. Обычный array, например, может быть сериализирован в json, List уже нет. Хотя BinaryFormatter с ним справляется без проблем.

бамп

Стив, как дела, продвигается ли изучение?

>>25670
Забил на какое-то время. Переезды, смена работы и всё такое
Ещё как закончил курс junior programmer, у меня случился overwhelm от осознания уровня необходимых скиллов (которые нужно качать и качать 100500 лет как в олдскулл ммо), что демотивировало продолжать процесс.

Недавно появилось желание раздропнуть. Начал новый курс Creative core. Посматриваю на применения Юнити в не-игровых индустриях, изучаю какие есть наработки в AR, webrtc, нативная интеграция в мобилках и всё такое.

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

>>25030
Я конечно понимаю, что бесконечное копание ассемблерного кода это самоцель проекта, но почему бы по-быстрому не набросать то же самое на юнити. Мне кажется концепт сам по себе вполне играбелен, и достоин того, чтобы принять более-менее оконченный вид.

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

>>25117
Я не буквально «бесконечно копаюсь в ассемблерном коде» (хотя и занимаюсь чем-то близким по осмысленности), я и ассемблер-то почти не знаю. Просто написал под впечатлением, что вот, смотрите, интринсики завезли. BTW:
>>25030
>10 лет прошло ... Технологии рендера изменились до неузнаваемости.
Всё ясно, автору 10 лет.
Да нет, почти всё придумано в прошлом веке. ЭВМ Наири-3 поддерживала разделение времени и эмуляцию других ЭВМ. Рейтрейсинг и нейросети использовали ещё раньше.

>занимаюсь чем-то близким по осмысленности
Например, я буквально пару дней назад догадался сделать хранение базиса касательного пространства в вершине не обычными 2 векторами (нормаль + касательная, 3-й восстанавливается в шейдере через их cross), а кватернионом, т. к. этот базис, в предположении, что не может быть разортонормализован или отражён, представляет собой поворот некоторого исходного базиса — скажем, X = (1, 0, 0), Y = (0, 1, 0), Z = (0, 0, 1).

Ну, это старая идея и я давно читал про неё, но мне не хватало точности при хранении кватерниона как непосредственных X, Y, Z в 10-10-10 битах с восстановлением в шейдере W через √(1−x²−y²−z²), а хранить с лучшей точностью смысла нет (не будет выигрыша относительно 2 векторов). Теперь же я прочитал про идею (вот здесь в конце: https://archive.org/stream/GDC2015McAuley/GDC2015-McAuley_djvu.txt) отбрасывать не W, а максимальный по модулю компонент, и в 2-битовом W сохранить индекс отброшенного компонента. То есть кватернион (X, Y, Z, W) пакуется в один из вариантов:

(Y, Z,&

Сообщение слишком длинное. Полный текст.

Тред умер?

>>26014
А ты думал, аффтору потребовалось если ответить 4 месяца на вопрос о пропаже билдов, и так их и не залить.
Но вроде что-то пилит.

>>26014 >>26015
Сказал же буквально на днях, всё будет, хорош шуметь.
>Третий тролль сказал: «Прощайте! Ненавижу болтунов».

За прошлый год я, хотя ничего не делал, стал парадоксальным образом в промышленных масштабах натыкаться на баги Free Pascal, отчего потерял терпение и повадился громко плакать о них на багтрекере в противоположность тому, как ранее натыкался на них раз в год и обходил переформулированием кода. Последние две недели плотно занимался https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/179, а вообще из всего, в чём засветился, мне больше всего нравится https://gitlab.com/freepascal.org/fpc/source/-/issues/39360 («копание в ассемблерном коде», да). Не подумайте, мне были жесть как нужны, соответственно, карманная база Юникода и ускорение генерации шума Перлина до уровня, когда текстуру с ним можно генерировать на месте, а не таскать с собой, здесь нет никаких проблем с приоритетами. Ну или, может, и есть самая малость, но кто сказал, что я прямо сейчас не возьму и не пойду дорисовывать Сырну?!

>>26016
>Сказал же буквально на днях
Где??
Но вообще, контрибы в язык - это ты малаца, завидно даже.

> какие ID у картинок с тегами t1,...,tn, но без тегов e1,...,en
Создаешь инвертированный индекс, где к каждому тегу привязана кишка с айдишниками соответствующих документов. Итерируешься по одной из кишок (ты можешь выбрать самую короткую), получаешь сложность O(длина кишки). Так делается в больших нагруженных поисковых системах.
> на странице с оффсетом 12000
Добавляешь еще один тег (поисковый литерал), означающий номер страницы.

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

О, а мысль протегировать страницы мне не приходила в голову.

>>25954
Разве такое не должно быть уже решено в СУБД?
Но гляньте https://roaringbitmap.org/
Если в кратце, для каждого тэга храним сжатый битовый массив, для выполнения запроса and-аем чанки этих массивов между собой, делая popcnt по результату, пока не достигнем нужный offset.

Моя бура состоит из двух TSV текстовых файлов вида тэг|хэш и хэш|путь-к-файлу, которые я грепаю скритом.

What is O(1), is it tasty

Странную продолжительность имеют пятый и десятый трек(пикрил).

REM GENRE New Wave, Post-Punk
REM DATE 2019 (1979)
REM COUNTRY EU
REM LABEL Factory
REM CATALOG FACT 10 40
REM ASDFVL_VinylRip
PERFORMER "Joy Division"
TITLE "Unknown Pleasures"
FILE "Joy Division - Unknown Pleasures - Side A.flac" WAVE
TRACK 01 AUDIO
TITLE "Disorder"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Day Of The Lords"
INDEX 01 03:31:35
TRACK 03 AUDIO
TITLE "Candidate"
INDEX 01 08:20:00
TRACK 04 AUDIO
TITLE "Insight"
INDEX 01 11:27:00
TRACK 05 AUDIO
TITLE "New Dawn Fades"
INDEX 01 15:52:00
FILE "Joy Division - Unknown Pleasures - Side B.flac" WAVE
TRACK 06 AUDIO
TITLE "She's Lost Control"
INDEX 01 00:00:00
TRACK 07 AUDIO
TITLE "Shadowplay"
INDEX 01 03:56:00
TRACK 08 AUDIO
TITLE "Wilderness"
INDEX 01 07:51:00
TRACK 09 AUDIO
TITLE "Interzone"
INDEX 01 10:32:00
TRACK 10 AUDIO
TITLE "I Remember Nothing"
INDEX 01 12:48:00

Воспользовался программой XRECODE 3, вес треков на выходе составил ~2.8Гб против ~1.5Гб исходных.
Предстоит разобраться...

Потыкал галочки. Получил файлы весом в 6.88Гб.

Вообще используют shnsplit/cuetools в зависимости от системы. А что касается cue, то этот вообще можно разбить на два файла и получить типичное один flac - один cue, это просто текстовый файл бля, кури мануалы:
https://wiki.hydrogenaudio.org/index.php?title=Cue_sheet
https://en.wikipedia.org/wiki/Cue_sheet_(computing)
https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Frames_and_timecode_frames

И не знаю чего ты тут пишешь, я тут особенной активности не замечал. Если знаешь буржуйский, я бы порекомендовал зарегатся на OPS.
https://interview.orpheus.network

>>25893
если у файлов продолжительность действительно ~20 минут, то вина наверняка в тупой программе

>>25895
Воспользовался программой XRECODE2, всё получилось.
Могу предположить что виной огромного веса треков была это галочка.

Я смотрю, исправление ссылок при объединении нитей сломалось.
Автор ещё тут хоть?

>>25926
При объединении, или при переносе?

>>25927
Объединении. Причём раньше работало.
Пример: >>/b/157239, начиная с >>/b/173234

>>25928
Ага, вижу, превью работает корректно, а сама ссылка при этом неправильная, со старой нитью.

>>25926
>>25929
Починил и создал пулреквест.
Оказалось настолько тривиально, что даже стыдно за такое.

В пулл-реквесте с предупреждениями автор добавил экранирование ХТМЛ для модлога, но не учёл, что таким образом ломаются ссылки для просмотра удалённых сообщений. Мы пока вернули эту строку, дабы ссылки работали, но настоятельно рекомендуем найти способ починки этой лабуды, ибо оно не позволяет использовать ХТМЛ в предупреждениях.

>>26066