Мобильные платформы
GameDev.ru / Мобильные платформы / Форум / [android + libGDX] нагрузка ЦП

[android + libGDX] нагрузка ЦП

Поделиться
stu5002Постоялецwww25 июля 20121:19#0
буквально недавно начал пробовать себя в программировании игр вообще и на андроид в частности. Решил использовать libGDX.
Для начала решил сделать 2Дэ игру по сути как Марио (движения вправо, влево, прыжок и тд).
Анимацию героя делаю примерно так, как описано в этом посте: http://freehabr.ru/blog/android/746.html
Проблема в том, что при запуске игры и выводе графики процессор начинает грузиться от 90 до 100%. И это при том, что в моей игре ничего еще практически нет, кроме главного героя и движущейся текстурки на заднем плане в качестве фона. И заметно, что анимация героя идет не всегда равномерно, а иногда с небольшими подергиваниями.
Как от этого избавится?
Каркас игры примерно как тут (может в нем чего не так): http://narod.ru/disk/17550315001/FirstGame%202.zip.html

Кстати, вопрос до кучи: Как легче всего создать анимацию для персонажа? Я пробовал брать реальное видео и путем обрисовки каждого кадра получал нужные изображения, но это явно как-то накладно. Есть же более простой путь?

SemtikoПостоялецwww25 июля 20124:50#1
Я так понял, что ты имеешь ввиду нагрузку на ЦП настольного пк, не дроида? Если да, то так происходит потому что нужно инициализировать приложение, передавая бэкэнду конфигурацию, в которой явно необходимо включить вертикальную синхронизацию и желательно cpu-синхронизацию, в противном случае нагрузка будет максимальной. Есть вариант "ручного" ограничения fps, но это нужно не всегда (если очень хочется, могу рассказать). Тут про конфиг - http://libgdxrus.blogspot.com/2012/05/blog-post.html
А про анимацию тут (много последовательных регионов - очень даже нормально, не переживай) - http://libgdxrus.blogspot.com/2011/11/11.html
Можешь задавать любые вопросы касательно libgdx (и все кто читает), так как скилл набивать лишним не будет, да и надо людям помогать - мойник@ya.ru (надеюсь понятно =)) Отвечу при первой возможности. Лучше всего если вопросы будут про libgdx, а не про всё на свете, связанное с игростроем на libgdx )
stu5002Постоялецwww25 июля 201216:49#2
Не не не, я имел ввиду нагрузку на процессор именно смартфона. Вообще я проверил - вроде как процессор грузится практически во всех играх да и вообще, когда на большей части дисплея меняется изображение (например при перелистывании домашних экранов).
Но вот только в других играх не подтормаживает так, как в моем приложении.
Вот по первой статье - можно ли установить вертикальную синхронизацию и синхронизацию с ЦП в андроиде?(извиняюсь за вопрос, просто сейчас сам не могу это проверить) Ну или как вообще в нем увеличить производительность?
И спасибо за ссылки. Жаль, кстати, что не продолжаешь вести этот блог, а то очень мало материалов по libGDX на русском.
SemtikoПостоялецwww25 июля 201219:16#3
Нагрузка - это нормально, особенно когда экран обновляется с максимально возможной для него скоростью. Именно так происходит на всех мобильных устройствах, так как по ограничение FPS - забота разработчика. Вертикальная синхронизация на дроиде включена изначально и не выключается, именно по этому количество кадров не может превышать допустимое для экрана. В основном это 60 герц, на некоторых устройствах (в частности с 3D дисплеем) - 120. FPS-логер показывает обычно 58-63 для первого варианта экранов и 117-119 для второго. Это не падение производительности, а небольшая погрешность подсчета кадров. Это нормально. Если устройство не может обновлять экран с максимальной скоростью (слабый процессор, либо просто тяжелое приложение), то кадры, само собой - упадут. Нормальная (играбельная) частота - 30-40 герц, но иногда лучше оставить запас в десять кадров - получится более плавно и не так критично для батареи устройства. Быстрый разряд батареи - причина не только частого обновления экрана, но и тяжелых алгоритмов, когда начинающие разработчики делают тяжеленные циклы, а-то и несколько, которые на самом деле можно уменьшить либо вообще от них отказаться. Многие пользователи жалуются на игроделов в маркете именно потому, что их приложения быстро разряжают батарею. Это тоже стоит учитывать, так как плохие отзывы - не есть хорошо. Стоит так же учитывать потребление памяти и стараться выгружать ненужные ресурсы (в gdx это обычно функция dispose, например для текстур, звуков и спрайт-батча). Контролировать нагрузку процессора можно так же через Method Profiler в DDMS, который позволяет определить - какие именно функции требуют максимального процессорного времени. Зачастую это помогает отказаться от некоторых функций, заменив их более легковесными. Например - постоянный вызов "someVar = new Vector3(pos.x, pos.y, 0f);" в методе render отнимает больше вычислительных ресурсов, чем шаг мира Box2D с 20-30 динамическими объектами.
Так, меня уже понесло ) О нагрузке. На каком устройстве ты тестируешь своё приложение и как ты определяешь нагрузку на процессор? Плюс - ты тестируешь нагрузку приложением, которое ты скинул в стартовом посте? Если да - это плохая идея, так как вывод одного изображения ничего не покажет и даже анимации в несколько кадров. Что значит "притормаживает" - в чем это заключается? (отсюда вывод - тестируешь ты точно каким-то другим приложением, картинка выводится всегда одинаково, даже с один кадром в секунду =) ).

Для ручного ограничения FPS ты можешь создать метод, например sleep, как в основном классе приложения, так и в наследуемом "screen". Тут на пальцах не объяснить, по этому вот три класса:

+ Показать

По поводу статей - Марио (разработчик libgdx) делает бэкэнд для iOS, по этому я дождусь когда он его выпустит, всё проверю 300 раз и статьи будут другого масштаба. Я переписывался с ним по поводу совместного написания нового варианта книги про разработку для мобильных платформ (у него уже есть одна книга, но она уже устарела и она только для дроида), если он выкроит время, то книга будет сразу на двух языках и постараемся сделать её полезнее, чем большинство штампованных книг про разработку под мобильные платформы, имеющихся на полках в магазинах. Само собой блог так же будет пополнен, но это уже отдельная тема )

stu5002Постоялецwww26 июля 201216:36#4
Если заносит - не останавливайся) Тестировал да, другим приложением, это я основу скинул, думал может в ней проблема. Кстати, у меня, кажется, создавалось два объекта класса, дочернего от Screen и один рисовал поверх другого. Возможно отчасти из-за этого притормаживало (а может и не отчасти =) ). Я с явой раньше не сталкивался, знаю просто, что там есть сборщик мусора - для меня это как сигнал к тому, что можно понаписать говна и за памятью не следить, а оно там все как-нибудь образуется. Хотя память особо сильно не нагружалась (пока что). Еще учиться и учиться. О Fps-логгере естественно тоже не знал, как и о DDMS, спасибо за информацию.
Тестировал на HTC Incredible S, нагрузку смотрел в приложении Cool Tool, там же использование памяти.
И не совсем понятно со sleep(), можно же просто передать константу в Thread.sleep()? Я понимаю, что там вместо этого какой-то хитрый алгоритм, но мне не хватает ума понять как он работает, протестировать пока что, к сожалению, тоже не могу, возможно только сегодня ближе к ночи.
SemtikoПостоялецwww26 июля 201218:12#5
Нее, так не бывает ) Два класса никак не могут жить, именно как ApplicationListener, то есть рисовать друг на друга тоже не смогут. Сборщик есть, он грохнет переменные в том случае, если класс уже не используется, но ресурсы сам выгружать не будет за тебя, например картинки или звуки при смене уровня игры. Всё равно говн писать не надо )
DDMS - твой лучший друг ) Там много чего полезного и интересного. Про Cool Tool я никогда даже не слышал и если честно, уже настолько приработался со стандартными инструментами, что вряд ли буду переходить на какие-то другие. Чтобы я не делал, пока что не возникало неудобств или снижения моей производительности из-за "инструментов".
Thread.sleep() - будет усыплять поток в независимости от того, как быстро устройство рисует картинки и получится так, что на более быстром устройстве игра будет играбельна, а на чуть тормозном - еще более тормозно, чем само устройство. По этому рассчитывается время между последней и текущей отрисовкой и только тогда усыпляется на рассчитанное время. Не заморачивайся сильно, просто оно работает )
stu5002Постоялецwww29 июля 20121:10#6
Да, ты прав, одновременно только один screen. Про слип понял, чет я тупил до этого) Ладно, на 2 недели на море, потом снова постигать навыки работы с libGDX) Спасибо за ответы)

/ Форум / Мобильные платформы / Общее

Тема в архиве.

2001—2017 © GameDev.ru — Разработка игр