Впечатления от Stable Diffusion

Так как господин К. таки завёл локальный Stable Diffusion,  немного поигрались коллективно с ним вечером в эту самую генерацию картинок из текста (и проиграли в итоге не раз).

О платных модах

    Поймал себя на нехитрой мысли, что платные моды могут сработать, если их правильно приготовить. В принципе, те же DLC можно записать в платные моды, сделанные самими разработчиками, и против платных DLC уже мало кто протестует. Да, лет 8-10 назад, протесты были куда сильнее, но сейчас никаких серьёзных скандалов на эту тему нет. Поэтому, почему бы и нет? Но, при этом, должна соблюдаться осторожность.

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

    Вторая вещь, которую по идее стоит сразу отметить - разделение на официальные моды и неофициальные. Официальные должны поддерживаться самим разработчиком, оперативно патчиться и прочее. Неофициальные - соответственно, живут своей жизнью.

    Но самое главное - взаимодействие разработчика с моддером. По идее здесь должна быть win-win ситуация: разработчик получает больше контента для игры, продлевая ей жизнь,  моддер - exposure, единоразовую выплату за разработку + процент продаж с мода (навскидку 20-40%). Такой малый процент взят потому что разработчику  всё равно придётся поддерживать мод. Ну и, возможно, место в штате если это его интересует, и это того стоит. Здесь, ещё бы стоит подумать об оценках качества разработки мода, общих гайдлайнах для модов, чтобы упростить интеграцию чужих модов в процессы. Но на этом останавливаться не хочется, а то по ощущениям выходит опять Битрикс.

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

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

hrtp-demake на Windows XP на старой машине

 Так как в оригинале предполагалось, что всё же движок сможет работать и на очень старых машинах, попробовал портировать игру на Windows XP. Было немного жутковато (ибо пересел на C++14, было ощущение, что придётся избавляться от новых конструкций) . Но  нет: благодаря TDM-GCC всё получилось:

Опишу вкратце основные проблемы, которые возникли, помимо обычных правок при переносе на более ранние версии компилятора (остальное - в описании к видео):

1. TDM-GCC 10.3.0 из-за проблем у Windows XP с HTTPS и общей старости нормально не ставится инсталлятором. Я тупо поставил его на "десятку" и просто копированием перенёс, он при этом отлично работает. В остальном - всё отлично, сам компилятор работает неплохо. Ощутимо медленнее, чем старые версии, но поддержка относительно свежего стандарта того стоит.

2. std::random_device НЕ создаётся. Какой ты ему токен не дай - падает с исключением. Решилось созданием своего "подвирающего" random_device на базе rand/srand. Ни о какой криптографической устойчивости речи не идёт при этом, но в игре это как по мне, никого не волнует и волновать не будет.

3. Почему-то встроенный Intel GMA 3150 не любит текстуры 4096х4096 . Это странно, если бы ему не хватало памяти - они бы падали на закачке, но здесь они закачиваются но не отображаются. Впрочем, разбить текстуры было легко, а в остальном проблем не возникло.

Отняло это на самом деле - ну, 3-4 часа, движок собирался куда дольше. 

В остальном я результатом доволен. Такие дела.

Небольшое геймплей видео по старому новому проекту

    Наконец-то дошёл до определённой точки в разработке, после которой можно наконец записать геймплей. Соответственно, залил геймплей:

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

И снова про Raspberry Pi 3B+

В прошлый раз рассказал о дурацкой проблеме, возникшей в процессе сборки своего мегадевайса. Покопавшись, таки удалось решить проблему, не взяв в руки паяльник и мультиметр.

Помог вот такой сорт шнура. По сути это Micro-USB на Micro-USB шнур с выключателем. Это ни разу, не супер реализация, так как подключать приходится через переходник USB-male - USB-male , а потом преобразовывать USB в Micro-USB . Соединение при этом хлипковато, нет ощущения прочности. Но, тем не менее, это работает under-voltage не возникает.

Остаётся только поместить это всё в корпус.

Такие дела.

Про Raspberry Pi 3B+ и его мобильность

Мне неожиданно захотелось собрать портабельную консоль на том же Raspberry Pi 3B, так как многие, не без причин, хвалят "малинку" за удобство и полезность. 

Сказано - сделано. Взял PowerBank RAVPower Power Bank 26800mAh PD 30W, зарядил, подключил - работает, система не показывает undervoltage, живи и радуйся. А вот нет же. 

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

Я сначала подумал, что дело в дополнительном переходнике USB - mini-USB который сильно длинный.  Попробовал взять вариант с тумблером, но USB-mini-USB напрямую. Это не изменило ситуацию, и я подумал, что шнур опять длинный (хотя во всех случаях совместимость с "малиной" гарантировалась).

Попробовал собрать более короткий вариант, но уже с двумя переходниками и это не помогло, всё так же при нагрузке возникает under-voltage. Вроде бы все заявляют о совместимости с Raspberry, которая на деле оказывается какой-то совместимостью в вакууме. 

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

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

UPD 1.07.22: Попробовал на аккумуляторе помощнее - Harper PB-0030. Дело всё же в шнурах, результат не изменился.

Про BlackChain

Недавно попробовал для себя BlackChain  - RTS, очень сильно похожую по стилю и управлению на первый StarCraft и, в целом, если её доделать она в целом была бы многообещающей. Как по мне, потенциал у неё выше чем у условной IronHarvest и идеи, хоть и взятые из старых близзардовских RTS довольно неплохи.