OpenGL ES 2.0. Отложенное освещение

Мне кажется смешиваются.
Вот так эта сцена выглядит, отрендериная blender'ом

Все источники

Только последний

Получается немного светлее, у него объемы больше при расчетах

Sony не умеет готовить Android

Согласен, что-то подобное там и произошло. Это же обычная проверка на включен/выключен, выдавать наружу фатальное исключение при этом — странная практика.

Sony не умеет готовить Android

Как инженеры сони могли пропустить такой баг — это вопрос интересный.

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

Sony не умеет готовить Android

Здесь все не так просто.
READ_PRIVILEGED_PHONE_STATE это не обычный пермишен, а привилегированный. Он создан с пометкой "signature" в уровне безопасности. Дословно это означает следующее:

A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.

Т.е. приложение Contacts от сони должно быть подписанно тем же ключок что и прошивка. Тогда необходимые разрешения автоматически гарантируются и никаких запросов в рантайме не будет. В противном случае, независимо от манифеста, при запросе выкинется SecurityException.
Если проблема действительно в манифесте, хотя это может быть и не так, то никакие исправленные версии не помогут.

Кстати, я посмотрел исходный код службы. В большенстве запросов, там где необходимы привилегированные пермишены, SecurityException перехватывается и логируется, а при проверке доступности видео звонков — почему-то нет.

Sony не умеет готовить Android

Sony не умеет готовить Android

отсутствие правильного процесса управления разработкой ПО

Sony полностью развалены процессы разработки и поддержки ПО

эти ребята не знают как писать софт и как его поддерживать

Не покупайте телефоны Sony

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

Перегрузка всех 49-и операторов в C++

Я призываю вас внимательней отнестить к тому коду, который вы пишете

То есть более правильным будет является такой код:

Vector3 operator = (Vector3 v1)
{
    ...
    return *this;
}

Нет. Более правильным будет такой код

Vector3 & Vector3::operator = (const Vector3 & v1)
{
    ...
    return *this;
}

Пример перегрузки для префиксных форм инкремента и декремента (++var, --var)

Vector3 Vector3::operator++();

Нет. Должно быть так

Vector3 & Vector3::operator++();

// или так
Vector3 & operator++(Vector3 & v);

Пример перегрузки операций составного присваивания +=, -=, *=, /=, %=

Vector3 operator += (Vector3 &v1, const Vector3 &v2)
{
    return Vector3(v1.x = v1.x + v2.x, v1.y = v1.y + v2.y, v1.z = v1.z + v2.z);
}

Нет. Должно быть так

Vector3 & Vector3::operator +=(const Vector3 & v);

// или так
Vector3 & operator +=(Vector3 & v1, const Vector3 & v2);

Хороший пример перегрузки операторов сравнения ==, !=, >, <, >=, <=

const bool operator < (const Vector3 &v1, const Vector3 &v2);

Почему тип возвращаемого результата const bool, a не bool?

Пример перегрузки логических операторов !, &&, ||

Здесь следует отметить, что операторы && и || оболадают сементикой logical short-circuiting. И при перегрузке это свойство теряется.

Пример перегрузки побитовых операторов ~, &, |, ^, <<, >>

const Vector3 operator ~ (Vector3 &v1);

Почему тип возвращаемого результата const Vector3, а не Vector3?

Перегрузка операции ввода из потока (очень удобный вариант)

istream& operator >> (istream &s, Vector3 &v)
{
    std::cout << "Введите Vector3.\nX:";
    std::cin >> v.x;
    std::cout << "\nY:";
    std::cin >> v.y;
    std::cout << "\nZ:";
    std::cin >> v.z;
    std::cout << endl;
    return s;
}

Выглядит стронно, относительно объекта s.

Пример перегрузки операторов работы с указателями и членами класса [], (), , &, ->, ->

int Vector3::operator [] (int n)
{
    try
    {
        ...
        throw "Ошибка: Выход за пределы размерности вектора";
    }
    catch (char *str)
    {
        ..
    }
    return 0;
}

В данном случае, исключение не перехватится. Должно быть

try
{
    ...
    throw "Ошибка: Выход за пределы размерности вектора";
}
catch (const char *str)
{
    ..
}

Также следует отметить, что оператор [], (), ->, могут быть только членами класса

Ну и в целом, если вы решили воспользоваться механизмом перегрузки операторов, то семантика поведания должна быть ожидаема. В противном случае, лучше использовать обычные функции/методы: add, sub, assign, ...

По поводу записи типа

Vector3(this->x++, this->y++, this->z++)

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

Перегрузка всех 49-и операторов в C++

Нет. Вы пытаетесь присвоить значение константному объекту.

Перегрузка всех 49-и операторов в C++

Вот это тоже не очень удачно

Vector3 operator += (const Vector3 &v1, const Vector3 &v2)
{
    return Vector3(v1.x = v1.x + v2.x, v1.y = v1.y + v2.y, v1.z = v1.z + v2.z);
}

Почему ООП не инкапсуляция, наследование и полиморфизм, или как я научился не волноваться и полюбил разметку

Мне кажется использовать лексику типа

… дохера… на хер… гребанная...

в публикации неуместно. Давайте будем хоть немного уважать друг друга.

OpenGL ES 2.0. Один миллион частиц

Выложил клиент под Android.
Cобираю на Ubuntu 16.04, на Windows не пробовал. Если попробуете и что-то не заработает, напишите пожалуйта.

OpenGL ES 2.0. Один миллион частиц

К сожелению, клиент под Android еще в процессе. В скором времени постараюсь выложить. Все примеры можно будет собирать в Android Studio и запускать на устройстве или на симуляторе.

Десктопных клиентов пока не планирую. Можно использовать Qt, вроде как она по умолчанию работает в режиме совместимости с OpenGL ES (что бы шейдеры не переписовать). Или воспользоваться каким-либо эмулятором, например, этим

OpenGL ES 2.0. Один миллион частиц

Тестовый девайс у меня всего один: xperia z3
Описанный пример с 2^20 частиц работает на ~30fps. Без красивостей в постобработки ~42fps.

На hdr-текстурах результат примерно на 5 fps хуже.
Утверждать ничего не буду, попробывал всего один раз и возможно где-то просто ошибся.

OpenGL ES 2.0. Один миллион частиц

OpenGL обрабатывает текстуры формата GL_RGBA8 с помощью того, что называется Normalized integer. Т.е. на самом деле у нас есть только целые числа, которые OpenGL автоматически преобразует в числа с плавающей точкой и обратно. Такие числа характеризуются наличием знака и количеством бит (bitdepth). В нашем случае, это 8-ми битные, беззнаковые целые.
Максимальное значение:

MAX = 2^8 - 1

OpenGL преобразования:

float = int / MAX
int = round(float * MAX).

Суть распаковки/запаковки

Запаковка:

1. Мы умножаем наше число F от 0.0 до 1.0 на 255.0. Из полученного результата нам важен остаток B. Это то, что не влезло в 8 бит. Т.е. в один 8-ми битный компонент мы можем записать только F — B / 255.0.
2. На втором шаге мы просто сохраняем (B, F — B / 255.0)

Распаковка:

1. Складываем две компоненты, не забыв разделить первую на 255.0.
   

   (B / 255.0) + (F - B / 255.0) -> F

Создание Android-приложения. Персонализация

На мой взгляд, проблема вреда обоев для батареи немного «раздута». Во-первых, у живых обоев (у движка) есть состояние hidden, т.е. обои активны, но их невидно. В этом состояние нужно прекращать всякую активность: остановить вычисления, отвязаться от сенсоров и т.д… Исходя из того, как мы пользуемся телефонами и планшетами, период видимости обоев достаточно небольшой. Во-вторых, конечно необходимо разумное ограничение fps. Если следить, как минимум, за этими вещами, проблем быть не должно.
К сожелению, про значительные изменения сказать ничего не могу. Единственным нововведением, которым я воспользовался, был интент смены обоев ACTION_CHANGE_LIVE_WALLPAPER (он появился только в 16 api).

Кстати про батарею, мне в одном из отзывов предложили сделать модификацию, чтобы уровень жидкости коррелировал с зарядом батареи, а на зарядке там пузырики чтобы были. Не знаю как делать, но мне показалось интересным. Приложение которое «жрёт» батарию и показывает пользователю как быстро оно это делает.