Есть стандартный чанк iTXt, который хорошо подходит для хранения сжатого текста UTF-8 (JSON)
Чем стандартный чанк хорош - для него есть готовые библиотеки, из коробки получаем сжатие deflate, проверку целостности и частичную поддержку редакторами
Очереди не нужны, можно открыть предзаказ заранее и по результатам определить сколько нужно произвести чтобы всем хватило. Как покупателю мне важнее стабильно получить товар в оговоренные сроки, а не играться в очереди с продавцом
Потребитель сканирует код, но получает минимум информации
И как эта проблема сейчас решается?
Как дотошный покупатель я хочу проверить что тот мятый липкий огрызок бумажки, который я с трудом отсканировал соответствует товару, к которому он был прицеплен. Ожидаю что мне перед покупкой покажут хотя бы дату истечения срока годности, а не "Товар очень полезный диетический со вкусом ..."
Желаю успехов, но судоку кажется довольно избитой темой. В любом случае это будет опыт изучения коммерческого потенциала, которым можно поделиться, а на github можно закинуть и через год.
P.S. Я делал судоку в игре Newspaper puzzle (2024) на newgrounds
Кажется что ничего страшного не произойдёт даже если ноль в конце не останется после извлечения всех интересующих перестановок (их число же фиксированное). Комментарий я удалил, так как понял что входной hex переваливает за значения max safe int, и остаток от деления как раз сокращает число для нормальной работы с number
Проблема генерации судоку в другом - нужно уметь как-то оценить сложность для игрока, а это не столько само решение, сколько начальное условие (какие цифры убрать)
Блоки с явным указанием 3! и 9! выглядят страшновато, тем более что это всегда факториал от длины массива. Изящнее был бы какой-нибудь класс-помощник которому можно было передать N и запрашивать перестановки, при этом он сам бы внутри менял N.
sRGB для хранения, а не вычислений. Можно и с целыми (с фиксированной запятой) числами работать, просто у 8 бит не хватает точности.
Меня зацепило что при переводе в градации серого единственное что можно было сохранить - исказили без каких-либо примечаний что это "художественная цель" в угоду производительности.
Не знают, не настраивают, тупо забивают - я как раз это и хотел донести. Излишне качественные текстуры не являются проблемой сами по себе, а лишь в совокупности факторов.
К счастью Unreal Engine из коробки умеет подбирать уровни детализации как для текстур, так и для геометрии, что позволяет избежать подобных проблем с ресурсами. На сегодняшний день это уже не проблема художников и дизайнеров моделей, скорее проблема настройки и использования самого Unreal Engine и утилит. Пожалуй единственной проблемой слишком детализированных картинок будет итоговый размер игры на диске.
Можно предварительно рассчитать анимации физически честных бросков на каждый случай, после чего просто выбрать нужную. Чтобы не были заметны повторы, можно после использования рассчитать новую.
В процессе рассчёта можно для каждого значения сохранять полученную анимацию в стек, чтобы потом просто доставать готовую по нужному значению.
Или же просто перезапускать симуляцию пока не попадётся нужная.
Если начальное состояние не важно, то можно после рассчёта анимации поменять грани так, чтобы выпало то, что надо.
Есть стандартный чанк iTXt, который хорошо подходит для хранения сжатого текста UTF-8 (JSON)
Чем стандартный чанк хорош - для него есть готовые библиотеки, из коробки получаем сжатие deflate, проверку целостности и частичную поддержку редакторами
Почему отказались от блока (чанка) PNG? Кажется графические редакторы сохраняют неизвестные блоки внутри PNG, а вот "хвост" могут и потерять
Очереди не нужны, можно открыть предзаказ заранее и по результатам определить сколько нужно произвести чтобы всем хватило. Как покупателю мне важнее стабильно получить товар в оговоренные сроки, а не играться в очереди с продавцом
Не понимаю зачем для тайла из пары треугольников вообще использовать инстансинг и что делать со щелями на границах тайлов в худшем случае.
Ждём результаты анализов тогда
И как эта проблема сейчас решается?
Как дотошный покупатель я хочу проверить что тот мятый липкий огрызок бумажки, который я с трудом отсканировал соответствует товару, к которому он был прицеплен. Ожидаю что мне перед покупкой покажут хотя бы дату истечения срока годности, а не "Товар очень полезный диетический со вкусом ..."
Желаю успехов, но судоку кажется довольно избитой темой. В любом случае это будет опыт изучения коммерческого потенциала, которым можно поделиться, а на 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 и утилит. Пожалуй единственной проблемой слишком детализированных картинок будет итоговый размер игры на диске.
Радуемся настоящему. В будущем лучше не станет, если смотреть на Китай
Может только у меня так, но цветные строки из оригинала сломаны в переводе.
Одно другому не противоречит, просто с графиками числа пользователей по годам/месяцам это было бы понятнее, но тогда магия исчезает.
Можно предварительно рассчитать анимации физически честных бросков на каждый случай, после чего просто выбрать нужную. Чтобы не были заметны повторы, можно после использования рассчитать новую.
В процессе рассчёта можно для каждого значения сохранять полученную анимацию в стек, чтобы потом просто доставать готовую по нужному значению.
Или же просто перезапускать симуляцию пока не попадётся нужная.
Если начальное состояние не важно, то можно после рассчёта анимации поменять грани так, чтобы выпало то, что надо.