>>19520
Если тебе нечем заняться, вот тут есть челлендж >>19427 , там задачи высочайшего уровня сложности.

>>19520
>экспоненциальной временной сложности.

Относительно n или |n|?

Здесь для С2

O(n)

?

https://pastebin.com/znip5iJc

Недавно попадалась новость про то, как алгоритм такого типа научили делать уровни для Doom, показав ему пачку готовых уровней, сделанных кем-то ещё. И получилось правдоподобно.
Но ведь это всё равно не новый контент. Алгоритм может лишь подражать чему-то существующему, делая его ремиксы. Чем больше он знает, тем более разнообразны эти ремиксы. Я бы назвал такое "псевдоновизной".
В будущем созданием игр и всего такого прочего будут заниматься машины. Разнообразие окажется как никогда высоким, но оригинальности (и гармоничности, слаженности элементов) всюду будет недоставать, и именно поэтому работа людей по-прежнему будет цениться выше, чем машин. Те, кто смогут привносить в устоявшийся круговорот что-то свежее, всегда будут востребованы.

>>19999
Впрочем, человек тоже не может придумать что-то полностью новое. Его творческие способности точно так же ограничены его знаниями. Когда Микельанджело писал свои знаменитые фрески, он был первопроходцем, но это не значит, что он ни с чего не копировал элементы. Нет, он их копировал, только из природы, а не чужих работ. А в чём-то он и подражал античному искусству, а вот оно уже подражало природе.

>>19999
И в эти игры играть будут сами же машины.

А вообще по поводу твоего недовольства, тут же суть именно в машинном обучении, то есть сверх нового она тебе ничего не даст и не должна давать.

>>20002
Почему бы и нет? Пусть играют машины, а я нажму X и буду смотреть кинцо.

>>20076
Чиочую. Особенно актуально в эпоху игры на Ютубе и прочих Твитчах.

>>20077
Только надо еще чтобы AI игрок прислушивался к моим советам и пожеланиям (или требованиям). Даже если я прикажу сделать самовыпил или просто обрушить всё достигнутое (например выбросить все шмотки). Буду сидеть и покрикивать в монитор, это и будет геймлей...

>>20078
Интерактивные зероплей-игры с влиянием на игровой процесс результатов голосования многих людей… Где-то я это уже видел…

>>19727
Я уже связался в f2d и получил свежайшие исходники, прямо с источника, но вплоть до третьего числа скорее всего не начну работать.
c: Perl

Ведро 4.4, Хром. Изображения в ОП-постах раскрываются вот так. На них текст налезает.

>>19746
Пф.
Ведро 8, хром и мишный браузер, изображение в новой вкладке.

>>19747
А на полной версии сайта >>19746

>>19748
А, в мобильной версии вообще яваскрипта нет, кажись.

>>19729>>19634
В общем, всё очень мило запиливается за ночь, есть только проблема. В том числе безопасности.

Нам надо как-то достать картинку с рисовалки на сервер. И так как всё рисование происходит на стороне клиента, то на сервер, потенциально, могут подсунуть чёрт знает что.
Я вижу три решения:
1. Хранить, как сейчас, временные файлы в /tmp/, удалять всё что старше часа и обмазать это разрешениями на чтение/запись. Соответственно, обеспечение безопасности на совести Администрации. Или проще - проверять файл на то, что это вообще png, но тогда при постинге проверка будет идти повторно.
2. Таскать туда-сюда картинку в base64, как она таскается сейчас дудлятором. Проблемы две: во-первых, всего картинку придётся протащить четыре раза: с рисовалки на сервер, с сервера на форму ответа (и как картинку и как поле формы ответа), и с формы ответа обратно на сервер. При этом на втором шаге картинка невозбранно подменяется на что угодно, даже не base64.
3. Хранить картинку где-то в памяти браузера и показывать её оттуда же. Всё ещё возможна подмена как в 2, но нет таскания файлов туда-сюда. Но надо будет переписывать форму ответа специально под этот случай, по-моему.

Я сейчас сделаю 1 с проверкой на png. 3 мне сделать не хватает теоретических знаний.

>>19991
http://yakuji.moe/wakaba/oekaki.diff
Содержит диффы к jfc.js и milf.js из https://github.com/f2d/doodle-mutator/tree/master/doodle, но не сами эти файлы.
Наверное, можно ещё посмотреть, почему при загрузке файла холст слетает в выравнивание по левому краю, как красиво убрать сохранение/загрузку чтобы кнопок не было, но при перебое питания можно было восстановить картинку, и ещё что-нибудь (например, передавать параметры чтобы интерфейс на русском), но я лучше спать. Благо, серверная часть в основе своей сделана.

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

>>19738
Что ты в тексте самой работы будешь писать в случае выбора движка имиджборды?

>>19739
Напишу что-нибуль про специфику общения на АИБ и все такое...

>>19739
Напишет про японские веб-форумы и общение на них, которое от наших отличается.

>>19738
Ты же сам говорил, что другие делают игры и сайты. В чем тебя не поймут?
Да и саму по себе игру гораздо интереснее делать, чем очередной движок для АИБ. Плюсом, может игру с платной составляющей сделаешь и в экономической части просчитаешь доходность.

>>19744
Спасибо за совет.

Как дела? Есть подвижки в дипломе? Начал что-нибудь?

Пособие https://trac.ffmpeg.org/wiki/Encode/VP9 оказалось рекомендующим чрезмерно подробные параметры вызова FFmpeg.

Действительность же вот какова: так как правка https://github.com/FFmpeg/FFmpeg/commit/2392da164a02e4e4f7e1b933018d14afcb13ddc1 была внесена 28 августа 2015 года, то FFmpeg создаёт WebM посредством кодека VP9 по умолчанию примерно с того же времени.

Соответственно, параметры «-c:v libvpx-vp9» можно исключить (потому что они подразумеваются в FFmpeg) из моих рекомендаций, приведённых в репликах >>18670 и >>19332.

Остался неохваченным вопрос о том, как создавать видео со звуком, и охвачу.

Проще всего это сделать на примере WebM, для которого FFmpeg (по аналогии с >>19377) автоматически употребляет кодировщик Opus, так что остаётся только выбрать битрейт — например, 256kbps — и вписать в аналогичную >>18670 командную строку:

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -sn -crf %2 -b:v 0 -b:a 256k -tile-columns 2 -threads 8 ibvideo.%2.webm

Впечатывание субтитров в видеокадр достигается аналогичным >>18676 приёмом:

ffmpeg -hide_banner -i %1 -vf "subtitles=%~nx1" -ss %3 -to %4 -sn -crf %2 -b:v 0 -b:a 256k -tile-columns 2 -threads 8 ibvideo.%2.webm

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

Если искать наиболее наглядный пример такого идеала между имиджбордами околоычановского конгломерата, то с неизбежностью приходится торжествующе ткнуть пальцем прежде всего в Nowere.net (открывается как подраздел /tu/ верхней навигационной панели или по гиперссылке «туризм» из раздела «Общее» в левом фрейме на Ы

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

Чуть больше трёх недель тому назад (19 марта) автор реплики https://iichan.hk/d/res/244600.html#245388 счёл возможным в обстоятельствах запрета на загрузку звуковых файлов (MP3, Opus) появление таких видеофайлов (MP4, WebM), у которых звуковая дорожка будет содержать желаемый звук (например, Opus в WebM), а видеодорожка будет состоять из повторений одного и того же видеокадра (в качестве примера он упомянул обложку альбома) — такие повторения очень хорошо сжимаются видеокодеком, так что такая видеозапись будет, в общем-то, немногим хуже (неэффективнее) первоначальной звукозаписи (конечно, если видео со звуком вообще разрешено публиковать на имиджборде, то есть если не запрещён звук в видео).

По адресу https://github.com/pituz/webm-thread/wiki/Pro-tips#Создание-видео-из-статичной-картинки-и-музыки можно видеть, что та же идея посещала в позапрошлом (2016) году разработчика, действовавшего на Гитхабе под псевдонимом «Питуз», который предложил для решения её такой рецепт, который может быть скорректирован под нынешние обстоятельства (восторжествование видеокодека VP9 и аудиокодека Opus) и избавлен от некоторых чрезмерных настроек (изменение длины GoP и высоты кадра), после чего принимает следующий вид:

ffmpeg -hide_banner -loop 1 -r 1 -i %1 -i %2 -ss %3 -to %4 -crf 7 -b:v 0 -b:a 256k -pix_fmt yuv420p -tile-columns 2 -threads 8 -shortest ibaudio.webm

Пользователям невиндовых операционных систем перед употреблением придётся внести в эту команду ряд обычных отличий (заменить «%1» на «$1» и проч.).

Предполагается, что команда для удобства лежит в пакетном файле и оттого вызывается в форме «имяПакетногоФайла имяКартинки.png имяЗвуковогоФайла.mp3 14:03 23:15», где «

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

Изложенные в рецепте >>19601 параметры «-pix_fmt yuv420p», по-видимому, полезны и во всех предшествующих рецептах, потому что без них FFmpeg может попытаться создать WebM с таким форматом пикселов, который в Firefox восприниматься не сможет (например, в десятибитном цвете) — или, может быть, сможет, но только в какой-нибудь новой последующей версии.

Кроме того, больше двух недель тому назад правка кода https://github.com/FFmpeg/FFmpeg/commit/0dc11d8bbd470db89fbc17b7434e992c9129b310 привела к появлению в FFmpeg поддержки кодека AV1, которому википедическая статья https://en.wikipedia.org/wiki/AV1 пророчит появление также внутри контейнеров WebM. Но до тех пор, пока это появление не состоится (или, вернее, не возымеет широкой поддержки в стабильных последних версиях браузеров), никаких готовых рецептов для командной строки вызова FFmpeg, порождающего видео AV1, я сочинять не стану.

Всѣ послѣднія версіи FFmpeg (по меньшей мере, от версии 4.0 и до сборки 8 мая включительно) отчего-то начинают генерировать невыносимо большое количество байеровской узорчатости (и даже никак не объяснимой по Байеру хѣрни) в том режиме «bayer_scale=0», который я рекомендовал выше.

По-видимому, это какой-то баг FFmpeg, потому что до этого таких проблем не было.

Единственный известный мне способ избежать его — поставить «bayer_scale=1» вместо этого, но и этот способ не идеален (возникают те границы между узорчатыми и неузорчатыми полосами, которых при нуле не было).

По поводу бага >>19788 два замечания.

Во-первых, он касается только анимированных GIFов, то есть замена значения «bayer_scale» (временная, для обхода бага в FFmpeg до того момента, когда разработчики исправят его) потребуется только в рецепте >>19332.

Во-вторых, по-видимому, баг в FFmpeg появился ввиду исправления ошибки https://trac.ffmpeg.org/ticket/4443 без последующего исправления ошибки https://trac.ffmpeg.org/ticket/6813 или другой аналогичной. Другой причины в багтрекере у FFmpeg я не мог найти.

Отдельно подчёркиваю: тот обходной путь, который изложен в реплике >>19788 и уточнён в реплике >>19790, всего лишь маскирует главную проблему: в FFmpeg 4.0 сломан генератор GIFов.

(И маскирует не слишком умело. При «bayer_scale=1» не так много сверхзаметного мусора, но всё равно видно какое-то чрезмерное трепетание узора в кадре там, где его не должно быть.)

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

Обновление 1.1

В этой версии: исправлено ускорение на высокочастотных дисплеях, уменьшена сложность за счет отключения восстановления съеденных точек при смерти (>> 18044), оптимизирована производительность, а также добавлена мобильная поддержка (можно управлять тапами по экрану) (>>18098)

По умолчанию теперь Japari mode.

>>18042
Про Мохнатку что ли?

>>19562

>>19691
В /b появлялась смешная девчонка с острыми звериными ушками, которую зовут Мохнаткой. Это не про неё случайно игра?

>>19731
Где-где появилась?

>>19732
В Автобусе.

>>19733
Нет, это про её друзей.

>>16218
Красивая гифка.

>>16218
Я не понял, математические деревья ты имеешь в виду или реальные, потому что на гифке как будто программа для моделирования сада. Сам хотел такую написать.

Бамп, хотелось бы апдейтов. Продолжай пилить, ну.

Что-то застряла разработка. А сф теперь при скачке говорит: malware detected, download at your own risk. Это что же получается?

>>19389
ОП взял твои деньги и свалил в Мексику.

>>19389
Всё не могу себя заставить ту Сырну дорисовать. Ничего, уже вот-вот, сейчас всё будет, ещё немного, ух. шёл 2018

Мальварь, по-видимому, детектится из-за того, что скомпилированный FPC бинарник зачем-то импортирует ReadProcessMemory. Возможно, стоило бы посмотреть, зачем именно, и репортнуть на багтрекер, но вот, скажем, у меня похожая проблема с PyInstaller, и их позиция — не подстраиваться под антивирусы (https://github.com/pyinstaller/pyinstaller/issues/680), что в идеологическом смысле правильно:
>The only correct way to deal with antivirus is to report them that they are wrong. If we are working around them, we simply start a cat-and-mouse game that never ends.
Если убрать из таблицы импорта ReadProcessMemory (в качестве незаконного решения, не требующего перелопачивания структуры EXE, а только HEX-редактора, можно затереть названием какой-нибудь другой 17-буквенной функции kernel32, например, GetCurrentProcess), бинарник продолжает работать, но уже не даёт ни одного срабатывания на VirusTotal. Подозреваю, что там в каком-нибудь недостижимом пути исполнения какая-нибудь ерунда уровня ReadProcessMemory(GetCurrentProcess(), ...), т. к. если такое нужно сделать один раз, это может быть проще SEH или VirtualQuery.

Кстати, упоминавшийся в >>16218 баг был из-за того, что объекты сцены сдвигались, соответственно, и дерево апдейтилось в Newton-коллбэке http://newtondynamics.com/wiki/index.php5?title=NewtonSetTransform, который вызывается в ходе NewtonUpdate в потоках физики, а не потоке, дёрнувшем саму NewtonUpdate. Когда я делал физику, я ввиду своей наивности проигнорировал параметр с недвусмысленным названием threadIndex, а старое дерево не меняло топологию на лету (требуя явно вызы

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

Всегда хотел это проверить =3.

Такой вопрос, а почему ты не использовал сокеты на SPA?

>>19671
Я бы наверно мог, но зачем? Real-time обновления здесь не сильно нужны, плюс нужен сервер помощнее, плюс бэкенд на Django с веб-сокетами не дружит.

Как и на новом нульче, кукла работать не будет?

>>19672
Я всегда думал, что со SPA неразрывно связаны веб-сокеты, особенно в тех местах где используются чаты и нужно вовремя реагировать появление новой информации.
В твоём случае это была, как минимум, боковая панель.

>>19673
Нет и не нужно.
>>19674
Нет, достаточно старого доброго AJAX. Алсо, имиджборд концептуально не чат, другой формат общения. Текст длиннее, немедленного ответа никто не ждет.

>>19675
Движок не нужен? Тогда зачем ты его пилишь и ведешь по нему тред?

>>19669
> для простого, в общем-то, проекта нужно столько кода. Уйма логики дублируется между клиентом и сервером.
Не понимаю что тут такого сложного ты нашел. Ну, с редуксом и реактом я не работал, может, там и вправду сложно. А на сервере у тебя было что-то кроме самой БД и API-ки?

> Ты открываещь тред, в нем последний пост появился только что, в боковике у него дата обновления - позавчера.
> и хотя я сделал так, что порядок при подгрузках будет сохраняться, но число постов и дата обновления снова вызовет недоумение.
А в чем проблема регулярно обновлять его?

CSS grid.
</thread>

>>19622
Мне нужен самый простой пример просто такого размещения блоков. Остальное сам.

>>19623
Да-да, на флексбоксах и гридах у меня всё вышло. Мне интересно понять, как это работает на чистом CSS.

Но спасибо, что зашёл.

>>19622
> Блоки закреплены
Это.

https://jsfiddle.net/x0u39zeu/66/

>>19627
И да, совет: используй контейнеры.

>>19627
>>19628
Спасибо тебе огромное!
Желаю тебе чего-нибудь очень хорошего.

>>19547
Тебе что-то не нравится в этом исследовании? Ну если ты такой гуру в нейросетях, то почему не поможешь?

>>19548
Клик по одному из этих квадратов открыл это окно. Сбоку белые полоски, по обе стороны которых хаотичные россыпи синих и красных пикселей. Наверняка это имеет непосредственное отношение к генерации новых картинок на основе предыдущих. Тем более что при каждом клике на одну из полосок эти россыпи рандомно меняются. Вот только надо получать не совсем рандомный результат, не забыли? Лишь частично рандомный, но и подчиняющийся определённым правилам. Ну и конечно же картинки должны быть гораздо крупнее, чем эти крошечные мешанины точек.

Я за весь тред не увидел работы с НС, со мною всё нормально? Не увидел определения количества слоёв, типа сети (Хопфилда, Хемминга, Кохонена, et cetera), функции активации, метода обучения. Вижу только работу с данными, при том с неизвестно какими. Вижу, что програмка как-то может решать задачи о классификации и кластеризаци. Как? Как минимум, нужно читать документацию. А то получается >>19540.
Приведённая программа не генерирует картинки(скорее всего). Она работает с некоторыми цифровыми данными. С возможностью их визуализации по некоторому неизвестному правилу.

>повседневных задач
То, что ты взял, решается всякими DeepMind’aми. Если ты это как-то неведомым образом используя старый ПК будешь эффективно решать, то это на научную работу потянет, например https://arxiv.org/pdf/1708.05509.pdf (и то этот ихний make.girls.moe работает очень плохо: попробуешь сделать что-то, что редко рисуют, и оно тебе покорёженного бисёнена выдает, я как-то постил в /b/ примеры такого поведения сети). У тебя же задача во много раз сложнее. Круче только >>19427. Запатентовать не забудь.

Поэтому, начни с теории. Сделай >>19526 (или не надо, кажется, такое уже есть, и широко используется в киноиндустрии).

>>/b/128351
Слово “генерировать” здесь не совсем уместно. Спроектировать и обучить(аппроксимировать) некоторую НС легко. Но именно что некоторую. Спроектировать и обучить может быть сложно. В зависимотси от того, что ты хочешь. Одно дело буковки на капче Ычана распознавать, а другое — решать классификацию изображений Гельборы по тегам.

На Чиочане как-то был человек, который целую статью по НС где-то там писал, его ещё на работу куда-то там взять хотели. Может быть, он тебе ответит и чем-нибудь поможет с литературою по теме.

>>19547
ОП напоминает Божену Рынску, когда она узнала слово "хикковать".

>>19556
Но это не Божена, это Девочка-Улыбнись.

https://www.youtube.com/watch?v=SacogDL_4JU
Здесь может! А вот у картинок правила построения наверняка гораздо сложнее, чем в симфонической музыке. Там-то накидать нот на станы, и всё. Полурандомно, то есть со случайным выбором, но также с соблюдением правил. А тут что? Скажем, такие этапы, что когда определять:
1) Число актёров (т.е. девочек, скорее всего от одной до двух, чаще одна, но изредка может быть и пять)
2) Тип взаимодействия актёров и их позы (хоть няшатся, хоть стоят одна в стороне от другой и даже не смотрят друг на дружку)
3) Задник - где это, какие объекты вокруг раскиданы. Заброшенный завод как в S.T.A.L.K.E.R., подворотня в киберпанк городе, железнодорожный вокзал в Токио, школьный класс, барокко дворец, внутри пассажирского самолета, да что угодно.
4) Места расположения, приблизительные позиции (и в пространстве и касательно картинной плоскости), ракурс: вблизи, издалека, сверху, снизу, с наклоном, etc.
5) Как выглядят, во что одеты
6) Более точные позиции, как позируют и какие выражения лиц (уточнения второго этапа)
И давай штамповать. Нажал пробел, вброшено семя в виде рандомного 10-значного числа, и по нему сгенерировалась пикча с чем бы то ни было. Не понравилось, нажал снова и получил по другому семени.