На счет загрузки арта по необходимости - это не просто "идея напоследок", это должна быть первоочередная идея, без которой ни один даже средний проект просто не заработает. Грузить все ресурсы на старте - это для поделок на коленке.
А вот устройств с поддержкой OpenGL 3.x не 42.3%, а 42.3 + 12.8 = 55.1% :) Остальная часть с поддержкой OpenGL 2.0 - это обычно старье с Adreno 200/205, SGX500+ или 1-4 ядерными Mali 400MP. Лично я под вопрос ставлю их практическую ценность и восприятие в качестве целевой аудитории.
Движок поддерживает все что поддерживает его окружение и операционка. Движку неважен формат текстуры если он(движок), конеч, не порывается читать ее в обход окружения.
А "самым безопасным" в этом отношении, на самом деле, может быть только TGA. :) Т.к. этот формат на 100% точно передаст качество текстуры и на 100% точно прочитается даже своими руками. ETC - такой же аппаратно-поддерживаемый формат сжатия текстур и он тоже может не поддерживаться какой-нибудь экзотикой из Китая. Шанс есть всегда.
В манифесте можно указать и требуемую версию OpenGL, и поддерживаемые текстуры. Таким образом можно сделать и несколько .APK файлов для разных GPU, которые будут полностью безопасными.
САОД (Структуры и Алгоритмы Обработки Данных) тебе в помощь.
После изучения теории советую изучить практическую часть через постижение STL ( en.cppreference.com/w/cpp/container ) и книг Николая Джосаттиса (STL - Standard library) или Скота Мейерса (Effective STL).
В целом это выглядит очень странно. Контекст случайно не в андроидах <3.0 теряется? В версиях >3.0 я такое наблюдал только в очень старых очень экзотичных китайфонах, которые мы благополучно отфильтровали в маркете. Поведение проекта на такой экзотике в целом напоминало чертовы пляски - все было крайне непредсказуемо и выбивалось из понимания процесса правильной работы самой ОС.
Наверное ты уже проверил правильность работы Activity и GlSurfaceView вместе с объектом рендерера и с ними все нормально?
В любом случае, когда приложение уходит в паузу, поверхность рендеринга у GlSurfaceView уничтожается, а контекст, даже если он не уничтожается, он просто отключается от текущего потока. А после выхода из паузы происходит новая связка контекста с поверхностью рендеринга. Т.е. контекст, по своей сути, должен оказаться тем же самым и его не надо перенастраивать.
В общем, или это экзотика, или что то не так с окружающим SDL кодом. Вариантов точного решения у меня нету, прости что обнадежил тебя.
Я с SDL не работаю, поэтому по его поводу ничего сказать не могу. ПО части андроида и OpenGL могу проконсультировать при наличии некоторых уточнений. Первое - GlSurfaceView используем? Если да, то дергаем ли метод `setPreserveEGLContextOnPause(true)`? Второе - правильные ли `android:configChanges` у нас стоят в манифесте? Это все препятствует ненужной потере контекста при сворачивании. Третье - делаем ли мы `surface_view.getHolder().setFormat()` с нужным форматом, в котором будет рисоваться кадр через контекст (да, в доке функция deprecated, только без нее все так же ничего не работает как положено)? Если форматы круто не совпадают, черный экран неминуем.
Плюсы - прекрасный инструмент, предоставляющий 1000 + 1 способ выстрелить себе в ногу. Использование в твоем вопросе constexpr или безымянных перечислений - это low grade decision основанный на недостаточном знании стандарта. Статическая константа простого типа может быть определена по месту объявления еще с 2003 стандарта. Тащить ее из заголовка в исходник - еще одна не совсем хорошая штука. Ты имеешь полное право просто взять и определить bytes_for_content прямо по месту его объявления в структуре Packet. А еще лучше в таком случае использовать тип size_t, но никак не int.
Стектрейс показать забыл. На кофейной гуще гадать неинтересно. А так, кодировать не в 1251 надо, а в utf-8 и везде поддерживать только одну кодировку, в том числе и в исходниках.
Плюсы - это самый лучший язык для того чтобы попасть себе в голову, стреляя себе в ногу, не делая для этого ничего. Поэтому у тебя все нормально компилится, однако в ногу оно стреляет и в голову ты себе исправно попадаешь.
Ты в принципе неправильно пользуешься как приведением типов, так и вообще переменными. Тебе надо читать документацию по плюсам, а не общаться на тостере.
Я ответ писать не буду, только коммент. У тебя там все не так делается, даже там, где ты написал что все ок, всё все равно не так. Делать из типа **void тип *QLayout - это очень не так и очень нехорошо.
Тебе срочно надо почитать про принципы управления памятью и про работу с объектами в С++.
Плюсую за наблюдательность относительно скобок. Превелика вероятность что именно в них, в квадратных самых, проблема и кроется. Но вот с экранированием у него все норм. :)
Это не ответ, это напутствие.
Всю надо знать математику. От школьной геометрии до углубленного анализа, рядов, теории поля и интегрального/дифференциального исчислений. Плюсом еще и дискретную надо знать, тоже всю. Математика она не только в 3D/2D применяется, вся логика строится математически, ИИ - это математика, даже внутренний менеджмент решается чисто математически.
Всю ее надо знать. Или часть, если хочешь быть узким специалистом.
В Google Code Style есть одно правило: "Never use postfix increment/decrement in loops!". Суть сама за себя говорит. Но у тебя проблема явно не в этом.
А вот устройств с поддержкой OpenGL 3.x не 42.3%, а 42.3 + 12.8 = 55.1% :) Остальная часть с поддержкой OpenGL 2.0 - это обычно старье с Adreno 200/205, SGX500+ или 1-4 ядерными Mali 400MP. Лично я под вопрос ставлю их практическую ценность и восприятие в качестве целевой аудитории.
Движок поддерживает все что поддерживает его окружение и операционка. Движку неважен формат текстуры если он(движок), конеч, не порывается читать ее в обход окружения.
А "самым безопасным" в этом отношении, на самом деле, может быть только TGA. :) Т.к. этот формат на 100% точно передаст качество текстуры и на 100% точно прочитается даже своими руками. ETC - такой же аппаратно-поддерживаемый формат сжатия текстур и он тоже может не поддерживаться какой-нибудь экзотикой из Китая. Шанс есть всегда.
В манифесте можно указать и требуемую версию OpenGL, и поддерживаемые текстуры. Таким образом можно сделать и несколько .APK файлов для разных GPU, которые будут полностью безопасными.