Подскажи кто как думает надо решить такую задачу для относительно медленных телефонов. Есть игровое поле которое состоит из элементов квадратной формы, по нему летают шарики, вот как оптимальнее всего это перерисовывать, среди варинатов
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 ?

проверку своей программы я проводил на nokia 5500d - s60v3, nokia 6680 - s60v2, Nokia 9300i - s90, Siemens CX65, Motorola e398, Nokia e50, Nokia 2630 и плохие результаты, вернее скажем всего 20 кадров в секунду минимум были на Siemens CX65, Motorola e398 и самая катастрофа была на Nokia 2630
а почему Вы спросили?? что с этой платформой что то не так?

Одно время были проблемы с Nokia S60 2 Ed.
Жутко тормозил flushGraphics();

Оказалось тормозила связка drawRegion() + flushGraphics();

Вопрос решил использованием Nokia API DirectGraphics

Вообщем совет на эту платформу такой: использовать MIDP 1.0 + Nokia API

на какую имено платформу?? подтормаживает то и на сименсах и на мотороле
а вот интересно нокия 2630 потдерживает nokia API или только MIDP 2.0 и что еще быстрее на ней работать будет...

Для Нокия S60 2 Ed




Если на всех подтормаживает, то что-то с кодом не то. 
Выложи код - посмотрю.




2630 - новый телефон, даже если и есть нокия АПИ, то лучше МИДП 2.0 использовать.

да с кодом то все в порядке  сам код(то есть просчет и все действия, и даже прорисовка в двойной буфер) быстро выполняется, 6-7 мс на медленных телефонах, все время занимает функция flushGraphics();. а пробовать вызыпать flushGraphics(int,int,int,int) лишь еще замедляется дело...
просто думал может как то можно обойтись без, скажем если через MIDP 1.0 делать, потому что дело полностью в ней :(

Из ваших слов можно сделать вывод, что с кодом у вас не все в порядке.
Если используется flushGraphics() значит у вас есть класс extends GameGraphics, а этот GameCanvas сам по себе имеет двойную буферизацию, а вы говорите, что дополнительно еще прорисовываете в двойной буфет. Или я не прав?

Свой пример я привел: по все показателям замера времени тормозил flushGraphics() на Nokia S60. Когда же убрал drawRegion() и заменил на аналог в Nokia API: после этого flushGraphics() перестал тормозить. Игра стала летать.

Как обойтись без flushGraphics()? 

shomer кажется привел пример, как это сделать использую Canvas:

нет еще одного двойного буфера нету, я подразумеваю двойную буферизацию которая реализована в GameCanvas.
а если не секрет то что делает функция drawRegion()?
я знаю как реализовавать самопальную двойную буферизацию, просто я интересовался в первом посте, будет ли это быстрее работать? там же я и предложил 5 вариантов как можно отрисовывать сцену 
просто обидно, игра потенциально может работать очень быстро, а из за одного вызова функции flushGraphics тормозит...

Даю 100% гарантии, что причина тормознутости не в flushGraphics(). Даю 100 потому, что сам делал игры "потяжелее" чем шарики с использование flushGraphics() и знаю, что сам по себе этот метод не тормозит.
Портации делались на все указанные телефоны (ну может не совсем эти, но по списку совместимости точно на все). Глюк с тормозами был только на s60.
А если где-то тормозило, то из-за неправильного кода, неоптимальности и т.д... но никак не из-за использования flushGraphics().

Причину нужно искать не во flushGraphics().

Причин может быть много, например, перед тем как нарисовать шарик, ты создаешь Image этого шарика, а потом отрисовываешь и так при каждой отрисовке.   

Без кода можно только гадать..

Так что код в студию или стоит закрывать тему.

ну не надо думать что я программирование занимаюсь  первую неделю или первый месяц, как никак уже почти десять лет  да и алгоритм я специально оптимизировал как мог, там фактически одна математика, и прорисовка drawImage...
а на счет ста процентов, ну не знаю, все таки время то не обмануть, если я провожу замер и вижу, что вся игра выполняется за 7 мс а flushGraphics за 33 то наверное это о чем то говорит.
Конечно может быть летающие шарики можно сделать значительно оптимальнее, неже ли это сделал я, с точки зрения математики, и это я уже начинаю понимаю  и конечно проведу оптимизацию, но это уменьшит цифру 7 мс но не 33 мс 

  

voltaren, я исхожу из того, что Нокия, Моторола, Сименс не могли на стольких телефонах сразу криво реализовать метод flushGraphics(). 
Понимаю, если бы это были какие-то три "корейца"... плюс у меня самого нормально идет приложение.

Поэтому, ты как человек с большим опытом работы в программировании должен понимать, что где-то не с той стороны подходишь к решению своей проблемы. Или ты так не думаешь?

Раз уж ты не хочешь код показывать, то сам подумай: flushGraphics() работает нормально, проблема в другом месте. 

Может у тебя память под завязку занята, поэтому когда flushGraphics() вызывается, то идет вызов сборщика мусора, а он уже тормозит.

Так где же код