Не вводите людей в заблуждение.
"LINQ for iOS" — Вот этот плагин заменяет библиотеку LINQ на работающую в iOS. Все отлично работает, проверено на личном опыте.
Зачем и кому это (read/write) нужно — я написал. Это случай на самый-самый край, который используется только когда никак иначе нельзя. Вы прививаете себе, в главное — всем читающим изначально неверные привычки. Вы увеличили расход памяти в разы (если сравнивать со сжатым атласом, то получится раза в 4-8, в зависимости от формата сжатия), вы понизили производительность на порядок, и все это без какой-либо необходимости делать именно так. Кроме того, вы написали 3 десятка строк там, где можно было обойтись одной. Если вы говорите «я не почувствовал», то это исключительно из-за размера проекта.
Хотите дальше забавать гвозди микроскопом — ок, я не буду переубеждать.
Я лишь буду надеяться, что эта статья никому не пригодится и никто не воспримет ее как руководство к действию :)
Вы меня простите, но все чему вы «учите» в этой статье — категорически неверно и нужно бить по рукам каждый раз, когда кто-то делает нечто подобное.
1. Texture read/write очень сильно потребляет расход памяти, делает невозможным использование сжатия текстур, да и вообще — работает очень медленно. Для целей определения клика отлично подходит система полигональных коллайдеров.
2. Осветление текстуры однозначно надо делать шейдером. Это просто в сотни (а то и тысячи) раз быстрее. Менять пиксели в текстуре — это вообще из ряда вон выходящая практика и применяется крайне редко, когда без нее никак (например, когда нужно рисовать мышкой на текстуре и т.п.)
В результате вы написали тонну лишнего кода (все эти беганья по текстурам и сравнивание пикселей), где можно было обойтись одной строчкой кода «получить объект под мышкой». Да, придется обвести коллайдером спрайт. Но это не так страшно и быстро. Да и если очень хочется, есть автоматические тулзы.
Любой уважающий себя программист просто обязан знать английский. Ну, поможете вы ему сейчас переведя книжку. А дальше что? Будете ему stack overflow переводить?
Для того, чтобы посмотреть, в каком формате у вас текстуры, надо всего лишь открыть APK (это ведь ZIP) и посмотреть. Вы увидите, что текстуры не зависят от изначального формата (jpg, png). Они там хранятся в том формате, какое сжатие вы выбрали (32 бита на пиксель и т.п.)
Код… Скажем так, весьма обфусцированный =) Но с первого взгляда не очень громоздкий.
А вообще — тут совсем не имеет значения, ведь речь идет о скриптинге ивентов, а не об апдейте, который крутится каждый фрейм для каждого из 10 тыс. объектов. Так что оверхед тут абсолютно не важен.
Что там происходит за пределами диаграммы, не суть важно. Важно именно то, что у ГД в руках инструмент со схемами и стрелочками и кодить он не лезет ;)
Стоковый скриптинг не подходит. Скриптование квестов и т.п. — задача гейм-дизайнера. Гейм-дизайнер не должен лазить в код. Редактировать исходники игры для добавления нового квеста — однозначно неверное решение.
А то, что схемы не влезают в экран — тоже не проблема. Есть скроллинг и зуминг.
"LINQ for iOS" — Вот этот плагин заменяет библиотеку LINQ на работающую в iOS. Все отлично работает, проверено на личном опыте.
Мне просто пока не пришлось глубоко сталкиваться с новым uGUI, я старообрядец.
Хотите дальше забавать гвозди микроскопом — ок, я не буду переубеждать.
Я лишь буду надеяться, что эта статья никому не пригодится и никто не воспримет ее как руководство к действию :)
1. Texture read/write очень сильно потребляет расход памяти, делает невозможным использование сжатия текстур, да и вообще — работает очень медленно. Для целей определения клика отлично подходит система полигональных коллайдеров.
2. Осветление текстуры однозначно надо делать шейдером. Это просто в сотни (а то и тысячи) раз быстрее. Менять пиксели в текстуре — это вообще из ряда вон выходящая практика и применяется крайне редко, когда без нее никак (например, когда нужно рисовать мышкой на текстуре и т.п.)
В результате вы написали тонну лишнего кода (все эти беганья по текстурам и сравнивание пикселей), где можно было обойтись одной строчкой кода «получить объект под мышкой». Да, придется обвести коллайдером спрайт. Но это не так страшно и быстро. Да и если очень хочется, есть автоматические тулзы.
value =2
просто недопустима. Это выглядит ужасно и неаккуратно. Лучше уж «value=2», чем ЭТО.
А вообще — тут совсем не имеет значения, ведь речь идет о скриптинге ивентов, а не об апдейте, который крутится каждый фрейм для каждого из 10 тыс. объектов. Так что оверхед тут абсолютно не важен.
Стоковый скриптинг не подходит. Скриптование квестов и т.п. — задача гейм-дизайнера. Гейм-дизайнер не должен лазить в код. Редактировать исходники игры для добавления нового квеста — однозначно неверное решение.
А то, что схемы не влезают в экран — тоже не проблема. Есть скроллинг и зуминг.