Подскажи кто как думает надо решить такую задачу для относительно медленных телефонов. Есть игровое поле которое состоит из элементов квадратной формы, по нему летают шарики, вот как оптимальнее всего это перерисовывать, среди варинатов
1)gameCanvas + перерисовывание только измениний, то есть зарисовывание шарики, отрисовка его в новой позиции, ну и измениния в поле если есть
2) свой канвас с двойной буферизацией, плюс измениния поля, потом выкладывания этого на экран а на это уже на прямую на экран нарисовать шарики, или будет эффект мерцания?
3) теоретически тоже что и пункт два только тройная буферизация, то есть поле храниться не изменным, в своей картинке, и изменяется в ней же, потом это рисуется в двойной буфер, по верх этого шарики, и потом flushGraphics, но ДУМАЮ Будет оч медленно.
4) TiledLayer и просто рисование шариков как картинок
5) TiledLayer и шарики в виде спрайтов

какой будет оптимальнее? или если можно предложите что нибудь свое 
а еще расскажите как оптимальнее всего обновлять экран если перерисовываются его части, но flushGraphics(int,int,int,int) я пробывал прироста не дал...на оборот только еще тормознее стало...телефон на котором тестилось Siemens CX75 среднее время которое уходило на отрисовку экрана было 45 мс...что конечно многовато..Заранее благодарен!

На мой взгляд, лучше всего первый вариант, тем более gameCanvas включает в себя двойную буфферизацию

2.Напрямую плохо. скорее всего будет эффект мерцания, ну если это эффектом назвать.
3. flushgraphics - плохо
4,5 - не юзал - ответить не могу

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

Теперь по вариантам, которые ты предложил.

Общее для всех вариантов: в игре нужно ВСЕГДА перерисовывать ВЕСЬ экран, делать это нужно для того чтобы в игре у тебя не было "рывков", например  1-я,2-я,3-я перерисовки экрана рисуют весь экран, потом одна перерисовка, только маленькую часть, так как быстро перерисовался  экран, то может получится указанный выше эффект.

1) GameCanvas - можно использовать, но отрисовка всего экрана.
2) Canvas + двойная буферизация: можно использовать, но опять же: отрисовка всего экрана.
Работа с двойной буферизацией:


3) 3-я буферизация - нет не нужно, хватит 2-йного буфера.

4,5) - Нет, не нужно такого использовать.

Я точно не знаю, что у тебя в проекте используется, но предполагаю, что шарики это Sprite ? 
Лучше обойтись без Sprite....

я не много не понял что подразумевается под перерисовкой всего экрана...
у меня вообще в игровом цикле такая отрисовка происходит...используется GameCanvas и никаких TiledLayer'ов и Sprite'ов:
сначала стираем шарик то есть один fillRect потом перемещаем и drawImage вот впринцыпе и вся отрисовка. 
  Над оптимальностью программы я еще работаю, но вообщем то написана она оптимально 
и просто смотря что считать тормозить...для меня полная отрисовка 6 шариков на поле со среднем временем 43 мс это тормоза...мне хотелось бы 30 фпс 
а вообще какой фпс нормальным считается? я читал где то что имено 30

Нормальный фпс, в смысле с которым можно уже играть это 12 и выше

а не маловат ли фпс 12 кадров для игры где шарики летают...?
а больше ни у кого предложений не будет?...просто сами расчеты 7 мс а прорисовка всего двух шариков 33 мс...это же просто не реально :((

и все таки мне одно не понятно...время обновления самой игры 7-10 мс а вот время одной функции flushGraphics которая правда весь экран обновляет целиком занимает 33 мс :( и как быть в такой ситуации? как бороться с такими тормозами?

12 fps с шариками, на моем не шустром телефоне - это тоска  
Присоединяюсь.. ( может репайнтить быстрее будет?)


Это сообщение отредактировал(а) shomer - 20.11.2007, 23:59

Присоединённый файл ( Кол-во скачиваний: 6 )
 DemoBall.rar 15,71 Kb

Проверил - paint в Canvase отрисовывает быстрее. ( чуть быстрее..)

Присоединённый файл ( Кол-во скачиваний: 6 )
 DemoBall_2.rar 15,71 Kb

>> 12 fps с шариками, на моем не шустром телефоне - это тоска 
что ты имел ввиду?

В динамичных играх скорость перемещения и плавность перемещения объекта важна беспорно.
Отчего она зависит?
1. При малых значениях приращения координат ( качественная реализация - плавное, не прерывистое движение) одназначно от скорости обсчета и отрисовки объекта.
Сталкиваемся с проблемой - физические ограничения скорости прорисовки аппаратной составляющей, и возможная неоптимальность программной реализации JVM. Это не зависящие от нас причины.
2. Скорость перемещения увеличиваем за счет увеличения приращения координат - получаем не движение а скачки игрового объекта.
Куда не кинь - везде клин. Но поскольку визуальное восприятие это чуть ли не самое главное в игровом процессе ( созревший клиент скорей телефон поменяет чем забудет то что ему понравилось), требуется по возможности улучшать графическую составляющую проекта.
От нас завит не много:
Оптимальность алгорима игрового процесса, выбор и использование максимально быстрых вариантов работы с классами, методами, членами классов ..
Кстати drawImage медленней drawRGB.
paint в Canvase быстрее чем flushgraphics в GameCanvase.
Clipping при отрисовке заметно на скорость не влияет..
и кое что еще..(надо пробовать)
-------------------------------------------
Извиняюсь - если загрузил  
-------------------------------------------
Отвлекся   . 12 fps с мечущимися по экрану шариками - смотреть противно. 70 fps на эмуляторе - красота  

Это сообщение отредактировал(а) shomer - 21.11.2007, 11:20

а какой у тебя телефон?
кстати я не понял но почему то твои программы DemoBall'ы работаю даже в эмуляторе не быстро, 16 мс на все дела...хотя может быть конечно это меня проглючило с утра, надо вечером будет еще посмотреть

Toshiba TS2050, CLDC-1.1 MIDP-2.0,  176x220 AlphaLevels=2, 350kb-jar,  JAVA RAM-1Mb
---------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------
В данном варианте на WTK ~ 0 ms, Sjboy эмулятор- 47 ms, TS2050 - 82 ms. Убираю 

Получаю WTK ~ 0 ms, Sjboy - 94 ms, TS2050 - 220 ms.
Вот такие кругом тормоза   
------------------------------------------------------------------------
как только Thread.sleep > 0 вылазят эти 16 ms

        


Это сообщение отредактировал(а) shomer - 21.11.2007, 23:56

на сколько я понял в реальност победить тормоза с flushGraphics нельзя, можно лишь сделать все что касается игрого цикла оптимально и радоваться  или не писать на j2me если есть возможность скажим для ташибы проще написать на C++ 

voltaren:

На каком телефоне ты проводил тестирование? 
Случайно не нокия s60 ?