Есть ли более идеальный способ отправки команд рисования? - PullRequest
1 голос
/ 31 декабря 2011

Я все еще работаю над переносом приложения для Android на OpenGL, и у меня снова возникла проблема.

Я дошел до того, что все функции, единственная проблема в том, что анимация кажется немного странной.

Я отслеживаю частоту кадров и вижу, что поток рисования не замедляется, но время от времени основной цикл немного замедляется, и я подозреваю, что у меня возникла проблема, о которой я беспокоился.

Способ работы приложения заключается в том, что при создании новых объектов (например, врагов) создаются 2 объекта. Первый создается и отображается в главном потоке, а затем в своем конструкторе создает объект сетки, который затем добавляется в группу для непрерывного рисования средством визуализации.

Каждый раз, когда атрибут для объекта изменяется (например, его координаты), объект передает необходимую команду своему аналогу сетки (в этом примере, чтобы перевести сетку.)

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

Можете ли вы придумать, как сделать это более эффективным и поточно-ориентированным?

Другое возможное решение: игровая логика не ДОЛЖНА работать на полной скорости (в режиме реального времени). Я действительно настроил ее так, чтобы обновления не производились до 33 миллисекунд. Очевидно, у меня должно быть достаточно времени между рисованными кадрами, могу ли я настроить его так, чтобы рисование вызывалось только по команде в потоке (после обновления логики игры)?

1 Ответ

1 голос
/ 01 января 2012

Похоже, вам нужно что-то вроде ScheduledThreadPoolExecutor .

С помощью одного из них вы можете настроить рендеринг по расписанию, чтобы он выполнялся со скоростью 30 кадров в секунду, оставляя основной / управляющий поток, чтобы делать все, что нужно, с картой объектов между кадрами.

Я не думаю, что вам нужна какая-либо блокировка wait/notify, так как все, что вам действительно нужно, это заблокировать доступ к map, пока рендерер его прогуливает. Для этого вам просто нужно сделать карту synchronized. Поскольку это будет происходить только раз в 1/30-ую секунды, вы, конечно, не вносите значительных накладных расходов.

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

Добавлена ​​

Я вычитаю время, затраченное на цикл из 33 мс, и использую результат, чтобы указать продолжительность сна ().

Интересно, может ли это быть частью вашей проблемы? На Windows-машине вы часто получаете разрешение 15 мс на currentTimeMillis, так что ваши сны могут в итоге почти не спать. Возможно, стоит поэкспериментировать с ScheduledThreadPoolExecutor, просто чтобы посмотреть, улучшит ли он ваше время. ... упс ... это Android не так ли. Тем не менее ... возможно, стоит попробовать.

...