Кроме спискового включения (list comprehension) есть ещё set и dict comprehension,
a = {x for x in 'abracadabra' if x not in 'abc'}
b = {x: x**2 for x in (2, 4, 6)}
(можно добавить в 1).
А также выражение генератор, которое от спискового включения отличается круглыми скобками вместо квадратных (можно добавить в 4).
На практике ещё работает производный от 3го вариант.
Поскольку в это время была большая очередь, то «Самые умные» в это время не пойдут, а раз их там не будет, то и очереди тоже :)
Ну это по сути что mipmap нет, и при уменьшении текстура может пестрить.
Я имел ввиду честный NEAREST_MIPMAP_NEAREST, поскольку в статье приводится код Python для генерации палитровой текстуры, то там же можно было генерировать ещё и все mipmap т.к. стандартный generateMipmap для этого не подходит.
Как-то пропустили что текстура должна читаться без интерполяции выбирая ближайшего соседа, да и тема генерации mipmap для палитровых текстур не раскрыта.
Кроме первого пункта «Поддержка ICU грамматики», парсер которой скрыт в недрах @eo-locale/core, и в npm ссылки на гитхаб нету, остальное есть в стандартном Intl (ну и коленка + 10 минут комментатора ниже :) ).
Я не понимаю почему это важно, поскольку мне не известны профессиональные CAT утилиты, нормально обрабатывающие ICU формат. Ни SDL Trados, ни MemoQ этим похвастаться не могут, колупаться среди непереводимых select и plural не приносит переводчикам радости. В теории ICU форматтер это круто и гибко, но на практике несколько простых текстов для plural или select без разметки переводить проще и быстрее.
Пока переводчик это коллега — программист и текстов мало — всё хорошо. Когда проект станет больше, например, несколько десятков тысяч слов которые нужно будет переводить на десятки языков работа с ICU грамматикой будет источником проблем.
В Python есть аннотация типов, а также механизмы приведения и проверки. Да, это не особо удобно или красиво, но почему «не даёт возможности» тестирования?
Возможности же есть!
Я думаю стоит ещё учитывать что ж/д вокзалы часто находятся ближе к центру города, в то время как до аэропорта нужно ещё добираться, приезжать на регистрацию заранее, ждать багаж.
Прокатившись на «Невском экспрессе» задумался что хоть самолёт и быстрее(дешевле?), но поезд всё-же удобнее. Экологичность тут не на первом месте, но если бы поезд шёл 2 часа вместо 4х, то самолёт по сути и не нужен для таких поездок.
Не нужно осознанно разрушать рабочий бизнес — это бред. Развивать какие-то новые направления это да. Если они хорошо себя покажут, то основной бизнес пойдет туда, а старые направления органично сдохнут сами. А если нет, то хоть не останешься у разбитого корыта.
А почему нельзя просто загрузить всё минимального качества, а потом постепенно догружать и заменять картинки?
У меня например под wifi скорость пляшет. Получается что если мне повезло — то я попал на полноценные картинки, а если нет то застрял с низким качеством?
Т.е. при условиях, когда «двусвязный список» в основном последовательный и очень похож на массив и при некоторых операциях «в одну сторону ходить, не глядя на значение» (для которых в массиве вообще прямая адресация) это будет в три раза (но возможно больше, значение может занимать больше указателя) эффективнее.
P.S. Всё равно не покидает ощущение лёгкой высанонасти :)
Там изначально расчёт идёт чтобы не «фризить» сразу на 3 секунды страницу одним куском, а синхронно проделав часть работы (допустим за 1/20 с) дать возможность другим сообщениям отработать, повесив остаток работы на «потом» и так 60 раз :).
Вместо одного большого фриза будет много маленьких фризят — но они конечным пользователем воспринимаются терпимее.
А можно как-то более развёрнуто про кэш-линии?
В AoS допустим я каждый элемент промазываю, но при этом хотя-бы читаю значение элемента из кэша.
В SoA я точно так же промазываю, но уже целых два раза — для самого значения и ещё для указателя.
В чём профит?
Возможно стоит добавить что до Web Workers тяжёлые скрипты «деблокировались» другими средствами, например используя setTimeout(fn, 0). Несмотря на очевидную «костыльность» этого — перетаскивание кучи зависимостей в Worker на мой взгляд не сильно лучше.
на мой взгляд несколько сбивает с толку, потому что палитровый PNG сам по себе 1 байт на пиксель, да ещё и сжат DEFLATE (т.е. он изначально меньше чем DXT5, как его ещё можно «сжать» ?)
Кроме того из статьи неясно почему таки PNG. Это же Python — можно взять, например, pillow и работать с практически любым форматом. Ну или воспользоваться конвертером типа ImageMagick.
Статья скорее «Особенности S3TC DXT5», что там на вход PNG и вывод DDS по сути не так важно.
Не совсем понятно зачем заморачиваться с DXT5 для пиксель арта. Пикселей не так много, такого же сжатия можно добиться палитрой на 256 цветов. Дополнительно палитру можно будет менять для ретро эффектов.
Я думаю это будет бесплатно, но ограничено по времени. Просто как дополнительный инструмент маркетинга игр. Абсолютно все действия игрока будут записаны и проанализированы, а на основе статистики отдел аналитики/маркетинга решит как улучшить продажи :)
По моему облачный гейминг отлично подходит для рекламы/демо. Можно перепробовать массу игр прежде чем окончательно купить что либо. Сейчас тот же Steam даёт текстовое описание, видео и скриншоты. Вместо одного и того же видео можно будет мгновенно поиграть в кусок игры.
Ну не совсем удачный пример привёл. По поводу авторских прав судятся регулярно, тот же Google и Oracle, Samsung и Apple. Может для РФ это можно сказать экзотика, поэтому законодательство недостаточно хорошо проработано по этому вопросу. Может как раз на этом примере и доработают.
Нет, поскольку там дело не уголовное.
Это скорее особенности законодательства и процессуального права. Как и написано в статье — это лишь инструмент.
Но нарушение авторских прав вполне могло быть и уголовным в США (возможен выбор)
Ну арестовывали и отжимали бы в другом месте другие люди, не упускать же такие возможности :).
В других странах это хороший заработок для судебной системы, адвокатов, прессы.
Причём они заработают независимо от исхода дела.
Статья подаёт это событие как нечто вызывающее и специфичное для России, но в мире, например, в США таких примеров гораздо больше, например как Кармак cудился с Bethesda/ZeniMax. Тоже беспредел, акулы капитализма, схлопывающийся рынок :)
Своё оно конечно ближе и обиднее, но это скорее негативная мировая тенденция, которая просто дошла, причём с опозданием.
Увы, никаких ограничений на конечность не нашёл. Не могли бы подсказать куда нужно смотреть?
Я имею ввиду тот случай, когда сервер реально отвечает безразмерным/бесконечным потоком.
Вроде даже можно через OffscreenCanvas+ImageBitmapRenderingContext, но в принципе дёргать WebGL каждый кадр то особо и не надо.
Я так понял что движок постоянно переписывает буфер атрибутов, но обычно туда напихивают статики и забывают — каждый кадр его обновлять довольно накладно.
Всякие простые вещи типа положения летящих пуль лучше повесить на вершинный шейдер — пусть сам вычисляет/интерполирует.
Спасибо за статью, хоть узнал что такое Axios.
A то всё по-старинке через XMLHttpRequest с колбеками :)
Недавно попробовал fetch — вроде работает отлично.
О том, что есть ещё какие-то другие способы даже не знал.
«верните как было» это вполне ожидаемо и даже неизбежно при некотором количестве активных пользователей продукта.
С их точки зрения кстати даже довольно конструктивно :)
Но вообще набрасывать какашки и перестать пользоваться продуктом — это разные вещи. Кидаться какашками бывает довольно весело, а вот когда молча «вежливо» уходят — вот это проблема.
Стоит отметить что русскоязычное сообщество вполне устойчиво к умеренному «обсиранию» без перехода на личности и в большинстве своём адекватно.
Но контраст ощущается :)
Позитивные или негативные отзывы сами по себе не всегда являются объективными.
На мой взгляд лучше получить конкретно обоснованную критику, чем мутный/общий «отлично, всё нравится».
Это неприятно, но иногда объективно против железобетонных фактов не попрёшь, как бы «токсично» это не выглядело.
Как они доказали, что случайное (неизвестное) передвижение пустой плитки при 256 (а не 100500) повторениях даёт нам именно равномерное распределение (а, например, не нормальное)?
В статье пропущено решение уравнений Колмогорова для марковского процесса, это просто большая СЛАУ, по которой можно вычислить финальные вероятности состояний.
Учитывая что они «Ради математической изящности» выкинули спец. условия на краях и в углах — скорее всего финальные вероятности состояний распределены равномерно.
По мере увеличения числа переходов вероятности будут стремиться к своим финальным значениям, вопрос лишь насколько быстро это произойдёт (ну и с какой точностью).
Однако вопросов действительно много.
Если рассмотреть шахматную доску (чётное N), то любое перемещение «пустого пространства» будет чередовать белые и чёрные клетки, что сделает часть состояний невозможными для любого фиксированного количества шагов. А это сложно назвать «случайным».
N в четвёртой степени это как-то очень много.
На практике для маленьких размеров от исходного состояния невозможно уйти дальше фиксированного количества шагов. Для «пятнашки» 3х3 это всего 31 ход.
Можно проверить полным перебором 9! состояний.