Но ведь это и так работает хорошо, например с тем же фильтром Ланцоша. Проблема в том ,что само изображение хранится не в линейном цветовом пространстве, а в гамма кодированном (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 гораздо лучше, но без тройки он не мог бы существовать.
На мой взгляд вот конкретно заколоченная дверь это какой-то антипаттерн. Как правило игрок имеет внушительный арсенал для тотального разрушения деревянных изделий типа коробок или бочек, но не может разломать несколько хлипких дощечек, перекрывающих проход!?
Световая индикация неплоха, но как писали выше - красный закрыто - подразумевает что его можно при каких-то условиях открыть. Если же это не так, то лучше вообще убрать цветовую индикацию вечно закрытых дверей.
На этом уровне ружьё получишь с убитого врага даже на самой низкой сложности. Что делает кнопка за красной дверью сразу после красного ключа не понятно. Как добраться до жёлтого ключа не понятно, только методом проб и ошибок.
Сначала предоставляется оружие, а затем появляется враг, требующий его применения
Это нарушается на первом же уровне первого эпизода на повышенной сложности - ружье добывается с врагов.
Игрок при использовании переключателя видит перед собой результат действия.
Это тоже нарушается повсеместно и во многих случаях нормального решения этой проблемы нет. В том же Hexen решили писать текстом где конкретно что произошло.
Игрок не заблудится при наличии в игре нормальной карты, а вот в плане того куда игроку нужно идти в игре всё не так хорошо. Да, если игрок нашел дверь одного из трёх цветов, то это именно то место, куда нужно идти после нахождения соответствующего ключа - на этом логика заканчивается - где искать ключ вообще не понятно.
Игра не следует своим же правилам. Например если проход закрыт колоннами цвета ключа и открывается при наличии ключа на месте или же требует нажатия какой-то кнопки с ключом в каком-то другом месте карты.
В игре было много хорошего и не очень, но без разбора ошибок оценка на мой взгляд не объективна.
Варианта было два - хранить/держать ссылку и не давать собрать GC или же не хранить ссылку - не мешать GC. WeakRef же третий вариант - ссылка хранится, но ненадежно - может пропасть. Удобно для всякого рода кэширования - само очистится GC.
Пример с умножением матриц неправильный ибо конкретно эта задача решается элементарно/берется готовая из библиотеки. Нужно смотреть глубже - зачем оно вообще понадобилось, а точно ли оно нужно, насколько применимо и т.д. в частности возможно что для этой задачи матрицы не надо перемножать, а обойтись кватернионами например. И тут срабатывает то, что в ВУЗе все знают про кватернионы и поэтому не будут косячить с решением/перемножением матриц. Для того чтобы вкусно готовить / хорошо рисовать / переводить с английского не обязательно иметь профильное образование, но профессионального повара, который плохо готовит, ещё стоит поискать. Никто не будет работать с врачом или например инженером строителем без образования/ сертификации и т.д. Черт возьми даже вождение автомобиля требует получения прав - от этого непосредственно зависит жизнь и здоровье людей. И там где от программиста тоже зависит жизнь и здоровье людей - внезапно тоже требуется профильное образование :) как раз что-то серьезное и ответственное.
Так исторически сложилось, когда ЭВМ были большими и решали ответственные важнейшие задачи своего времени, просто так без знания вышки / дискретки /численных методов / архитектуры ЭВМ там было нечего делать.
Но на современном рынке труда это от программистов не требуется, от ответственности отказ полнейший. Ну и вообще зачем идти в лабораторию/НИИ/завод где нужен диплом и будешь нести ответственность если можно найти место где и отвечать не надо и платят больше :)
И образование, я надеюсь,(давно было) ещё гарантирует хоть какой-то минимальный и достаточный стандарт для выполнения работы по профессии. И программирование в этом плане не сильно отличается от множества других профессий.
Конечно с оговорками и в другой формулировке все верно, но Вы пытаетесь исправить изначально провальную тут идею рекурсии, заменив её на задачу оптимизации.
Возможно смысл учебы не в этом. Учебная задача на рекурсию для чисел Фибоначчи научит тому, что её бесполезно решать таким образом. Учебная задача на факториал научит переполнению и ограничениям применения стандартных числовых типов данных.
И главный вывод - который должен сделать ученик - что рекурсию использовать не надо :)
Факториал вообще случай, когда вместо функции можно просто брать готовые значения из массива фиксированной длины. Числа Фибоначчи тоже, хоть и массив значительно больше, по сегодняшним меркам - мелочь. Зачем это вообще пересчитывать, ещё и рекурсивно?
Добавьте пожалуйста пояснение что усреднение цвета должно проводиться в линейном цветовом пространстве. Это важно - просто брать закодированные значения каналов 0-255 и складывать без учёта sRGB нельзя!
Но ведь это и так работает хорошо, например с тем же фильтром Ланцоша. Проблема в том ,что само изображение хранится не в линейном цветовом пространстве, а в гамма кодированном (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++ хуже?
Схема сетевого взаимодействия скорее усложнённая. Каждый с каждым плохо масштабируется - почему бы не начать с клиент-серверной архитектуры?
На этом уровне ружьё получишь с убитого врага даже на самой низкой сложности. Что делает кнопка за красной дверью сразу после красного ключа не понятно. Как добраться до жёлтого ключа не понятно, только методом проб и ошибок.
Не согласен :). Конкретный пример E3M7.
Это нарушается на первом же уровне первого эпизода на повышенной сложности - ружье добывается с врагов.
Это тоже нарушается повсеместно и во многих случаях нормального решения этой проблемы нет. В том же Hexen решили писать текстом где конкретно что произошло.
Игрок не заблудится при наличии в игре нормальной карты, а вот в плане того куда игроку нужно идти в игре всё не так хорошо. Да, если игрок нашел дверь одного из трёх цветов, то это именно то место, куда нужно идти после нахождения соответствующего ключа - на этом логика заканчивается - где искать ключ вообще не понятно.
Игра не следует своим же правилам. Например если проход закрыт колоннами цвета ключа и открывается при наличии ключа на месте или же требует нажатия какой-то кнопки с ключом в каком-то другом месте карты.
В игре было много хорошего и не очень, но без разбора ошибок оценка на мой взгляд не объективна.
Тут явно не хватает примера с массивом нулевого размера в конце struct :)
Варианта было два - хранить/держать ссылку и не давать собрать GC или же не хранить ссылку - не мешать GC. WeakRef же третий вариант - ссылка хранится, но ненадежно - может пропасть. Удобно для всякого рода кэширования - само очистится GC.
Пример с умножением матриц неправильный ибо конкретно эта задача решается элементарно/берется готовая из библиотеки. Нужно смотреть глубже - зачем оно вообще понадобилось, а точно ли оно нужно, насколько применимо и т.д. в частности возможно что для этой задачи матрицы не надо перемножать, а обойтись кватернионами например. И тут срабатывает то, что в ВУЗе все знают про кватернионы и поэтому не будут косячить с решением/перемножением матриц. Для того чтобы вкусно готовить / хорошо рисовать / переводить с английского не обязательно иметь профильное образование, но профессионального повара, который плохо готовит, ещё стоит поискать. Никто не будет работать с врачом или например инженером строителем без образования/ сертификации и т.д. Черт возьми даже вождение автомобиля требует получения прав - от этого непосредственно зависит жизнь и здоровье людей. И там где от программиста тоже зависит жизнь и здоровье людей - внезапно тоже требуется профильное образование :) как раз что-то серьезное и ответственное.
Так исторически сложилось, когда ЭВМ были большими и решали ответственные важнейшие задачи своего времени, просто так без знания вышки / дискретки /численных методов / архитектуры ЭВМ там было нечего делать.
Но на современном рынке труда это от программистов не требуется, от ответственности отказ полнейший. Ну и вообще зачем идти в лабораторию/НИИ/завод где нужен диплом и будешь нести ответственность если можно найти место где и отвечать не надо и платят больше :)
И образование, я надеюсь,(давно было) ещё гарантирует хоть какой-то минимальный и достаточный стандарт для выполнения работы по профессии. И программирование в этом плане не сильно отличается от множества других профессий.
Конечно с оговорками и в другой формулировке все верно, но Вы пытаетесь исправить изначально провальную тут идею рекурсии, заменив её на задачу оптимизации.
Возможно смысл учебы не в этом. Учебная задача на рекурсию для чисел Фибоначчи научит тому, что её бесполезно решать таким образом. Учебная задача на факториал научит переполнению и ограничениям применения стандартных числовых типов данных.
И главный вывод - который должен сделать ученик - что рекурсию использовать не надо :)
Факториал вообще случай, когда вместо функции можно просто брать готовые значения из массива фиксированной длины. Числа Фибоначчи тоже, хоть и массив значительно больше, по сегодняшним меркам - мелочь. Зачем это вообще пересчитывать, ещё и рекурсивно?
Добавьте пожалуйста пояснение что усреднение цвета должно проводиться в линейном цветовом пространстве. Это важно - просто брать закодированные значения каналов 0-255 и складывать без учёта sRGB нельзя!