2 D - a кс e л e р a т op - графический ускоритель для обработки двухмерных графических данных (2D), реализует аппаратное ускорение таких функций, как прорисовка графических примитивов, перенос блоков изображения, масштабирование, работа с окнами, мышью, преобразование цветового пространства. Первоначально видеоадаптеры с аппаратным ускорением графических функций делились на две группы: видеоадаптеры с графическим ускорителем (акселератором) и видеоадаптеры с графическим сопроцессором.
Графический акселератор - устройство, выполняющее заданные логические или арифметические операции по жесткому алгоритму, который не может быть изменен.
Графический сопроцессор - более универсальное устройство и работает параллельно с центральным процессором. Основное отличие графического сопроцессора от графического акселератора в том, что сопроцессор можно запрограммировать на выполнение различных задач, поскольку он является активным устройством: имеет возможность, как и центральный процессор, обращаться к системной оперативной памяти и управлять шиной ввода/вывода.
В современных видеоадаптерах объем и сложность графических функций, выполняемых графическим сопроцессором, стали соизмеримы с объемом задач, решаемых центральным процессором ПК. В связи с этим Chipset, составляющий основу современного видеоадаптера с аппаратной поддержкой графических функций, называют графическим процессором.
З D -акселераторы предназначены для обеспечения возможности видеть на экране проекцию виртуального (не существующего реально) динамического трехмерного объекта, например, в компьютерных играх. Такой объект необходимо сконструировать, смоделировать его объемное изображение, т.е. задать математическую модель объекта (каждую точку его поверхности) в трехмерной системе координат, аналитически рассчитать всевозможные зрительные эффекты (угол падения света, тени и т.п.), а затем спроецировать трехмерный объект на плоский экран. ЗD-акселератор необходим только в том случае, когда объемное изображение синтезируется компьютером, т. е. создается программно.
Совокупность приложений и задач, в рамках которых реализуется эта схема построения трехмерного изображения на экране монитора PC, называется трехмерной графикой, или 3D (З- Dimentional - трехмерный).
Синтез трехмерного изображения. Зd-конвёйер
Синтез ЗD-изображения выполняется путем аналитического расчета различных параметров изображения для создания визуальных эффектов, обеспечивающих ощущение его объемности и реальности. В частности, в процессе синтеза ЗD-изображения выполняются:
оценка расстояния до предмета путем анализа информации о его размерах (чем меньше объект - тем он дальше);
оценка последовательности наложения предметов один на другой (кто выше - тот ближе);
определение глубины пространства за счет использования эффекта перспективы, т. е. визуального сближения параллельных линий, уходящих вдаль;
анализ световых эффектов на предмете (теней, бликов и т. п.).
Для получения этих эффектов процесс синтеза трехмерного изображения объекта в виде его двухмерной проекции на экране монитора строится по модели, называемой З D -конвейером. Выделяют следующие основные этапы ЗD-конвейера.
1.Построение геометрической модели поверхности объекта путем задания трехмерных координат его опорных точек и уравнений соединяющих их линий. Полученная геометричес-кая модель представляет собой так называемую каркасную модель объекта (Wireframe). На рис. 4.14 изображена каркасная модель тора, заданного координатами центра 0 (х, у, z), внут-ренним радиусом R1 и радиусом сечения R2.
2.Разбиение поверхности полученного объекта на элементарные плоские элементы (прямоугольники или треугольники) - тесселяция (Tesselation), или триангуляция. Это приводит к тому, что поверхность объекта представляет собой совокупность плоских граней - многоугольников, в частности треугольников, как показано на рис. 4.15. Поверхность объекта воспроизводится точнее при увеличении числа и уменьшении размеров многоугольников (ср. рис. 4.15, а, б).
3.Моделирование движения объекта: его перемещение, вращение и изменение размеров (формы) - трансформация (transormation) - сводится к стандартному преобразованию ко-ординат вершин отдельных граней в виде многоугольников и реализуется путем выполнения множества различных алгебраических опера-ший с использованием тригонометрических функций. На рис. 4.16 показана трансформация формы объекта путем изгиба и скручивания.
4.Расчет освещенности (Lighting) и затенения (Shading) объекта производится в два этапа. Сначала выполняется расчет освещенности каждого элементарного многоугольника с учетом его удаленности от источника света и угла падения светового луча. Чтобы поверх-ность объекта не выглядела состоящей из множества отдельных плоских граней, как это показано на рис. 4.17, а, применяют методы затенения, т.е. дополнительно производят интер-поляцию значений освещенности, позволяющую плавно изменять освещенность каждой грани и скрыть резкие переходы между ними (рис. 4.17, б).
5. Проецирование синтезированного трехмерного объекта на плоскость экрана, т.е. первое, предварительное преобразование трехмерного объекта в совокупность двухмерных. При этом в Z-буфере сохраняется совокупность данных о расстоянии каждой из вершин элементарного многоугольника, образующего грани, до плоскости проецирования. Это позволяет в дальнейшем определить, какие части объекта окажутся видимыми, а какие - нет. Наличие Z-буфера - важнейшее отличие работы с трехмерной графикой от работы с двухмерной.
Удаление скрытых поверхностей - HSR (Hidden Surface Removal), т.е. исключение из проецирования тех элементов поверхности объекта, которые оказываются невидимыми с точки наблюдения.
Закраска элементарных треугольников, или текстурирование, выполняется наложением текстур (Texture Mapping). Текстура (Texture) - это элемент обшивки объекта, т.е. изобра-жение участка его поверхности, которое хранится в виде квадратной растровой картинки, состоящей из текселов (Texel - Texture Element - элемент текстуры). После наложения текстуры (рис. 4.18, а) каркасная модель как бы покрывается своеобразным покрытием - текстурой и становится похожей на реальный объект (рис. 4.18, б). В процессе текстурирования каждый многоугольник, составлявший каркасную модель, заменяется на элемент текстуры, а значение каждого пиксела двухмерного изображения вычисляется по значению соответствующего тексела текстуры.
При текстурировании производится обработка растровой графики, что приводит к необходимости применять различные приемы коррекции изображения, например применение текстур с различным разрешением - мипмэппинг.
MIP -текстурирование, или мипмэппинг (MIP - Multum In Parvo - много в одном), применяется для устранения пикселизации при приближении к ЗD-объекту. MIP-текстурирование заключается в том, что в памяти акселератора хранятся несколько копий одной и той же текстуры, но с различным разрешением LOD (Level Of Detalization - уровень детализации). Каждая последующая копия текстуры содержит в четыре раза больше пикселов, чем предыдущая. Совокупность всех копий одной и той же текстуры называют MIP-каскадом, пример которого дан на рис. 4.19. В процессе «прорисовки» ближних к наблюдателю поверхностей используются более крупные текстуры, а при прорисовке дальних - более мелкие. Применение мипмэппинга требует значительных объемов памяти акселератора. Для хранения текстуры не в локальной памяти ЗD-акселератора, а в RAM PC и при необходимости быстро их подгружать используется локальная шина AGP с высокой пропускной способностью.
9. Моделирование эффектов прозрачности и полупрозрачности заключается в том, что на основе информации о взаимной прозрачности объектов и среды выполняется коррек-ция цвета пикселов - так называемое альфа-смешение (Alpha - blending ) и затума-нивание (Fogging ).
10. Коррекция дефектов изображения путем сглаживания - ан тиалиасинг (Anti - aliasing ). Антиалиасинг применяется для устранения дефектов изображения типа «лестничного» эффекта на наклонных линиях, муара. Различают краевой (Edge Anti-aliasing) и пол-ный (Full-screen Anti-aliasing - FSAA) антиалиасинг. В первых моделях игровых уско-рителей использовался только краевой антиалиасинг, для современных ЗD-акселераторов обязательным является полный антиалиасинг.
Краевой антиалиасинг заключается в усреднении цвета пикселов на краях (реб-рах) грани на основе взвешенного суммирования цветов прилегающих граней. Техника взвешенного суммирования заключается в определении весовых коэффициентов, с которыми суммируются цвета при определении цвета краевого пиксела. При этом пола-гают, что каждая точка (линия) на краю грани имеет фиксированную, ненулевую пло-щадь, а значения весовых коэффициентов зависят от того, какую часть этой площади перекрывают прилегающие грани. На рис. 4.20 дана иллюстрация техники взвешенного суммирования.
Полный антиалиасинг, или субпикселный антиалиасинг, используется для полного устранения всех дефектов. Суть данного метода в том, что коррекция дефектов выполняется с так называемым виртуальным разрешением, которое выше исходного. При этом каждый пиксел представляется состоящим из нескольких виртуальных субпикселов, над которыми производится антиалиасинг, как показано на рис. 4.21. После коррекции, когда цвета всех субпикселов определены, исходное разрешение восстанавливается.
Интерполяция недостающих цве тов - (Dithering ) используется в том случае, когда в текущем видеорежиме 3D-акселератора для кодирования цвета пиксела используется менее 24 бит (напри мер, в режиме High Color при 16-битном цвете).
Окончательное формирование кадро вого буфера (Frame Buffer ) - области памяти ЗD-акселератора, в которую помещается спроецированное двухмерное изображение. Кадровый буфер используется для формирования выходного, аналогового видеосигнала ЗD-ускорителя.
Для ускорения процесса создания изображения используется механизм двойной буферизации, при котором выделяется память одновременно для двух смежных кадров: построение следующего кадра начинается еще до того, как закончится отображение предыдущего. В результате обеспечивается более плавная смена кадров.
13. Постобработка (Post-processing) применяется в том случае, когда требуется реализовать какие-либо двухмерные эффекты над подготовленным кадром как единым целым.
Этапы 1-6 ЗD-конвейера образуют его геометрическую стадию, на которой выполняются интенсивные тригонометрические вычисления с помощью CPU. Однако существует тенденция обеспечения современных игровых ЗD-акселераторов специальным процессором, обеспечивающим аппаратное ускорение выполнения геометрической стадии ЗD-конвейера.
Этапы 7-13 ЗD-конвейера образуют стадию прорисовки объекта, или стадию рендеринга (Rendering-изображение, рисование, визуализация). На этой стадии все действия выполняются уже с растровыми объектами, состоящими из отдельных, дискретных элементов - пикселов и текселов. Выполняемые на стадии рендеринга операции не характерны для центрального процессора (как на геометрической стадии), поэтому именно на этом этапе конвейера необходимо аппаратное ускорение. Большинство современных ЗD-ускорителей предназначено для рендеринга на аппаратном уровне и различается лишь числом реализуемых функций.
Программным интерфейсом для ЗD-акселераторов служит так называемый интерфейс прикладного программирования (Application Program Interface - API). API занимает промежуточное положение между высокоуровневыми прикладными программами и низкоуровневыми командами различных ЗD-акселераторов и обеспечивает эффективное преобразование запросов прикладной программы в оптимизированную последовательность низкоуровневых команд. Благодаря API, разработчики прикладных программ избавлены от необходимости работать с низкоуровневыми командами акселератора.
В настоящее время существуют несколько платформ API, отличающихся областями применения.
DirectX разработана фирмой Microsoft, используется в игровых приложениях, работающих под управлением операционной системы Windows 95/98, и включает в себя несколько узконаправленных API:
DirectDraw обеспечивает использование аппаратных средств ускорения обычной, двухмерной графики;
Direct3D отвечает за работу графической системы в режиме создания трехмерных изображений;
DirectInput обеспечивает аппаратно независимый ввод информации в ПК через клавиатуру, мышь и джойстик;
DirectPlay используется при совместной игре на нескольких компьютерах, объединенных в сеть или соединенных непосредственно, через параллельный или последовательный порты;
DirectSound управляет использованием ресурсов звуковой системы ПК.
В архитектуре Direct3D заложен принцип проверки функциональных возможностей установленного аппаратного обеспечения. В соответствии с этим принципом прикладная программа сначала запрашивает Direct3D-coвместимый драйвер об аппаратно поддерживаемых данным акселератором ЗD-функциях, а затем в зависимости от ответа активизирует поддерживаемые функции. Это избавляет от необходимости производить ручную настройку.
DirectX является жестко регламентированным, закрытым стандартом, который не допускает изменений до выхода в свет своей новой версии.
OpenGL используется в основном в профессиональных приложениях (CAD, системы трехмерного моделирования, симуляторы и т.п.), работающих под управлением операционной системы Windows NT. Вместе с тем существуют и игры, ориентированные на OpenGL, например Quake.
API OpenGL построен на основе концепции открытого стандарта, имеющего небольшой базовый набор функций и множество расширений, реализующих более сложные функции. Производитель Chipset карты ЗD-акселератора обязан создать BIOS и драйверы, выполняющие базовые функции OpenGL, но не обязан обеспечивать поддержку всех расширений. В результате возникают проблемы, связанные с написанием производителями драйверов для своих изделий, которые поставляются как в полном, так и в усеченном виде. К числу OpenGL-совместимых драйверов относятся следующие:
ICD (Installable Client Driver - драйвер приложения-клиента) обеспечивает максимальное быстродействие, поскольку содержит низкоуровневые коды, обеспечивающие поддержку не только базового набора функций, но и его расширений.
MCD (Mini Client Driver) содержит оптимизированный код лишь для некоторых этапов ЗD-конвейера, поэтому акселератор под его управлением работает медленнее.
Мини-порт - группа специализированных OpenGL-совмеcтимых драйверов, каждый из которых специально разработан для работы с какой-либо одной программой или игрой. Такой мини-порт применяется, когда, например, возникает необходимость поиграть в QuakeGL или Quake II на ПК с Windows 95 и 3D-акселератором, не рассчитанным на использование OpenGL.
Раппер (Wrapper - устройство для оборачивания, завертывания, окутывания) - мини-порт, который может работать как ICD за счет перевода инструкций OpenGL в инструкции Direct3D, эбеспечивая при этом самую низкую скорость работы по сравнению с драйверами других типов.
Game Engine - «игровой движок» - драйвер, разработанный Идя конкретной ЗD-платы и обеспечивающий максимальную производительность за счет непосредственного использования низкоуровневых команд акселератора, без использования API.
Принципиальным отличием API OpenGL от DirectX является Го, что OpenGL ориентирован на корректность создаваемых изображений, тогда как для DirectX важны скорость прорисовки и естественность изображения.
Кроме того существуют Native API, создаваемые производителями ЗD-акселераторов исключительно для своих Chipset с целью наиболее эффективного использования их возможностей.
Для настройки видеосистемы с целью обеспечения максимальной производительности при работе с трехмерной графикой пользователь ПК должен:
*при выборе ЗD-платы четко представить область ее будущего применения: игры или решение профессиональных задач;
*установить в систему требуемый API;
*проконтролировать настройку параметров драйвера и/или прикладной программы, задействовав необходимые функции 3D-aK-:елерации;
*используя тесты и оценивая качество изображения визуально, подобрать набор функций, обеспечивающих наилучшее качество изображения.
При работе с программами, ориентированными на DirectX, пользователь не выполняет перечисленные выше настройки, поскольку они производятся автоматически.
Устройство и характеристики видеоадаптера
Первые ЗD-акселераторы выполнялись в виде самостоятельного устройства только для работы с трехмерной графикой, устанавливаемого в слот шины ввода/вывода и соединяемого с видеоадаптером специальным кабелем.
Современные видеоадаптеры содержат один мощный графический процессор, в состав которого входит ЗD-акселератор. В связи с этим понятие «ЗD-акселератор» означает не специализированную плату, а универсальный видеоадаптер, в состав которого входит ускоритель трехмерной графики.
Современный видеоадаптер (видеокарта) включает следующие основные элементы :
Графический процессор;
Модули оперативной памяти;
RAMDAC - цифроаналоговый преобразователь, выполняющий преобразование цифровых сигналов ПК в сигналы, формирующие изображение на мониторе.
Интегральным показателем качества видеоадаптеров, сфера применения которых - в основном трехмерные игры, является частота смены кадров (frame per second - fps). В каждой трехмерной игре этот показатель будет различным.
Качество современного видеоадаптера можно считать удовлетворительным, если в игре Quake при разрешении 1600x1200 он обеспечивает 60 - 70 fps.
Другим показателем качества видеоадаптера является максимальное число обрабатываемых элементарных простых объектов (многоугольников, треугольников) в секунду. Эти значения для отдельных видеоадаптеров составляют 800-1200 млн/с.
Объем оперативной памяти видеоадаптеров достигает 128 Мбайт. Типы памяти, используемой в видеоадаптерах, аналогичны модификациям обычной оперативной памяти. В недорогих моделях используется память SDRAM или ее более быстрая графическая модификация SGRAM со временем доступа 7 -8 не. Более совершенные модели оснащены памятью DDR SDRAM со временем доступа 5 -6 не.
Частота работы графического чипа и памяти видеоадаптера может быть одинаковой или разной. Например, базовая частота чипа самых популярных видеокарт 2004 г. составляла свыше 500 МГц, а частота памяти - более 1000 МГц.
Частота RAMDAC определяет качество видеоадаптера. Большинство современных видеокарт имеют частоту RAMDAC в диапазоне 250 - 400 МГц.
Тип интерфейса с шиной ввода/вывода оказывает существенное влияние на быстродействие всей видеосистемы. Для эффективной работы с трехмерной графикой современные видеоадаптеры ком плектуются интерфейсом AGP. AGP4x - суперскоростной режим, обеспечивающий скорость обмена 1,06 Гбайт/с. На компьютерном рынке наиболее популярны видеокарты на чипсете собственной оригинальной разработки, предлагаемые фирмами ATI, Matrox и 3dfx, в то время как чипсеты фирмы Nvidia используются в составе видеокарт других производителей. Видеокарты ATI предпочтительнее в мультимедийных комплексах, производства 3dfe - в игровых приложениях, а фирма Matrox специализируется на двухмерной графике.
Для поддержки спецэффектов в игровых приложениях (анти-алиасинга, имитации тумана, пламени, ряби на водной глади) в процессор видеоадаптера все чаще встраивают специальный блок «трансформации и освещения» (Т&Т), который позволяет получить высокое качество игрового изображения.
Для приема телевизионных сигналов и вывод их на монитор в плату видеоадаптера встраивают TV-тюнер. Встроенные TV-тюнеры не отличаются высоким качеством изображения, которое может воспроизводиться в небольшом окне Windows. TV-тюнеры, устанавливаемые в отдельный слот компьютера, обеспечивают полноэкранный режим и высокое качество изображения, обеспечивая при этом выполнение дополнительных сервисных функций: телефонные переговоры через Internet, прослушивание радио, прием спутникового телевидения при наличии спутниковой антенны.
Внешние TV-тюнеры, подключаемые через порт USB, обеспечивают воспроизведение телепередач в «оконном» режиме на экране монитора.
Доброе утро, Хабр!
Обнаружил на xda-developers.com интересную для себя новость, которая является пересказом свежего поста «Разрушаем мифы о полном аппаратном ускорении в ICS» из Google+ профиля разработчика Google Дианы Hackborn. Взял на себя смелость сделать краткий перевод-пересказ по мотивам этих двух публикаций, который и привожу ниже под хабракатом. Первый вариант этой публикации уже был опубликован мной этой ночью в блоге R2-D2: Android с пользой , но тема показалась мне достойной освещения и на Хабрахабре (я надеюсь тут не нужно поднимать повторно обсуждение того факта, что раздел «Ссылки» после осеннего хабраобновления практически и фактически умер).
Разработчик из Google Диана Hackborn на своей странице в Google+ поделилась информацией касательно аппаратного ускорения интерфейса в Android 4.0 Ice Cream Sandwich. Ажиотаж который поднялся вокруг этой функции возник не просто так - слишком много упреков звучало в адрес плавности отрисовки 2D-элементов в Android в сравнении с другими мобильными ОС.
Безусловно, аппаратное ускорение в Android это позитивная вещь, но есть много неправильных представлений о том что на самом деле представляет из себя эта возможность. Во-первых, Android уже много лет поддерживает аппаратное ускорение для задач отрисовки множества окон (речь идет о композиции окон - панель задач, оповещения, панель меню, появление и скрытие элементов интерфейса). Это означает что вся анимация элементов интерфейса в Android всегда использовала аппаратное ускорение.
В отличии от отрисовки композиции окон, рендеринг изображения внутри окна традиционно осуществлялся при помощи процессора в Android 2.X и ниже. Однако, в Android 3.0 Honeycomb, эти функции могут быть переложены на графический ускоритель, но только в том случае если в манифесте приложения это прямо указано опцией android:hardwareAccelerated=”true”. Единственное отличие Android 4.0 ICS в том, что при разработке, используя последнее доступное API level 14 (и во всех будущих), эта опция для приложений включена «по умолчанию».
Казалось бы, теперь у нас есть возможность «заставить» работать все приложения в Android 4.0 ICS с включенным аппаратным ускорениям независимо от его манифеста, разве это не прекрасно? На самом деле это не совсем так. В случае, например, с видеоускорителем PowerVR драйвера, используемые в Nexus S и даже в Galaxy Nexus, «отъедают» по 8Мб оперативной памяти за каждый процесс который использует аппаратное ускорение. Вроде бы не так много? Не тут-то было, ведь такое активное потребление оперативной памяти сразу множеством процессов значительно повышает потребление памяти в целом, что сразу сказывается на скорости мультизадачности - вплоть до значительного ее замедления. В итоге, команда разработчиков Google сейчас тратит значительные усилия на тонкую настройку того, какие именно части пользовательского интерфейса действительно нуждаются в аппаратном ускорении на Nexus S.
Что же в итоге? По сравнению с Android 2.X, Ice Cream Sandwich имеет больше возможностей, в том числе благодаря более широкому использованию аппаратного ускорения. Тем не менее, кроме наличия опции включенного ускорения «по умолчанию», использование аппаратного ускорения в ICS ничуть не более «полное», чем это было ранее. И, кроме всего прочего, не стоит забывать что аппаратное ускорение это не магия и не чудо, как считают многие, но его присутствие это конечно плюс, а не минус.
Всем доброго времени дорогие друзья, знакомые, читатели и прочие личности. Сегодня посмотрим как ускорить Андроид, всякие там приложения под него и игры вроде PUBG Mobile в том числе
Для многих не секрет, что мы любим чего-то покрутить и поотмизировать, что порой выливается в разного рода интересные интересности или странные странности. Впрочем, часто усилия приносят страшную такую пользу и Ваши устройства начинают бегать на порядок быстрее.
Сейчас мы наблюдаем занимательную историю, когда развитие железной компьютерной индустрии достигло некоего своего логического (и не очень) пика и все технологии (в том числе программные) ринулись в сферу мобильных устройств.
Вот о последних сегодня и поговорим.
Вводная
Все наверное слышали про всякие там режимы разработчика в Android, которые позволяют что-то такое там хитрое нашаманить в настройках.
Эти настрои действительно существуют и хитрое нашаманить реально позволяют. Вопрос лишь в том, - будет ли это на пользу и не очень, - да и кому, собственно, - Вам, Вашей батареи, производительности, или некому разработчику.
Тем не менее, - ведь попытка не пытка. Во-первых, телефон можно сделать быстрее, во-вторых и в трехмерных играх всё будет бегать побыстрее (с выходом PUBG Mobile ) все прямо помешались на этой идее), да и вообще, - интересно и приятно.
Что касается возможных побочных эффектов, - тут всё просто. В некоторых случаях всё конечно идет здорово, весело и всячески на пользу. Производительность растёт, ускорение присутствует, PUBG летает, лаунчер телефона счастлив безмерно, а Вы, как его владелец, - пишите хорошие комментарии под этой статьёй, рассказываете о ней друзьям и всё такое прочее-разное.
Во всех остальных же случаях, стоит понимать, что многое зависит от железа в Вашем Android-телефоне, планшете или на чём Вы там планируете всё это запускать и использовать, - так тут вопрос техники.
И да, стоит понимать, что производительность может снизиться, а расход батареи увеличится. Как это исправить? Вернуть всё назад, настройки отключить.
Как ускорить Андроид и запустить настройки разработчика
Итого нам требуется "Многопроцессорный WebView ", - это один из крайне важных пунктов, который ускорит систему вцелом, хотя и может негавтивно сказаться на времени работы от батареи.
Как ускорить Андроид еще сильнее? И визуально понятно? Тоже самое касается пункта "оптимизация SD карты ", если конечно она у Вас вообще есть (карта) и пункт вообще).
Дальше, если Вы не любитель всяческих там анимаций, то крайне рационально будет отключить анимацию окон, переходов и убрать длительность анимации. Это на порядок сэкономит ресурсы, а визуально (субъективно и по ощущениям) у Вас телефон прямо начнет летать вообще.
Еще больше ускорения и оптимизации
Что касается аппаратного ускорения и GPU для компоновки экрана, - считается этот пункт актуален только на быстрых графических ядрах и только для 2D -приложений.
На деле это не всегда так, плюс ко всему, помимо всяких там PUBG Mobile и других 3-х мерных игр для Android , которые Вы и пытаетесь ускорить, собственно, - дело в том, что у Вас всегда задействован процессор как таковой, который работает с интерфейсом и процессами в фоне, поэтому перекладывая часть функционала на Вы можете получить некоторый прирост производительности.
Ну, и если памяти или мощностей у Вас не очень, а поиграть на любимом телефоне хочется, то есть смысл таки подрезать число фоновых процессов. Это конечно скажется на некоторых уведомлениях (например, почты), но зато повысит скорость работы в общем и целом, да и в трёхмерных приложениях в частности.
Послесловие
На сим всё, теперь Вы знаете как ускорить Андроид. Традиционно, - это не моветон и нюансов может быть много. У кого-то сие возымеет эффект, а у кого-то начнет кушать батарею. Кто-то вообще не заметить разницы и не поймет зачем оно вообще нужно.
Многое зависит от способа использования Вашей железки на Андроиде, её конфигурации, версии системы, процессора, памяти, места, игр в которые играете и многого другого.
Такие дела. Если интересно, - пишите в комментариях, - мы разовьем тему и расскажем как тем же Kernel Auditor "ом реально ускорить любой девайс, исходя из глубокого настройка ядра любого телефона.
Как и всегда, если есть какие-то мысли, вопросы, дополнения и всё такое прочее, то добро пожаловать в комментарии к этому материалу.
Я знаю приличное количество С++, и теперь я хотел исследовать создание игры. Мне было интересно, какой лучший подход будет в плане написания аппаратной ускоренной игры, которая по-прежнему кросс-платформенная (Windows/OSX/Linux). Это будет игра 2d, но достаточно интенсивная, чтобы рендеринг CPU, вероятно, не сократил бы ее.
Наконец, я видел такие библиотеки, как http://www.sfml-dev.org/ , которые, возможно, упростили, следует ли мне спуститься по этому маршруту?
Еще раз спасибо.
6 ответов
Это нонсенс ребята
OpenGL IS кросс-платформенный. Нет необходимости в Qt или такой. Необходимо адаптировать только несколько частей: API окон и API ввода, которые являются единственными функциями, зависящими от подпрограмм, специфичных для ОС.
У вас есть несколько возможностей:
Перекрестная платформа с аппаратным ускорением 2d С++ app?
SDL_Init(SDL_INIT_VIDEO); SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8); SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8); SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8); SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16); SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1); SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);//disable vsync if (SDL_SetVideoMode(scrWidth, scrHeight, 32, SDL_OPENGL) == 0){ fprintf(stderr, "couldn"t set mode %dx%d!\n", 640, 480); SDL_Quit(); return -1; } glewInit();//if you use glew, shaders, extensions. while(gameIsRunning()){//game loop glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); //OpenGL rendering here glFlush(); SDL_GL_SwapBuffers(); } SDL_Quit();Я знаю, что OpenGL, но я не могу найти каких-либо учебников о том, как использовать его в кросс-платформенной манере, все они сосредоточены на одной платформе.
Подробнее см. в документации по sdl.
Использование SDL также возможно, но я боюсь, что игра может не работать, если я ее использую. Это обязательно верно?
Если vsync отключен, вы можете получить от нескольких сотен до тысячи кадров в секунду. Точная производительность зависит от сложности вашего оборудования и сложности сцены. У меня было 300 кадров в секунду для простого 3D-искателя подземелий, в котором использовался "RAW" opengl без отображения списков/объектов буфера вершин. Кроме того, если вы используете механизм с фиксированной частотой кадров или таймером, вы не будете получать больше кадров в секунду, чем вы просили.
SDL использовался для переноса Unreal 2004 на Linux. Он также использовался в порту Linux Doom 3/Quake 4. Поэтому он тщательно протестирован и хорошо известен.
Для меня вопрос не в том, следует ли вам использовать библиотеки или нет. Это библиотека, которую вы должны использовать. Если вы хотите написать игру, найдите библиотеки, которые будут решать большинство проблем с переносимостью для вас. Это позволит вам сосредоточиться на том, что важно больше всего: самой игре. Другие дали больше предложений библиотеки, которые я мог бы вам дать.
Я думаю, что ошибочно беспокоиться о производительности, прежде чем вы даже начали свой проект. Работайте над проблемами производительности, такими как любая другая проблема, с которой вы сталкиваетесь во время разработки. Создайте свою программу, чтобы изолировать библиотеки на одном уровне, отличном от остальной части вашей логики. При необходимости будет проще переключать реализацию. Это даже позволит экспериментировать с различными реализациями.
// separate files class LowLevelGraphicStuff { // abstract }; class LowLevelGraphicStuff_SFML: public LowLevelGraphicsStuff { // actual SFML implementation }; class LowLevelGraphicsStuff_OGL: public LowLevelGraphicsStuff { // actual OpenGL implementation }; // main // Run the game with the SFML implementation. gameLoop(new LowLevelGraphicsStuff_SFML()); // Run the game with the OpenGL implementation. gameLoop(new LowLevelGraphicsStuff_OGL());
