Желаю успехов, но судоку кажется довольно избитой темой. В любом случае это будет опыт изучения коммерческого потенциала, которым можно поделиться, а на github можно закинуть и через год.
P.S. Я делал судоку в игре Newspaper puzzle (2024) на newgrounds
Кажется что ничего страшного не произойдёт даже если ноль в конце не останется после извлечения всех интересующих перестановок (их число же фиксированное). Комментарий я удалил, так как понял что входной hex переваливает за значения max safe int, и остаток от деления как раз сокращает число для нормальной работы с number
Проблема генерации судоку в другом - нужно уметь как-то оценить сложность для игрока, а это не столько само решение, сколько начальное условие (какие цифры убрать)
Блоки с явным указанием 3! и 9! выглядят страшновато, тем более что это всегда факториал от длины массива. Изящнее был бы какой-нибудь класс-помощник которому можно было передать N и запрашивать перестановки, при этом он сам бы внутри менял N.
sRGB для хранения, а не вычислений. Можно и с целыми (с фиксированной запятой) числами работать, просто у 8 бит не хватает точности.
Меня зацепило что при переводе в градации серого единственное что можно было сохранить - исказили без каких-либо примечаний что это "художественная цель" в угоду производительности.
Не знают, не настраивают, тупо забивают - я как раз это и хотел донести. Излишне качественные текстуры не являются проблемой сами по себе, а лишь в совокупности факторов.
К счастью Unreal Engine из коробки умеет подбирать уровни детализации как для текстур, так и для геометрии, что позволяет избежать подобных проблем с ресурсами. На сегодняшний день это уже не проблема художников и дизайнеров моделей, скорее проблема настройки и использования самого Unreal Engine и утилит. Пожалуй единственной проблемой слишком детализированных картинок будет итоговый размер игры на диске.
Можно предварительно рассчитать анимации физически честных бросков на каждый случай, после чего просто выбрать нужную. Чтобы не были заметны повторы, можно после использования рассчитать новую.
В процессе рассчёта можно для каждого значения сохранять полученную анимацию в стек, чтобы потом просто доставать готовую по нужному значению.
Или же просто перезапускать симуляцию пока не попадётся нужная.
Если начальное состояние не важно, то можно после рассчёта анимации поменять грани так, чтобы выпало то, что надо.
Патенты хороши тем, что они в открытом доступе - с ними можно ознакомиться - кроме того их ценность подтверждена (они не бесплатные для получения и требуют активной защиты со стороны правообладателя).
Патент - патенту рознь, и хотя между собой они могут отличаться в разы, при увеличении их количества влияние каждого отдельного патента стремится к среднему, т.е. сравнить 3 и 5 патентов объективно не получается, а вот 3000 и 5000 - уже более объективно, 30к и 50к - ещё лучше
подталкивает пользователей к определенным установкам просто потому, что учится на их взаимодействиях и непрерывно прогрессирует с ними с ними.
"Случайный захват" уже произошел - пользователи деградируют до текущего уровня ИИ, разжевывая очевидные вещи в простыню контекста. По факту это просто поиск наиболее похожего по шаблону, и если ничего похожего там изначально не было - ничего и не найдешь. Для прогресса нужны новые данные, в процессе взаимодействия с пользователями новых данных ничтожно мало для какого-то существенного влияния на модель.
С версии 3.12 в itertools наконец-то появился batched, до этого писали свои костыли со слайсами, всякие chunks и т.п. чтобы делить на куски. Мелочь, но приятно
Технически WebP сложнее в реализации, но степень сжатия без потерь там обычно выше чем у PNG. В большинстве случаев на сайте можно обойтись только WebP, полностью заменив JPG/PNG/GIF.
Желаю успехов, но судоку кажется довольно избитой темой. В любом случае это будет опыт изучения коммерческого потенциала, которым можно поделиться, а на github можно закинуть и через год.
P.S. Я делал судоку в игре Newspaper puzzle (2024) на newgrounds
Кажется что ничего страшного не произойдёт даже если ноль в конце не останется после извлечения всех интересующих перестановок (их число же фиксированное). Комментарий я удалил, так как понял что входной hex переваливает за значения max safe int, и остаток от деления как раз сокращает число для нормальной работы с number
Проблема генерации судоку в другом - нужно уметь как-то оценить сложность для игрока, а это не столько само решение, сколько начальное условие (какие цифры убрать)
Блоки с явным указанием 3! и 9! выглядят страшновато, тем более что это всегда факториал от длины массива. Изящнее был бы какой-нибудь класс-помощник которому можно было передать N и запрашивать перестановки, при этом он сам бы внутри менял N.
Типа:
reader = new PermutationsReader(N)
pDigits = reader.readPermutation([1,2,3,4,5,6,7,8,9]);
...
const pRows = reader.readPermutations([0,1,2], 3)
Там даже больше информации о состоянии станка можно штатно получить, но это надо читать документацию, подключаться... не модно
Да, коэффициенты не те. В Gimp кстати всё есть https://docs.gimp.org/3.0/en/gimp-filter-desaturate.html - даже на скриншоте из документации.
sRGB для хранения, а не вычислений. Можно и с целыми (с фиксированной запятой) числами работать, просто у 8 бит не хватает точности.
Меня зацепило что при переводе в градации серого единственное что можно было сохранить - исказили без каких-либо примечаний что это "художественная цель" в угоду производительности.
Да, применяется одинаково. Нет, отношение чисел и условно квадратов чисел не будет одинаковым.
Корректный алгоритм приведет значения в линейное пространство, посчитает взвешенную сумму и обратно гамма кодирует.
Конвертация RGB в градации серого
Увы, но это так не работает, т.к. компоненты гамма кодированы, их взвешенная сумма является сильно искажённой.
Не знают, не настраивают, тупо забивают - я как раз это и хотел донести. Излишне качественные текстуры не являются проблемой сами по себе, а лишь в совокупности факторов.
К счастью Unreal Engine из коробки умеет подбирать уровни детализации как для текстур, так и для геометрии, что позволяет избежать подобных проблем с ресурсами. На сегодняшний день это уже не проблема художников и дизайнеров моделей, скорее проблема настройки и использования самого Unreal Engine и утилит. Пожалуй единственной проблемой слишком детализированных картинок будет итоговый размер игры на диске.
Радуемся настоящему. В будущем лучше не станет, если смотреть на Китай
Может только у меня так, но цветные строки из оригинала сломаны в переводе.
Одно другому не противоречит, просто с графиками числа пользователей по годам/месяцам это было бы понятнее, но тогда магия исчезает.
Можно предварительно рассчитать анимации физически честных бросков на каждый случай, после чего просто выбрать нужную. Чтобы не были заметны повторы, можно после использования рассчитать новую.
В процессе рассчёта можно для каждого значения сохранять полученную анимацию в стек, чтобы потом просто доставать готовую по нужному значению.
Или же просто перезапускать симуляцию пока не попадётся нужная.
Если начальное состояние не важно, то можно после рассчёта анимации поменять грани так, чтобы выпало то, что надо.
Патенты хороши тем, что они в открытом доступе - с ними можно ознакомиться - кроме того их ценность подтверждена (они не бесплатные для получения и требуют активной защиты со стороны правообладателя).
Патент - патенту рознь, и хотя между собой они могут отличаться в разы, при увеличении их количества влияние каждого отдельного патента стремится к среднему, т.е. сравнить 3 и 5 патентов объективно не получается, а вот 3000 и 5000 - уже более объективно, 30к и 50к - ещё лучше
Если я правильно понял статью, то чел боялся потерять работу, и с большой вероятностью он бы получил нужную справку, просто солгав так или иначе.
"Случайный захват" уже произошел - пользователи деградируют до текущего уровня ИИ, разжевывая очевидные вещи в простыню контекста. По факту это просто поиск наиболее похожего по шаблону, и если ничего похожего там изначально не было - ничего и не найдешь. Для прогресса нужны новые данные, в процессе взаимодействия с пользователями новых данных ничтожно мало для какого-то существенного влияния на модель.
Про него хотя-бы написали, я не понимаю почему нет ни слова про Object.is
С версии 3.12 в itertools наконец-то появился batched, до этого писали свои костыли со слайсами, всякие chunks и т.п. чтобы делить на куски. Мелочь, но приятно
Технически WebP сложнее в реализации, но степень сжатия без потерь там обычно выше чем у PNG. В большинстве случаев на сайте можно обойтись только WebP, полностью заменив JPG/PNG/GIF.