>>27817
Видимо, всем плевать на индикатор сажи.

Поотвечать/запиливать пока руки не доходят.

>>27817
Почему бы и да. Надо будет сделать отдельный столбец в posts_$boardname.

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

Закончилася поддержка Theora во браузерах: https://caniuse.com/ogv

Не отпилить ли её и здѣсь?

Думаю в качестве значка сажи использовать шалфей, лол. Пока как-то так.

>>27829
Можно. Я так понимаю, с точки зрения расширения «Ѳеора» = ОГВ, и нам уже сейчас следует убрать его из разрешённых к загрузке?

>>27831

Да.

Ужé послѣ того, как загрузка перестанет быть разрѣшённою, можно будет и из кода FBE выкинуть строчку специальной обработки таких загрузок («if( $expectedFormat === 'ogv' ) $expectedFormat = 'ogg';»).

>>27831
Как-то с шалфеем вы меня потеряли, в чем суть?

>>27833
Sage (сажа) — не только мудрец, но и растение.
https://www.nccih.nih.gov/health/sage

>>27833
А ведь обо всём написано здесь:
https://noobtype.ru/wiki/Sage

>>27836
Читайте и тщательно конспектируйте Нубтайп...

Завёл задачу про значок сажи:
https://codeberg.org/FBE410/fbe-410/issues/51

Файл приложен сюда, но следует преобразовать его, как описано здесь: https://codeberg.org/FBE410/fbe-410/src/branch/public/icons

>>27796
Нет, у меня газовое.

З.Ы.: Если не хватает денег на нормальный компьютер, советую оставить программирование и идти работать. Хотя бы грузчиком.

>>27797
Да взаправду было интересно, тонкий стеб это или нет.

PS. Впрочем от жава-программиста, видимо, ожидать способности к самоиронии было глупо.

>>27798
Страшно далеки мы от народа...
Извини, я действительно не в курсе, над чем самоиронизируют нищуки. Но как бы там ни было, дельный совет я тебе уже дал: если нет денег, оставь программирование и начни их зарабатывать. От твоего нытья на всеми забытом форуме ничего не изменится.
З.Ы.: Мы отошли от темы.

>>27799
Нормальные ЯПы не требуют при компиляции таких затрат по мощности.
_Мимокрокодил_

>>27797
> Хотя бы грузчиком
На нормальный компьютер так не заработать.

Я проходил совершенно мимо и возмущен уровнем негатива и дезинформацией 😀

>>27802
По сравнению с компиляцией типичного проекта на C++, проекты сопоставимого размера на Java компилируются довольно шустро (из-за отсутствия инклюдов и макросов). Но зато некоторые проекты медленно запускаются. Это относится ко всему, где активно используется рефлексия: любой проект на Spring создаёт Proxy-классы, которые наследуются от компонентов, экземпляры этих наследников инджектятся друг вдруга - это всё происходит в рантайме во время деплоя.

>>27796
Шутка забавная, но она также происходит от непонимания, почему Java-проекты иногда начинают жутко лагать и сильно грузить процессор. JVM на самом деле работает очень быстро, но если взять программу, для работы которой необходимо икс мегабайтов ОЗУ и задать в настройках джавы лимит (Xmx) меньше, раза в два меньше мегабайтов, у JVM не будет никакого выхода кроме как лихорадочно пытаться в этот лимит уложиться. Я уже года три этим не занимался, так что не знаю, как сейчас, но раньше вся программа фактически превращалась в непрерывную сборку мусора. Но это следствие как правило неверного использования, а даже не слабого железа. Вот пример, IDEA в стандартной поставке шла с лимитом в 768Mb, и на небольших проектах этого было достаточно, но при открытии больших производительность проседала. Но при увеличении лимита до 1500Mb снова становилась шустрой.

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

>>27804
Человек застрял в 10-х. Ему ещё про приложения на Электроне не рассказывали.
>Или я не понял, что ты хочешь.
Хочу убрать из проекта прямой вызов ResourceBundle.getString, строковые константы в качестве его аргумента, ну и его MissingResourceException.
>В проекте менять properties синхронно с классом - только руками.
Есть старый дедовский метод: https://stackoverflow.com/a/56377778 — находим классы, имплементящие нужный интерфейс, берём с них {key, defaultValue} пары через этот интерфейс, берём из файла конфига currentValue или пользуемся defaultValue. Соответственно, все строковые константы можно убрать в Enum и больше никогда не доставать.

Тред пора перекатывать, наверное.

>>27814
Ок, как чуть получше станет со временем перекачу

Я ненавижу вредоносное ПО, такое как reCAPTCHA, hCAPTCHA. К сожалению, многие веб-сайты стали коллаборантами этих корпораций зла. А другие коллаборанты Дуровской корпорации зла завязываются на его вредоносный мессенджер.

> Последние 2 года материалы лекций и вся орг. информация выкладываются в тг-канале.

Я не являюсь их студентом, но считаю это крайне аморальным - навязывать скоту вредоносные шпионские сервисы, вроде ТГ, сотрудничающие с кем надо, и собирающие персональные данные, и возглавляемые такими высокоАморальными особями, как Паша и его Кот.

Правда, эти студенты сами это заслужили. Если бы не заслужили - то там бы не выкладывалось, а выкладовылась бы по нормальному - на частном инстансе Forgejo, или вообще в radicle с заркалом на инстанс.

Насколько я знаю, есть workaround: читать эту хрень через tgstat.

Но

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

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

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

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

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

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

Тред умер?

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

Гиде билды?

Хорош бампать, я сам бампну, когда придёт время.

Недавно гулял с сестрой в лесу. Она при всём уважении к моим хикки-привилегиям выразила заинтересованность в доступном объяснении, чем я занимаюсь целыми днями. Я сказал, что если честно, то делаю скорее не непосредственно свои проекты, а разные штуки для Паскаля (до этого сам похвастался, как сделал по просьбе человека с жёлтой аватаркой https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/446 за 1 день и €250; у человека свои причины улучшать совместимость с Delphi: https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg41878.html, но конкретно эти классы — очевидный бред и полная чушь и совершенная мерзость, решающая несуществующую проблему и не имеющая отношения к маршалингу, и мне стыдно за это; ковыряние с ассемблерным кодом в миллион раз лучше, одно моё творчество над стандартной функцией CompareByte ускоряет абьюзящие её программы на 10~20% в целом). Она спросила, зачем мне Паскаль, я сказал, что для той игры, которую показывал 10 лет назад. Она сделала сочувственное лицо и спросила, неужели я её до сих пор не доделал. Кажется, мой ответ заключался в том, что я ничего не делал всё это время, потому что мне было грустно, что у меня нет друзей. Этот ответ вроде как верен, и если не уточнять, что причина что-то делать у меня была точно такая же, даже удовлетворителен. ＊вздох＊

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

>>27282
>Хорош бампать
Раз в полтора года слишком часто, нужно было хотя бы до круглой даты дотянуть? xP

Гиде можно добавиться к тебе во френды? Спрашиваю исключительно из личного интереса, может хочу поиграть в это поделие, а еще втереться к тебе в доверие и украсть всю интеллектуальную собственность, ха-ха-ха. В любом случае, добавление меня ни к чему не обязывает, мне комфортно сидеть и ничего не писать и ничего не получать. Но может мы что-то напишем, возможно даже по этой игре. Да!

>>27282
О как, как увидел ник твой в fpc gitlab, так сразу подумал, о чем-то связанным с аиб, а сегодня и на этот тред наткнулся.
Спасибо за то, что делаешь в fpc dev.

>>27251
Ладно, держи вторую картинку.

>>27250
>>27252
Высылаю

>>27250
>>27252

Прочитал https://rakhim.org/summary-of-concurrency-is-not-parallellism-a-talk-by-rob-pike/ . КарGo-культ какой-то. Не вижу преимуществ между 100500 юзерспейсных псевдо-тредов с чем-то вроде встроенного интерпретатора

while(true){
switch(taskChunkId){
case a:
...
break;
case b:
...
break;
}
}

перед подходом, когда на задачу выделяется по треду, делающему её от и до, ну а когда переключение контекста происходит - оно всё равно происходит в основном, когда I/O идёт. В результате нет лишнего оверхеда на всякую фигню, нет лишнего оверхеда на message passing, ну а оверхэд на хранение состояния треда можно минимизировать, избавляясь от ненужных данных тогда, когда они перестали быть нужными.

А можно мне совет 0x65, пожалуйста!

>>27260
????

Запрашиваю 0x0B

>>27536
Я думал тред уже все, прости что поздно.
В примере у авторов крыша потекла кмк.

>>27789

>>27791
Совет дельный. Правда если понимать его только в разрезе производительности, эффект может оказаться краткосрочным.

>>27790
Думаю, что особенной проблемы в этом нет. Как никак, а Автобус не из быстрых борд (хотя казалось бы имеет колёса и двигатель).

>спойлер
Ну, совет действительно странный. И скорей достоин рубрики "вредные советы".

Запрашиваю 0х3D

Самый вменяемый способ работать с консолью в виндузе - использовать собтсвенную отрисовку (а там хоть через вулкан).
CMD.EXE это не то чем оно тебе кажется, не трогай его. Даже все индусы МС не смогли сделать из этого костыльного монстра нечто нормальное, лучше не пытайся и пиши сразу свой вывод, будет лучше быстрее надежнее и понятнее чем cmd.exe

Рекомендую попробовать ConEmu для означенной цѣли.

https://conemu.github.io/

>>27748
okay mate :cool:

>>27747
а на линуксе можно и терминал юзать, там он настолько шустрый, что даже есть стирать и перерисовывать всё 60 раз в секунду, то даже мерцаний не будет видно

>>27741
ENABLE_VIRTUAL_TERMINAL_PROCESSING действительно медленная, но не до невозможности, я делал то же самое и у меня в итоге вышел почти приемлемый для полноэкранной анимации FPS. В моём случае узким местом было формирование строки, то есть, буквально, формирование и копирование RGB-циферок стандартными функциями. Проверь, не так ли это в твоём случае, то есть сколько раз в секунду ты можешь хотя бы сформировать строку без её вывода. Если проблема действительно в этом, то предвыдели буфер по максимуму, то есть столько, сколько понадобится в худшем случае — для смены обоих цветов в каждой ячейке экрана, и заполняй его руками без аллокаций, то есть заноси буквы через buf[pos++] = '[' и цифры компонентов RGB-цветов через buf[pos++] = c / 10 % 10.

И да, содержимое всего экрана ты должен вывести в один вызов. Это не только быстрее, но и выполняется без мерцания, разрывов, и подобных артефактов, в отличие от вывода построчно или попиксельно.

И да, вывод всего прямоугольника через WriteConsoleOutput намного быстрее, если тебя устраивают 16 цветов. А то судя по скриншоту, устраивают, а я растеоретизировался. :D

Бамп

>>13947
Бамп длинною в жизнь.

Программные продукты, написанные в ООП значительно проще расширять и поддерживать.
Если мы говорим о коммерческой разработке, где важен не столько сам код, сколько адекватные сроки решения поставленных задач, которые разумеется не состоят только из новых фич, то ООП продукты вырываются вперёд за счёт двух важнейших параметров в коммерческой разработке:
1. Способность модифицировать куски системы без риска разломать вообще всё.
2. Возможность переиспользовать имеющийся код, если он вписывается в решение поставленной задачи.

Функциональщики соснут тогда, когда потребуется написать действительно большой продукт с сотнями сущностей и тысячами специфичных для этих сущностей действий.
Когда мы проектируем системы, мы проектируем их отталкиваясь от реального мира. Что вот, например, есть User. User имеет ряд, специфичных для себя полей, а так же User имеет ряд специфичных для себя, действий (методов). При ООП подходе это описывать удобно, зачастую прозрачно и не вызывает боли, если есть мозг. Если мозга нет - то можно и в процедурном стиле написать что угодно, прыгая взад - вперёд через goto.
Только вот кто это будет поддерживать? Тот кто это написал? Отлично. Это определённо успех.

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

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

Опять двадцатилетние синьоры хуйню на чанах несут. Куда смотрит ПэЖэ?!

>>14013
Лучший тред. Читал с удовольствием.

>>27716
Понастольгировал, всплакнул?

>>27724
Удивился какие жестокие нравы были в разделе. Но зато хоть люди были какие-то.

>>27729
Аноны, наверное, в ту пору горячими студентами были. А теперь они выгоревшие работяги...

>>27737
Все-таки гики-студенты, если вообще студенты. Обычному студенту объяснять другим людям что такое ООП и в голову бы не пришло, тем более сраться за корректную терминологию и даже идеологию применения.

>>27729
Устроить холивар и засыпать кому нибудь хуёв за воротник - тогдашняя норма в айтишечке.

>>27666
Она через жопу работает, у неё неправильная логика интерфейса. А ещё у меня к этому поделию личные претензии. Однажды пидор-разраб что-то сделал и у меня все картинки направо переехали. При этом сделать мне обратно он отказался, типа мне самому нужно ещё раз открыть настройки и переключить. Ага, блядь, делать мне больше нехуй, если я один раз уже открывал эти настройки, после чего я снёс его высер и больше к нему не притронусь никогда.
Дашчян тоже неправильно работает, а про зондовую показывалку таблички "хуй будешь?" мы вообще промолчим, это за бордоклиент вообще не считается.

>>27671
Предпочитаю не бампать треды нерелевантной информацией.

Ладно, как и где этот «запарожец» ручками поковырять? Раз уж никто ничего не делает.

>>27700
В шапке ссылка на гитхаб, вроде у алисы самая актуальная версия, посмотри по форкам

Капча на неназываче похоже всё...

>>27702
Да, она всё. Пишет 404 и даже пасскод не проходит, потому что пидор тамошний отключил старую капчу совсем.

>>27702
Да и сам он тоже всё.

Анон из mobi харкача сделал форк, где поддержал капчу и начал новые фиксы пилить.

Код: https://github.com/a2nc3/Overchan-Android-N/tree/testing
Апк: https://github.com/a2nc3/Overchan-Android-N/releases/download/v1.9.0b22/Overchan-Android-N-unofficial-release.apk

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

>>27708
Недолго музыка играла.

>>27743
Да тут вот что-то можно скачать, например:
https://github.com/a2nc3/Overchan-Android-N/releases

>>26323
Разработчики, родненькие, подайте пожалуйста хоть какой-то сигнал по вам и о статусе проекта

>>27262
Статус проекта: обглоданные кости.

>>27262
Как-то так вышло, что все сколь-либо активные участники ныне забанены на Автобусе, скорее всего после последних вайпов. И мне было лень отписаться.
Лично я слушаюю что всё ещё делается, надеюсь, жду и даже получаю запросы на помощь.

>>27297
А в процессе слушания вещества употребляете?

>>27306

С Наступающим всех Новым годом!

>>27297
Тебе отвечает нейросеть.

>>27429
Нет, даже я молчу.
нейросеть

Когда-нибудь они допилят. Мы все еще ждем.

>>27730
В эроге допиле все будет зашибись.
Его выпустят скоро, надо только ждать.
Там веселый лагерь, и лето в нем - кайф,
Даже, может быть, не надо будет перепроходить.

>>27441
Дудосят.

>>27008
Чаще есть. Но теперь совместно с пустотой перестаёт грузиться капча в тредах. Из браузера всё нормально. Обычно приходит в норму в пределах получаса.

Кто может вот так же для Ычана сделать?

Опять оранжевый не работает.
На life обновляются треды, но каталоги и капча forbidden.
На hk большую часть времени постоянно forbidden, но иногда грузит.

Почините харкач уже кто-нибудь, пожалуйста, ну сил никаких больше нет терпеть постоянное 403 и страдать в сраном дашчяне дебильном, где всё неправильно и через жопу работает.

ДА КТО-НИБУДЬ УЖЕ ПОЧИНИТЕ ЁБАНЫЙ ХАРКАЧ, БЛЯДЬ

Бросай нахуй это говно (харкачь), тебе уже свыше знаки шлют.

>>27638
Так больше негде сидеть.

1. Тред давно перекотился >>27507
2. Сидение на помойке, что косит под двач, это элементарное неуважение к себе.
3. С починкой тебе никто не поможет.

>>27637
>ПОЧИНИТЕ ЁБАНЫЙ ХАРКАЧ, БЛЯДЬ
У меня как работало всё, так и работает. Не ебу что там за траблы у вас. Капчую с него, и тут этот пост с него пишу

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

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

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

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

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

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

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

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

https://unity.com/dots

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

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

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

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

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

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

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

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

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

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

бамп

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

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

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

>>26109
ну чО, как результаты?

>>27432
Тоже любишь отчеты вкатывальщиков читать?

о, здарова, вы тоже игры делаете?