Есть ограничение на компенсацию — больше чем на N кадров враг не откатится. В рамках этого значения тяжело получить какое-то преимущество, даже если подменять трафик

С читерами, конечно, будем бороться и банить

У меня иногда секунд 40 запускается, за это время пару раз появляется окно «проверка на вирусы не была завершена», где жмется «повторить». Но прошлая версия на этом моменте висла, так что уже лучше :) А новый дизайн очень здоровский.

Еще, если нужен более полный контроль над AppController-ом (извиняюсь за каламбур), можно просто отнаследоваться от classes/UnityAppController и переопределить нужные методы (не забывая добавлять [super ...]). Для того, чтобы использовался новый AppController вместо дефолтного, нужно дополнительно поправить main.mm (а конкретно AppControllerClassName поле)

«Расковырять можно все, что угодно» равно по смыслу «принципиально невозможно защитить», как по мне :) Я писал про то, что можно усложнить это по максимуму. Выводя проверку хешей в нативку, а баны и контрольные чеки различной логики на сервер. Если брать не сферический проект в вакууме, а реальный, этого часто бывает достаточно. Конечно, есть много факторов, которые на это влияют, в частности объем аудитории и тип проекта (оффлайн — онлайн — частично онлайн)

Разве я писал, что это возможно? Наоборот в конце подчеркнул, что вовсе нет

Я не писал, что что-то этому мешает, вопрос лишь в сложности. C# сборку легче расковырять чем найти .so и расковырять ее. Соответственно, из .so не должны торчать концы (кроме как loadLibrary), и уж точно она не должна общаться или обмениваться данными с managed-кодом (в идеале). Опять же, расковырять все что угодно можно, конечно. Но иногда достаточно увеличить сложность взлома, и энтузиастов это сделать может уже не найтись. А могут и найтись :)

Есть еще такой вариант, как проверить, играет ли пользователь со взломанной .apk-шки (т.е. используя патченную Assembly-CSharp.dll) — хранить хеш сборки на сервере для каждой версии. При старте игры вычисляется хеш локальной сборки, затем отправляется серверу. Сервер ее проверяет, и, если она неверная, запоминает это. Затем через определенное время включается банхаммер, и всем юзерам, от которых был прислан неверный хеш, присваивается бан, показывается окно «поди прочь» (или еще что-то, зависит от реализации). Конечно, вычисление и отправку хеша нет смысла класть в Assembly-CSharp — если в ней поломали уже что-то, то могут поломать и это, а значит нужно как можно меньше зависимости от c# и java. Вариант — сделать либу на JNI, которая этим занимается. Тогда ее использование сводится к строке System.loadLibrary(«you_native_library_name») (при использовании JNI_OnLoad), которую найти посложнее. Но и это не гарантирует полной защиты, конечно. Тем не менее планка взлома слегка повышается. Так же, отложенный банхаммер не дает сразу понять читеру, на основании чего он произошел.

Это не связано с интерполяцией, а просто оптимизация. Таким образом это реализовано в железе в различных GPU. Барицентрические координаты считаются уже после того, как выясняется, что точка внутри треугольника и используются для интерполяции. Нет смысла считать их до того момента, как это выяснится. Это особенно критично при использовании bounding-box алгоритма, поскольку кол-во проверяемых пикселей, не попадающих в полигон, может быть велико. Я не говорю, что у вас так должно быть реализовано, разумеется, просто рассказал про оптимизацию

Еще быстрее — это посчитать линейные функции, которые задают грани полигона. Затем достаточно посчитать значения этих функций в самом первом пикселе в bounding box. Далее значения этих функций в соседних пикселях вычисляется за счет одного сложения, например f(x +1, y) = f(x, y) + a, где a — соответствующий коэф. в функции грани ax + by + c

Не дело с концом. Чтобы избежать графических артефактов, как например дыры между полигонами (упомянуто у вас) или перезаписывание пикселей на смежных гранях, нужно добавлять код для реализации filling convention, например top-left rule. Плюс, для проверки принадлежности пикселя к треугольнику достаточно вычислить значения линейных функций, которые заданными гранями треугольника, и необязательно до этого считать барицентрические координаты. Их можно посчитать потом, как только установлено, что пиксель внутри

Суть рендерера — во многом «матан» :) Прежде чем писать, нужно понимать, что писать и откуда берутся такие формулы

Может, я неверно понял вопрос, но разве кол-во точек схода в итоговом изображении не зависит от ориентации камеры? Если плоскость проекции пересекает все три оси, то мы получим трехточечную проекцию, но мы так же можем получить двух или одно-точечную, в зависимости от угла просмотра

Я вообще не занимался никакой оптимизацией на данном этапе. Может быть, позже, это интересная тема. В ближайшее время в статьях будет упор на описание алгоритмов, а не на их оптимизацию в коде. Сейчас, на модели с 27к вершин, 90 FPS (с -О3) с вьюпортом 640х480, i7-3770K

Подача материала в разных статьях и соответствующей литературе существенно различается. Всегда хорошо иметь выбор, что почитать на эту тему. Кому-то, возможно, приглянется мой вариант

Не стоит, согласен. Нужно поправить. Но этот пост не из хаба «идеальный код», и на него не претендует, поэтому можете смело сделать фикс и отправить пулл реквест, если хотите :)

В ближайшее время таких планов точно нет, возможно в будущем. Было бы интересно над этим поработать