Android: Вращаем на все четыре стороны AndEngine

[@cypok]

Прочитайте цикл статей Tabs vs Spaces, ибо вы не по делу юзаете табы:

[@lordtao]

Код перенесен напрямую из Эклипса. В нем я использую табы. Мне удобнее использовать табы. Я буду использовать табы. Я никого не заставляю использовать табы. Это мое имхо мнение. А в статье я исправлю. Здесь вы правы.

[@Mad_Fish]

Так и используйте табы, но для логических отступов. Для декоративных, которые зависят от числа символов (как здесь) — пробелы.

[@0mm]

Когда-то читал заметку на предмет использования табов и пробелов. После прочтения перешел только на пробелы (и/или табы, которые автоматически вставляются как 4 пробела). В разных IDE размер табуляции может существенно отличаться, что превращает код в неразборчивую кашу. С пробелами таких проблем никто не наблюдается.

P.S: в настройках Eclipse можно задать постановку таба как n пробелов.

[@Mad_Fish]

Если правильно использовать табы, проблем тоже не будет.
Например,
<-->if(a == b &&
<-->___b == c &&
<-->___c == d)
<-->{

, где "<-->" — таб, "_" — пробел.

В этом случае при изменении размера таба «вёрстка» не поедет.

[@0mm]

В вашем случае, 4 пробела придется ставить руками, что, согласитесь, не очень удобно. Мне кажется, несколько проще, если все свести к использованию пробелов.

[@vovkab]

Отличный пример минуса от использования табов :)

[@0mm]

Жаль, что нельзя отредактировать комментарий. Никто = никогда. Извиняюсь за опечатку

[@SabMakc]

Скажите, а с акселерометром приходилось работать из AndEngine?
Встречались ли с проблемой инверсии знака координат X, Y, если в момент инициализации телефон был наклонен «от себя»?

[@lordtao]

Работать не приходилось, но возможно вам поможет следующий подход.
Сначала я поставил непрерывный вывод логов по данным которые выдают сенсоры, а потом эмпирическим путем подбирал тот диапазон показаний который мне необходим. Если в вашем случае проверять наклон телефона по сенсорам как в указано в статье, то можно будет нормально просчитать в любой момент наклон и пересчитать инверсию. Кстати, прошу учесть, что числа в статье рассчитан эмпирически и вы можете его подстраивать под себя:

if (in(z, 60, 100)) return 1;
if (in(z, -20, 20) && y > 50) return 2;
if (in(z, -20, 20) && y < -50) return 0;
if (in(z, -100, -60)) return 3;

[@SabMakc]

«Костыль», выправляющий показания я уже сделал.
Хотелось бы полностью от эффекта избавиться, но видать, не судьба.

[@r_ii]

Ваш метод getCurrentOrientation будет давать неточные данные если устройство будет расположено не вертикально (т.е. например если стоять и держать его в руках почти горизонтально) — такая-уж особенность акселерометров.
Для определения точного угла поворота устройства можно воспользоваться тем свойством, что сумма углов по осям y и z должна быть равна 90:

// fix pitch and roll
if (Math.abs(pitch) + Math.abs(roll) != 0)
{
	float x = 90 / (Math.abs(pitch) + Math.abs(roll));
	pitch *= x;
	roll *= x;
}

[@r_ii]

вот более полный код

public void onOrientationChanged(float azimuth, float pitch, float roll)
{
	// fix pitch and roll
	if (Math.abs(pitch) + Math.abs(roll) != 0)
	{
		float x = 90 / (Math.abs(pitch) + Math.abs(roll));
		pitch *= x;
		roll *= x;
	}
		
	if (pitch < 0) angle = roll;
	else
	{
		if (roll < 0) angle = -90 - (roll + 90);
		else angle = 90 + (90 - roll);
	}
		
	angle = angle - 90;
	if (angle < -180) angle = 360 + angle;
}

[@lordtao]

Данные по поворотам определялись по удобству поворота для пользователя. Строго вертикальное положение в моем случае было не приемлемо. Поэтому метод и содержат такие данные для вычисления. Для моей программы они оказались наиболее подходящими. На всякий случай я это отметил в коде в виде комментария.

[@r_ii]

Ну если Вас все устраивает — тогда ok.
Я всего лишь предложил метод точного определения угла наклона устройства то отношению к горизонту из любого положения (ну кроме строго горизонтального — тогда возможны очень резкие скачки).