Можно предварительно рассчитать анимации физически честных бросков на каждый случай, после чего просто выбрать нужную. Чтобы не были заметны повторы, можно после использования рассчитать новую.
В процессе рассчёта можно для каждого значения сохранять полученную анимацию в стек, чтобы потом просто доставать готовую по нужному значению.
Или же просто перезапускать симуляцию пока не попадётся нужная.
Если начальное состояние не важно, то можно после рассчёта анимации поменять грани так, чтобы выпало то, что надо.
Патенты хороши тем, что они в открытом доступе - с ними можно ознакомиться - кроме того их ценность подтверждена (они не бесплатные для получения и требуют активной защиты со стороны правообладателя).
Патент - патенту рознь, и хотя между собой они могут отличаться в разы, при увеличении их количества влияние каждого отдельного патента стремится к среднему, т.е. сравнить 3 и 5 патентов объективно не получается, а вот 3000 и 5000 - уже более объективно, 30к и 50к - ещё лучше
подталкивает пользователей к определенным установкам просто потому, что учится на их взаимодействиях и непрерывно прогрессирует с ними с ними.
"Случайный захват" уже произошел - пользователи деградируют до текущего уровня ИИ, разжевывая очевидные вещи в простыню контекста. По факту это просто поиск наиболее похожего по шаблону, и если ничего похожего там изначально не было - ничего и не найдешь. Для прогресса нужны новые данные, в процессе взаимодействия с пользователями новых данных ничтожно мало для какого-то существенного влияния на модель.
С версии 3.12 в itertools наконец-то появился batched, до этого писали свои костыли со слайсами, всякие chunks и т.п. чтобы делить на куски. Мелочь, но приятно
Технически WebP сложнее в реализации, но степень сжатия без потерь там обычно выше чем у PNG. В большинстве случаев на сайте можно обойтись только WebP, полностью заменив JPG/PNG/GIF.
Для "тщательно разработанных" выглядит странно. Отдельный remove выглядит избыточным, выставление undefined ведь делает то же самое.
Не понимаю почему в хранилище нельзя писать сразу синхронно, просто вернув обёртку над сеттером из стейта и сразу же ловить ошибку, зачем эффект?
Эффект нужен для другого - так как хранилище общее, а компонентов которым оно нужно может быть несколько, то нужно как-то узнавать об изменениях. Про это вообще думали?
Но ведь это и так работает хорошо, например с тем же фильтром Ланцоша. Проблема в том ,что само изображение хранится не в линейном цветовом пространстве, а в гамма кодированном (sRGB), и при преобразовании делается выбор в пользу более точного совпадения отдельных пикселей, а не суммы группы. Если я правильно понимаю - скрипт как раз компенсирует накопившуюся ошибку группы, но по сути это же добавление шума чтобы сумма по группе сошлась?
Качество сильно зависит от тесселяции - на больших треугольниках 3х цветов по углам не будет хватать для передачи деталей освещения, на малых же наоборот излишне. Текстура освещения позволяет передавать консистентное качество из-за привязки к развертке
Создание новой раскраски/освещения руками гораздо быстрее чем перекраска вершин
Monument Valley использует Unity и унаследовал оттуда системные требования.
При создании игры в 2022м разработчики не писали свой собственный движок, а взяли уже готовый и актуальный на момент создания.
Допустим вместо Unity разработчики выбрали бы Unreal. Доступный для использования в 2022м это Unreal Engine 5 - его системные требования тоже на порядки выше версии 1998 года и не сильно отличаются от Unity.
Разработчик имея на руках основу в виде современного движка для игр 2022 года занимается тем, чтобы стилизовать его под свои нужды. Делает дополнительные действия чтобы игра выглядела как из 1998 года.
При всём желании они не могли использовать Unreal 1998 в 2022м, потому что он уже не продается.
Но допустим для игры было бы достаточно движка Quake из 1996. Он есть в открытом доступе, но для его разработки требуются знания и работа с технологией того времени, а это дорого и долго + на выходе будет игра только на ПК без мобильной/кроссплатформенной версии.
Разработчик хотел донести игру до максимального числа пользователей с минимальными затратами - задача выполнена.
Довольно странная рекомендация - для уменьшения промахов кэша использовать сортировку. Кажется что сама по себе сортировка каких-то не примитивных объектов создаст больше промахов кэша чем потенциальный выигрыш.
Очень странное сравнение. Основной сценарий использования БД - это чтение (с join, group by, и т.д.), а не запись. Читаем 20 секунд, пишем одну. Ускорение записи в 3 раза даст меньший выигрыш, чем ускорение чтения на 5%, а в некоторых сценариях будет гораздо выше 1 к 20, какой-нибудь новостной сайт где пишется 100 новостей в день и миллион просмотров.
И получается что БД где запись в три раза быстрее абсолютно проигрывает БД где чтение на каких-то 5% быстрее.
Успех Fallout 3 (игра года) - заслуга серии Elder Scrolls. По сути Bethesda получала игру года за Oblivion, Fallout 3, Skyrim... Попадись им другая франшиза, вместо Fallout например Wasteland - вместо Fallout 3 та же самая команда сделала бы Wasteland 2 игрой года. И да - это точно так же была бы пересборка Oblivion. Просто повезло что дали серии новую жизнь.
Как продолжение именно Fallout - New Vegas гораздо лучше, но без тройки он не мог бы существовать.
На мой взгляд вот конкретно заколоченная дверь это какой-то антипаттерн. Как правило игрок имеет внушительный арсенал для тотального разрушения деревянных изделий типа коробок или бочек, но не может разломать несколько хлипких дощечек, перекрывающих проход!?
Световая индикация неплоха, но как писали выше - красный закрыто - подразумевает что его можно при каких-то условиях открыть. Если же это не так, то лучше вообще убрать цветовую индикацию вечно закрытых дверей.
Можно предварительно рассчитать анимации физически честных бросков на каждый случай, после чего просто выбрать нужную. Чтобы не были заметны повторы, можно после использования рассчитать новую.
В процессе рассчёта можно для каждого значения сохранять полученную анимацию в стек, чтобы потом просто доставать готовую по нужному значению.
Или же просто перезапускать симуляцию пока не попадётся нужная.
Если начальное состояние не важно, то можно после рассчёта анимации поменять грани так, чтобы выпало то, что надо.
Патенты хороши тем, что они в открытом доступе - с ними можно ознакомиться - кроме того их ценность подтверждена (они не бесплатные для получения и требуют активной защиты со стороны правообладателя).
Патент - патенту рознь, и хотя между собой они могут отличаться в разы, при увеличении их количества влияние каждого отдельного патента стремится к среднему, т.е. сравнить 3 и 5 патентов объективно не получается, а вот 3000 и 5000 - уже более объективно, 30к и 50к - ещё лучше
Если я правильно понял статью, то чел боялся потерять работу, и с большой вероятностью он бы получил нужную справку, просто солгав так или иначе.
"Случайный захват" уже произошел - пользователи деградируют до текущего уровня ИИ, разжевывая очевидные вещи в простыню контекста. По факту это просто поиск наиболее похожего по шаблону, и если ничего похожего там изначально не было - ничего и не найдешь. Для прогресса нужны новые данные, в процессе взаимодействия с пользователями новых данных ничтожно мало для какого-то существенного влияния на модель.
Про него хотя-бы написали, я не понимаю почему нет ни слова про Object.is
С версии 3.12 в itertools наконец-то появился batched, до этого писали свои костыли со слайсами, всякие chunks и т.п. чтобы делить на куски. Мелочь, но приятно
Технически WebP сложнее в реализации, но степень сжатия без потерь там обычно выше чем у PNG. В большинстве случаев на сайте можно обойтись только WebP, полностью заменив JPG/PNG/GIF.
PNG без потерь, под капотом фильтрация для предсказания по трём соседним пикселям + DEFLATE
Технически лучше чем GIF и BMP, на сегодняшний день сожран WebP как и большинство других растровых форматов.
Да, извиняюсь - как-то пропустил этот момент. К качеству перевода претензий нет.
Для "тщательно разработанных" выглядит странно. Отдельный remove выглядит избыточным, выставление undefined ведь делает то же самое.
Не понимаю почему в хранилище нельзя писать сразу синхронно, просто вернув обёртку над сеттером из стейта и сразу же ловить ошибку, зачем эффект?
Эффект нужен для другого - так как хранилище общее, а компонентов которым оно нужно может быть несколько, то нужно как-то узнавать об изменениях. Про это вообще думали?
Но ведь это и так работает хорошо, например с тем же фильтром Ланцоша. Проблема в том ,что само изображение хранится не в линейном цветовом пространстве, а в гамма кодированном (sRGB), и при преобразовании делается выбор в пользу более точного совпадения отдельных пикселей, а не суммы группы. Если я правильно понимаю - скрипт как раз компенсирует накопившуюся ошибку группы, но по сути это же добавление шума чтобы сумма по группе сошлась?
Что такое "правило RIS"?
Vertex Color хуже:
Дополнительно 4 байта на каждую вершину/нормаль
Качество сильно зависит от тесселяции - на больших треугольниках 3х цветов по углам не будет хватать для передачи деталей освещения, на малых же наоборот излишне. Текстура освещения позволяет передавать консистентное качество из-за привязки к развертке
Создание новой раскраски/освещения руками гораздо быстрее чем перекраска вершин
Monument Valley использует Unity и унаследовал оттуда системные требования.
При создании игры в 2022м разработчики не писали свой собственный движок, а взяли уже готовый и актуальный на момент создания.
Допустим вместо Unity разработчики выбрали бы Unreal. Доступный для использования в 2022м это Unreal Engine 5 - его системные требования тоже на порядки выше версии 1998 года и не сильно отличаются от Unity.
Разработчик имея на руках основу в виде современного движка для игр 2022 года занимается тем, чтобы стилизовать его под свои нужды. Делает дополнительные действия чтобы игра выглядела как из 1998 года.
При всём желании они не могли использовать Unreal 1998 в 2022м, потому что он уже не продается.
Но допустим для игры было бы достаточно движка Quake из 1996. Он есть в открытом доступе, но для его разработки требуются знания и работа с технологией того времени, а это дорого и долго + на выходе будет игра только на ПК без мобильной/кроссплатформенной версии.
Разработчик хотел донести игру до максимального числа пользователей с минимальными затратами - задача выполнена.
Довольно странная рекомендация - для уменьшения промахов кэша использовать сортировку. Кажется что сама по себе сортировка каких-то не примитивных объектов создаст больше промахов кэша чем потенциальный выигрыш.
Очень странное сравнение. Основной сценарий использования БД - это чтение (с join, group by, и т.д.), а не запись. Читаем 20 секунд, пишем одну. Ускорение записи в 3 раза даст меньший выигрыш, чем ускорение чтения на 5%, а в некоторых сценариях будет гораздо выше 1 к 20, какой-нибудь новостной сайт где пишется 100 новостей в день и миллион просмотров.
И получается что БД где запись в три раза быстрее абсолютно проигрывает БД где чтение на каких-то 5% быстрее.
Баги традиционно были неотъемлемой частью Fallout. Особенно если брать версии от Фаргуса.
Успех Fallout 3 (игра года) - заслуга серии Elder Scrolls. По сути Bethesda получала игру года за Oblivion, Fallout 3, Skyrim... Попадись им другая франшиза, вместо Fallout например Wasteland - вместо Fallout 3 та же самая команда сделала бы Wasteland 2 игрой года. И да - это точно так же была бы пересборка Oblivion. Просто повезло что дали серии новую жизнь.
Как продолжение именно Fallout - New Vegas гораздо лучше, но без тройки он не мог бы существовать.
На мой взгляд вот конкретно заколоченная дверь это какой-то антипаттерн. Как правило игрок имеет внушительный арсенал для тотального разрушения деревянных изделий типа коробок или бочек, но не может разломать несколько хлипких дощечек, перекрывающих проход!?
Световая индикация неплоха, но как писали выше - красный закрыто - подразумевает что его можно при каких-то условиях открыть. Если же это не так, то лучше вообще убрать цветовую индикацию вечно закрытых дверей.
Тоже не понял зачем в примере нужен useEffect?
Чем простой return useRef(0).current++ хуже?