Comments 7
Улучшенная логика загрузчика выглядит так (пример с заменой загруженного скрина на новый):Таким образом, если в меню и самой игре (двух разных экранах) используются большие текстуры, которые на слабом устройстве не влезут в память, у вас получится переполнение. Потому, что вы загружаете новые ресурсы еще не освободив старых.
Добавляем второй скрин, которому необходимы некие ресурсы
Если ресурсы не загружены, добавляем поверх него скрин загрузчика
Отображается анимация показа загрузчика, одновременно начинается загрузка ресурсов
После загрузки ресурсов, мы хотим отображать уже второй скрин, потому удаляем первый скрин
Отображается анимация сокрытия загрузчика
Скрываем загрузчик и меняем слушателя нажатий на второй скрин
И еще, у вас не раскрыта тема того, как сделать «плавную» смену скринов.
Спасибо за отзыв!
Вообще, архитектура приложения очень гибкая, и каждый скрин предоставляет своего загрузчика (это может быть один и тот же загрузчик, а могут быть и разные) при утрате контекста (pause/resume).
Потому, при необходимости удалять ресурсы до загрузки, ничего не мешает переопределить метод базового класса в очередном своем загрузчике.
На эту проблему можно посмотреть с другой стороны — на игровом экране имеются 60% неуникальных объектов (главный герой, боты, ui и прочее) и только 40% уникального контента, который тоже может быть неуникальным (тайлы карты, при смене левела могут быть новые, а могут остаться те же). В вашем случае пользователю придется ожидать загрузки ресурсов, которые уже были загружены. Выход — иметь разные загрузчики для разных ситуаций, и данная архитектура это позволяет.
Что вы подразумеваете под плавной сменой скринов?
Вообще, архитектура приложения очень гибкая, и каждый скрин предоставляет своего загрузчика (это может быть один и тот же загрузчик, а могут быть и разные) при утрате контекста (pause/resume).
Потому, при необходимости удалять ресурсы до загрузки, ничего не мешает переопределить метод базового класса в очередном своем загрузчике.
На эту проблему можно посмотреть с другой стороны — на игровом экране имеются 60% неуникальных объектов (главный герой, боты, ui и прочее) и только 40% уникального контента, который тоже может быть неуникальным (тайлы карты, при смене левела могут быть новые, а могут остаться те же). В вашем случае пользователю придется ожидать загрузки ресурсов, которые уже были загружены. Выход — иметь разные загрузчики для разных ситуаций, и данная архитектура это позволяет.
Что вы подразумеваете под плавной сменой скринов?
Я не верю в OutOfMemory
Я написал игру, в которой на старте загружались вообще все ресурсы. Проблемы возникали лишь при утрате контекста — тогда пользователю приходилось ждать по 10 секунд на слабом девайсе для загрузки текстур. OutOfMemory может возникнуть, если что-то было не учтено, например одна текстура не помещается в видеопамять (такая проблема в игре «Swing Copters» с текстурой 2048х2048, но на том же устройстве работает игра, где на старте грузятся 6 таких текстур, да и работает GTA). Решение этой проблемы кроется в использовании TextureFilter.MipMapNearestNearest. При загрузке текстуры на устройство с маленьким экраном текстура размером 2048х2048 будет уменьшена (например) до 512х512.
Я занимался разработкой игры, в которой требовалось хранить два слоя нетайловой карты 1024x1024, плюс несколько атласов врагов в псевдо-3D, которые поворачивались под разными углами. Плюс текстуры других объектов и большого количества GUI. Вот в таком случае богатой на графику игры, приходилось очень сильно извращаться. На многих новых (3 года назад) девайсах случались OOM именно из-за текстур.
Насчет плавной смены скринов я имею ввиду не переключение щелчком, а плавный съезд в сторону одного экрана, сдвигаемого другим. Либо плавного «выхода» из прозрачности через альфу. То есть, такие моменты, когда отображаются два экрана одновременно. Например, игровая сцена переходящая в сторилайн сцену, или в экран выбора следующего левела, или в экран результатов и ачивок.
Насчет плавной смены скринов я имею ввиду не переключение щелчком, а плавный съезд в сторону одного экрана, сдвигаемого другим. Либо плавного «выхода» из прозрачности через альфу. То есть, такие моменты, когда отображаются два экрана одновременно. Например, игровая сцена переходящая в сторилайн сцену, или в экран выбора следующего левела, или в экран результатов и ачивок.
Вашу проблему с ООМ в libgdx идеально решил бы TextureFilter.MipMapNearestNearest.
По поводу «плавной» смены скринов — я не говорил, что буду это рассматривать,
ведь статья о загрузчике и о загрузке зашифрованных ресурсов.
Я рассматривал ситауцию, в которой нужно показать скрин, ресурсы для которого еще не загружены.
По поводу «плавной» смены скринов — я не говорил, что буду это рассматривать,
ведь статья о загрузчике и о загрузке зашифрованных ресурсов.
Я рассматривал ситауцию, в которой нужно показать скрин, ресурсы для которого еще не загружены.
Вашу проблему с ООМ в libgdx идеально решил бы TextureFilter.MipMapNearestNearest.Интересно, каким образом? Предлагаете всю игру уменьшить в два раза? А как быть с фигурками монстров, отрендерреными из 3D в 2D с размерами около 40x40? Представляете, какая пикселизация будет?
Если ресурсы были подготовлены под разрешение 1920х1080, а игра запускается на телефоне с разрешением 800х480, то смысла сохранять исходный размер я не вижу, так как в результате картинки в любом случае будут меньшего размера.
Повторюсь - проблемы с ООМ часто бывают из-за кривых рук.
Устройство для тестов 2011 года с разрешением 800х480, 512 ОЗУ, 1 ГГЦ:
Игра «Swing copters» имеет лишь одну текстуру 2048х2048 и падает с ООМ сразу после старта.
Игра «Mad Bomber» загружает на старте много больше текстур и всё работает.
Игра «GTA 3» загружается без проблем и работает.
Игра «Swing copters» имеет лишь одну текстуру 2048х2048 и падает с ООМ сразу после старта.
Игра «Mad Bomber» загружает на старте много больше текстур и всё работает.
Игра «GTA 3» загружается без проблем и работает.
Что вы скажете о больших паралаксовых нетайловых фонах в 3-4 слоя?
Sign up to leave a comment.
Libgdx: экран загрузки и загрузка шифрованных ресурсов