vipermagi , "В-третьих" можно исключать, более подробной информации уже не будет.
Если изложенное непонятно, я могу сделать отсылки к стандарту где это все описано "во-сто-раз-еще-более-понятно"{sarcasm}. :)
@dero
Вань, такие лабораторные даны не для того чтоб самому в них разбираться, а для общения с преподавателем. Только он тебе скажет, что именно ему хотелось сказать вот этим текстом. Любой третьей стороне этот текст покажется простым неупорядоченным подмножеством слов из множества всех слов одного из разговорных диалектов русского языка.
Там действительно проблема с приведением типов.
Для приведенной сигнатуры std::function, код присвоения должен быть таким: `_glClearColor = *(PGLCLEARCOLORPROC)SDL_GL_GetProcAddress( "glClearColor" );`.
Разыменование обязательно, или std::function надо инстанцировать от указателя на функцию.
Вот пример: cpp.sh/2k4g
На счет загрузки арта по необходимости - это не просто "идея напоследок", это должна быть первоочередная идея, без которой ни один даже средний проект просто не заработает. Грузить все ресурсы на старте - это для поделок на коленке.
А вот устройств с поддержкой 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 применяется, вся логика строится математически, ИИ - это математика, даже внутренний менеджмент решается чисто математически.
Всю ее надо знать. Или часть, если хочешь быть узким специалистом.
Если изложенное непонятно, я могу сделать отсылки к стандарту где это все описано "во-сто-раз-еще-более-понятно"{sarcasm}. :)