Там изначально расчёт идёт чтобы не «фризить» сразу на 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 — вроде работает отлично.
О том, что есть ещё какие-то другие способы даже не знал.
«верните как было» это вполне ожидаемо и даже неизбежно при некотором количестве активных пользователей продукта.
С их точки зрения кстати даже довольно конструктивно :)
Но вообще набрасывать какашки и перестать пользоваться продуктом — это разные вещи. Кидаться какашками бывает довольно весело, а вот когда молча «вежливо» уходят — вот это проблема.
Вместо одного большого фриза будет много маленьких фризят — но они конечным пользователем воспринимаются терпимее.
В AoS допустим я каждый элемент промазываю, но при этом хотя-бы читаю значение элемента из кэша.
В SoA я точно так же промазываю, но уже целых два раза — для самого значения и ещё для указателя.
В чём профит?
Кроме того из статьи неясно почему таки PNG. Это же Python — можно взять, например, pillow и работать с практически любым форматом. Ну или воспользоваться конвертером типа ImageMagick.
Статья скорее «Особенности S3TC DXT5», что там на вход PNG и вывод DDS по сути не так важно.
Не совсем понятно зачем заморачиваться с DXT5 для пиксель арта. Пикселей не так много, такого же сжатия можно добиться палитрой на 256 цветов. Дополнительно палитру можно будет менять для ретро эффектов.
По моему облачный гейминг отлично подходит для рекламы/демо. Можно перепробовать массу игр прежде чем окончательно купить что либо. Сейчас тот же Steam даёт текстовое описание, видео и скриншоты. Вместо одного и того же видео можно будет мгновенно поиграть в кусок игры.
P.S. «госдолг США», «негров линчуют» :)
Хороших выходных
Это скорее особенности законодательства и процессуального права. Как и написано в статье — это лишь инструмент.
Но нарушение авторских прав вполне могло быть и уголовным в США (возможен выбор)
В других странах это хороший заработок для судебной системы, адвокатов, прессы.
Причём они заработают независимо от исхода дела.
Своё оно конечно ближе и обиднее, но это скорее негативная мировая тенденция, которая просто дошла, причём с опозданием.
Я имею ввиду тот случай, когда сервер реально отвечает безразмерным/бесконечным потоком.
Ну это как-бы частный случай Observable, и где гарантии что там ответ конечный?
Я так понял что движок постоянно переписывает буфер атрибутов, но обычно туда напихивают статики и забывают — каждый кадр его обновлять довольно накладно.
Всякие простые вещи типа положения летящих пуль лучше повесить на вершинный шейдер — пусть сам вычисляет/интерполирует.
Это не генератор, т.к. он не возвращает итератор. В статье описано списковое включение.
Пример кошмарный, есть же set.
Функция-генератор это def + yield, то что описано в статье это выражение-генератор
Интерпретаторы С и С++ тоже существуют, например cling, однако носят скорее теоретическую ценность.
A то всё по-старинке через XMLHttpRequest с колбеками :)
Недавно попробовал fetch — вроде работает отлично.
О том, что есть ещё какие-то другие способы даже не знал.
С их точки зрения кстати даже довольно конструктивно :)
Но вообще набрасывать какашки и перестать пользоваться продуктом — это разные вещи. Кидаться какашками бывает довольно весело, а вот когда молча «вежливо» уходят — вот это проблема.