Как вы организовали поддержку 1к моделей для андроида, составляли какие-то таблицы поддерживаемых технологий для каждой модели и группировали по ним? Или у вас ферма для тестирования из тысячи трубок? Слышал, что в рамках одного коммерческого названия модели может быть целая группа устройств с совершенно разным железом, вы с таким сталкивались?
Слетайте в США и пообщайтесь с уродцами из TSA, тогда поймете. У 90% их служащих синдром вахтера в терминальной стадии. Один раз меня задержали на досмотр на 40 минут, если бы во время этого досмотра мой рейс не задержали на несколько часов по техническим причинам, я бы на него опоздал (ха, и кого из них это волнует). Никто даже не извинился, я уже молчу про то, что бы внятно объяснить мне причину досмотра. Не удивительно, что многие в США питают ненависть к этой псевдополезной службе.
Это вы извините, обычный сотрудник и работодатель находятся в совершенно разных условиях. Первый — наемный работник, а второй — предприниматель, со всеми вытекающими. Первый получает стабильную зарплату, и, возможно, помогает второму получать прибыль. До тех пор, пока сотрудник не будет явно участвовать и разделять ответственность в рисках (финансовых, репутационных и т.д.) работодателя, никакими партнерами они не будут.
Я не читал отзыв, но я много наслышан про одного из соавторов, который может и неплохой журналист, но ученый никудышный. Конечно, все были бы рады, если бы получилось сделать рабочий термоядерный реактор в гараже, но в данном случае, зная авторов проекта, лично у меня доверия к нему нет.
На международных краудфандинговых платформах уже довольно давно наблюдается интересная тенденция: сбор денег на разного рода научно-популярные и научные проекты.
Тенденция есть, но она не очень здоровая, научных проектов там единицы, а вот шарлотанов полно, включая и этот проект. И с каждым таким проектом довере к краудфандингу снижается.
И завести еще пару-тройку инженеров на отлов непонятных багов и постоянные танцы с бубном для апгрейдов под актуальные версии макоси и ПО? Не говоря уже о проблемах с легальностью такого решения.
Я думал они 1 в 1 передрали API кокоса. Значит я вам не помогу с этим, к сожалению.
Здесь я согласен с вами, но возможная потеря пропорций меня напрягала. Как с этим бороться?
Универсального рецепта нет, к сожалению. Для приложений вроде вашего, где вся сцена должна располагаться на одном экране (если я правильно понял), техники примерно могут быть следующими:
— при поддержке 4+ айфонов, можно принимать размер экрана 4ки за всю активную игровую сцену (с клетками), а на 5+ девайсах добавлять арт, компенсирующий разницу в высоте. В вашем случае можно было сделать разные элементы управления: вашу текущую версию оставить для 5+, а для 4+ сделать более компактное меню (ваше вполне можно уменьшить в пару раз без потери функциональности).
— при поддержке зоопарка андроидов, а так же 6+ айфонов, делать несколько наборов ассетов + скалирование. Для вашего случая за минимальный размер экрана можно было бы выбрать 4й айфон, условно говоря это был бы размер 1х. При загрузке игры расчитывать размер клетки (исходя из разрешения экрана и количества клеток по вертикали-горизонтали). Если размер больше 4го айфоновского, но меньше условного 1.5х, то брать ассеты размера 1.5х и скейлить до нужного размера. Если больше 1.5х, то скейлить из 2х и т.д. Все зависит от спектра поддерживаемых разрешений. По хорошему вы должны требовать от художника всего арта в нескольких размерах сразу, к примеру исходный, 2х и 4х для планшетов. В идеале вы должны следить, что бы ассеты были нарисованы под каждый размер (с уменьшением/увеличением детализации), а не просто отскейлеными в фотошопе, но это будет очень дорого, особенно учитывая анимации.
— весь код должен работать с design resolution, а не напрямую с физическим разрешением экрана. Как дела обстоят в вашем фреймворке я не знаю.
Да, скалирование не бесплатная операция, но я не знаком с sprite kit, поэтому не могу дать какие-то советы на этот счет.
ширина текстовой надписи (UILabel) изменялась и менялось само расстояние между символами, что нас не устраивало
Нужно было сразу или искать моноширный шрифт или делать его самому как bitmap font (что надо было делать с самого начала, если вы конечно считаете draw calls).
Не обижайтесь, но сам подход «подгонка по пикселям GUI» не будет работать ни на одной платформе нормально. После выхода 6го айфона неумение работать с разными разрешениями вам аукнется. Я молчу про андроид.
Удивительно что на такой простой сцене у вас возникли какие-то проблемы с производительностью. Вы использовали стандартные техники SpriteFrameCache и SpriteBatchNode?
Спасибо, к сожалению пропустил ссылку на прошлую статью, как и саму статью, видимо. анал-раны в чате на 100к игроков конечно приобретают некую пикантность :)
Думаю на такие нарушения можно пойти ради производительности. В данном случае Msg обрабатывается только для объектов класса Аватар, но вообще, видимо, интерфейс Abonent может быть реализован разными классами.
Есть и опенсорсные решения, самое популярное: www.gitlab.com/
Тенденция есть, но она не очень здоровая, научных проектов там единицы, а вот шарлотанов полно, включая и этот проект. И с каждым таким проектом довере к краудфандингу снижается.
Я думал они 1 в 1 передрали API кокоса. Значит я вам не помогу с этим, к сожалению.
Универсального рецепта нет, к сожалению. Для приложений вроде вашего, где вся сцена должна располагаться на одном экране (если я правильно понял), техники примерно могут быть следующими:
— при поддержке 4+ айфонов, можно принимать размер экрана 4ки за всю активную игровую сцену (с клетками), а на 5+ девайсах добавлять арт, компенсирующий разницу в высоте. В вашем случае можно было сделать разные элементы управления: вашу текущую версию оставить для 5+, а для 4+ сделать более компактное меню (ваше вполне можно уменьшить в пару раз без потери функциональности).
— при поддержке зоопарка андроидов, а так же 6+ айфонов, делать несколько наборов ассетов + скалирование. Для вашего случая за минимальный размер экрана можно было бы выбрать 4й айфон, условно говоря это был бы размер 1х. При загрузке игры расчитывать размер клетки (исходя из разрешения экрана и количества клеток по вертикали-горизонтали). Если размер больше 4го айфоновского, но меньше условного 1.5х, то брать ассеты размера 1.5х и скейлить до нужного размера. Если больше 1.5х, то скейлить из 2х и т.д. Все зависит от спектра поддерживаемых разрешений. По хорошему вы должны требовать от художника всего арта в нескольких размерах сразу, к примеру исходный, 2х и 4х для планшетов. В идеале вы должны следить, что бы ассеты были нарисованы под каждый размер (с уменьшением/увеличением детализации), а не просто отскейлеными в фотошопе, но это будет очень дорого, особенно учитывая анимации.
— весь код должен работать с design resolution, а не напрямую с физическим разрешением экрана. Как дела обстоят в вашем фреймворке я не знаю.
Да, скалирование не бесплатная операция, но я не знаком с sprite kit, поэтому не могу дать какие-то советы на этот счет.
5 от 4 и 4s отличается только размером экрана.
Посмотрите на бесплатный Explosion Generator 3
Нужно было сразу или искать моноширный шрифт или делать его самому как bitmap font (что надо было делать с самого начала, если вы конечно считаете draw calls).
Не обижайтесь, но сам подход «подгонка по пикселям GUI» не будет работать ни на одной платформе нормально. После выхода 6го айфона неумение работать с разными разрешениями вам аукнется. Я молчу про андроид.
Удивительно что на такой простой сцене у вас возникли какие-то проблемы с производительностью. Вы использовали стандартные техники SpriteFrameCache и SpriteBatchNode?