Как я понял в NeoAxis делается интерполяция все-таки — просчитываются два положения между стандартными тиками и вычисляется позиция в промежутке.
>1. Увеличить TICKS_PER_SECOND;
В шутерах будет напряжно.
Поэтому частота обработки увеличивается только для объекта, для которого CCD включен (для пули). Получается как раз то, о чем вы написали — вычисляются промежуточные позиции. Иначе пуля за один тик может преодолеть большое расстояние и пролететь сквозь тонкую стенку, а не столкнуться с ней.
>2. Быстрый объект растянуть по всему пути его следования.
Сложно реализовать при криволинейных траекториях (особенно при действии силовых полей).
Да. Но при прямолинейном движении иногда можно получить выигрыш.
Прим. перев.: в движке NeoAxis для физического объекта можно выставлять флаг Continuous Collision Detection; подозреваю, что по нему как раз и выполняется обработка, подобная описанной выше реализации игрового цикла.
CCD используется для детектирования коллизий быстрых объектов. Насколько я помню, есть 2 основных подхода:
1. Увеличить TICKS_PER_SECOND;
2. Быстрый объект растянуть по всему пути его следования.
javax.microedition.lcdui.game иногда может быть полезным, но часто в играх используется настолько извращенная специфическая оптимизация, что лучше изобрести велосипед.
groupIndex — индекс в группе (предположительно группа — один объект Body)
Насколько я помню, этот параметр нужен для фильтрации столкновений. Какие-то объекты могут сталкиваться, какие-то пролетают друг сквозь друга.
По видео у меня сложилось ощущение, что мяч все равно ударяется об исчезнувшие кирпичи. Попробуйте использовать этот параметр.
linearDamping, angularDamping, bullet — не понятно с первого взгляда
bullet нужен для быстрых объектов, подверженных туннельному эффекту. Для таких объектов используется более «тяжелый» алгоритм расчета столкновений, поэтому его надо использовать для небольшого количества объектов. В вашем случае — для мяча.
setFullScreenMode(true); //Полно экранный режим
w = getWidth();
h = getHeight();
По моему опыту, лучше разворачиваться на весь экран в первом paint. И еще, у вас разворот на весь экран вот тут дублируется:
public Habra(){
habra_midlet = this;
splash_screen = new HabraSplash();
splash_screen.setFullScreenMode(true);// <=здесь
}
Есть у меня сомнения, что канва нормально развернется на весь экран и получит правильные w и h до того, как ляжет на экран. А 100% узнать, что она готова для разворота на весь экран можно только при первом вызове её paint… ну может еще по нажатиям клавиш, etc.
Так что:
private boolean isInFullScreen;
protected void paint(Graphics g) {
if (!isInFullScreen) {
isInFullScreen = true;
setFullScreenMode(true);
w = getWidth();
h = getHeight();
}
//отрисовка
}
Да, и в конструктор мидлета тоже лучше ничего «тяжелого» не класть, лучше в startApp. На некоторых трубках это тоже может негативно отразиться.
Изучение J2ME даст Вам знание ООП, научит хорошо контролировать память и много чего другого.
Согласен. Писал довольно большую игрушку на j2me; как только не приходилось извращаться…
Поэтому частота обработки увеличивается только для объекта, для которого CCD включен (для пули). Получается как раз то, о чем вы написали — вычисляются промежуточные позиции. Иначе пуля за один тик может преодолеть большое расстояние и пролететь сквозь тонкую стенку, а не столкнуться с ней.
Да. Но при прямолинейном движении иногда можно получить выигрыш.
CCD используется для детектирования коллизий быстрых объектов. Насколько я помню, есть 2 основных подхода:
1. Увеличить TICKS_PER_SECOND;
2. Быстрый объект растянуть по всему пути его следования.
извращеннаяспецифическая оптимизация, что лучше изобрести велосипед.По видео у меня сложилось ощущение, что мяч все равно ударяется об исчезнувшие кирпичи. Попробуйте использовать этот параметр.
bullet нужен для быстрых объектов, подверженных туннельному эффекту. Для таких объектов используется более «тяжелый» алгоритм расчета столкновений, поэтому его надо использовать для небольшого количества объектов. В вашем случае — для мяча.
Есть у меня сомнения, что канва нормально развернется на весь экран и получит правильные w и h до того, как ляжет на экран. А 100% узнать, что она готова для разворота на весь экран можно только при первом вызове её paint… ну может еще по нажатиям клавиш, etc.
Так что:
Да, и в конструктор мидлета тоже лучше ничего «тяжелого» не класть, лучше в startApp. На некоторых трубках это тоже может негативно отразиться.
Согласен. Писал довольно большую игрушку на j2me; как только не приходилось извращаться…