Download as PDF
Автор: Ли Бэмбер (Lee Bamber)
1. Введение
Недавно я занимался подготовкой игрового движка, над которым я работал для конференции Games Developer Conference. Учитывая значимость этого мероприятия, было важно, чтобы игра достаточно быстро работала на трех устройствах, которые были у меня под рукой: от современного Ultrabook™до системы на два поколения старше.
В этой статье вы узнаете, как увеличить скорость трехмерной игры, и поймете, на что нужно обращать внимание при переносе своих приложений на Ultrabook. Будь вы опытным разработчиком игр, или же программирование для вас просто хобби — в любом случае вы наверняка понимаете важность высокой производительности. Игра, идущая плавно и с высокой кадровой скоростью, будет восприниматься как намного более качественная и профессиональная, нежели игра, спотыкающаяся на несчастных пяти кадрах в секунду. Никакая сколь угодно захватывающая графика не скроет тот факт, что игра просто тормозит, дергается на экране (из-за постоянного рассогласования с вертикальной разверткой монитора), а о сколько-нибудь приемлемой реализации физики и говорить нечего. В этом примере с настоящим игровым проектом я постараюсь рассказать о возможных проблемах при переносе игры на разные платформы и способах решения таких проблем.
![]()
Рисунок 1. Если у вашей игры красивые снимки экрана, это поможет поднять продажи, но за низкую кадровую скорость расплачиваться придется уже вам!
В этой статье описывается несколько распространенных причин потери производительности. Разработчикам игр предлагается полезная информация по переносу высококачественных трехмерных игр высшего уровня на Ultrabook с нужным уровнем производительности. Для работы таких игр с комфортной скоростью зачастую требуется мощный дискретный видеоадаптер, а нагрузка на GPU весьма высока. Здесь может пригодиться понимание архитектурных различий между выделенными и интегрированными GPU, но лучший способ повышения производитель¬ности графической подсистемы — анализ конвейера обработки графики для выявления узких мест с дальнейшей оптимизацией этих областей без снижения качества изображения.
Требуется базовое понимание вызовов графических API в целом, знание компонентов, образую¬щих типичные трехмерные игры, а также некоторое знание или опыт использования Ultrabook.
2. Почему важна производительность?
Число игроков на рынке приложений и игр постоянно растет, поэтому уникальные полезные особенности ваших продуктов становятся все более важными для коммерческого успеха, а хорошая производительность сейчас рассматривается не как некий желаемый результат, а как строго необходимый атрибут любой программы или игры. Современные пользователи даже не будут считать вашу игру законченной, если она не будет работать достаточно гладко и комфортно на их устройстве, и не будут возвращаться к игре, если с самого начала о ней сложится отрицательное впечатление.
Это обстоятельство крайне важно. Если же учесть еще и быстрый рост рынка мобильных телефонов, планшетов и ноутбуков, окажется, что производительность имеет первостепенное значение. Вы можете удовольствоваться адаптацией игры к Ultrabook, учитывая высокую вычислительную мощность этих устройств по сравнению с остальными, но пользователи всегда будут требовать высших стандартов и ожидать максимального удобства.
![]()
Рисунок 2. Ultrabook раскрывает немалую мощь в умелых руках.
С точки зрения выработки полезных навыков все, что вы сейчас можете сделать для оптимиза¬ции и улучшения кода игры, вы сможете применять и во всех дальнейших проектах, повысив свою квалификацию разработчика.
3. Зачем оптимизировать?
Многие разработчики используют для создания и тестирования трехмерных игр настольные ПК. Из-за наличия выделенного графического адаптера иногда возникает ощущение безграничности вычислительных ресурсов, а это приводит к появлению в коде игр таких алгоритмов и шейдеров, которые работают на самом пределе возможностей GPU. Если же запустить такую игру на менее мощной платформе, она может работать гораздо медленнее. Ultrabook — это исключительно мощные мобильные устройства, но по «грубой силе» обработки графики они все же немало уступают мощным современным графическим процессорам. Кроме того, Ultrabook предназначены для мобильного использования, поэтому может оказаться, что в процессе игры Ultrabook будет работать от аккумулятора: конвейер отрисовки должен быть очень эффективным, чтобы избежать быстрого израсходования всей электроэнергии. Все эти факты необходимо учитывать при создании игровой графики.
![]()
Рисунок 3. Варианты использования успешного приложения.
При разработке приложений программисты обычно двигаются «сверху вниз»: сначала создают приложение, а потом стараются адаптировать его для как можно большего количества устройств в рамках отведенного на разработку времени.
Простейший подход — разрабатывать игру на Ultrabook, а затем переносить ее на настольный компьютер с выделенным графическим адаптером: при этом для переноса игры не требуется практически никаких действий. Тем не менее, вашими конкурентами могут стать игры, для которых планка качества установлена гораздо выше. Преимущество у такого подхода только одно: вы с самого начала учитываете время работы системы от аккумулятора и с большей вероятностью разработаете игру, которая будет снижать потребление ресурсов в определенные моменты, например во время заставок или на экранах настроек. Более распространенный подход — разработка на настольном ПК с последующей оптимизацией для Ultrabook: в этом случае, как правило, достигается более высокое качество, поскольку изначально концепция разработки нацелена именно на это.
4. С настольного компьютера на Ultrabook: пример битвы за производительность.
Мой рассказ начинается за много недель до крупного мероприятия — конференции GDC. Моя игра работает на достаточно современном графическом адаптере стоимостью около двухсот долларов с интерфейсом PCI Express* 3.0. При наивысшем качестве графики моя игра выдавала порядка 60 кадров в секунду. Это был вовсе не сверхмощный игровой компьютер, но я мог запускать любые трехмерные игры с самым высоким качеством графики без сколько-нибудь ощутимых проблем с производительностью. В моем распоряжении было шесть ядер, 6 гигабайт системной памяти и массив крайне быстрых твердотельных дисков. Я знал, что на конфе¬ренции в моем распоряжении не будет настольных компьютеров, и не собирался везти с собой через полмира здоровенный стационарный компьютер. Следующим по мощности устройством был мой Ultrabook, который вполне годился для поездки: именно его я и решил взять с собой.
![]()
Рисунок 4. GDC 2014 — одна из крупнейших конференций разработчиков.
Мой Ultrabook оснащен процессором Intel® Core™ 4-го поколения с графикой Intel® HD Graphics 4000™: это мое любимое устройство, когда я не на работе. Результаты первого теста оказались, прямо скажем, катастрофическими: кадровая скорость упала настолько, что вообще вся затея начала казаться мне чересчур смелой. Используемая сборка трехмерного игрового движка широко использовала шейдеры и отрисовку множества объектов одновременно. Игра просто глотала циклы CPU, как конфетки, стараясь дотянуться до всех доступных ресурсов. Разумеется, с таким подходом моей игре было крайне далеко до экономных и дружественных приложений, подходящих мобильным устройствам.
Несмотря на очевидную наглость моего плана, я все же знал, что современные Ultrabook — это вполне мощные игровые системы, при правильном подходе они не отстают от настольных компьютеров по производительности, существенно опережая их в удобстве. Кроме того, мне приходилось играть во множество игр на Ultrabook, поэтому я знал, что моя задача вполне выполнима: я решил добиться от игры 60 кадров в секунду.
Написанием кодов я занимаюсь очень давно: я научился программировать задолго до появле-ния анализаторов производительности и графических отладчиков, поэтому основной способ обнаружения узких мест состоял в том, чтобы удалять огромные фрагменты движка до тех пор, пока производительность не повысилась бы. Затем, возвращая по очереди важные фрагменты кода обратно в игру, я мог определить, какие части движка работали медленнее всего. После определения узких мест (а просто взять и удалить их было невозможно) начинался осторожный процесс снижения ресурсоемкости компонентов. Примеры такого подхода: исключение обычного расчета карты в шейдерах для пикселей за пределом определенного расстояния от игрока; пропуск вызовов обновления искусственного интеллекта в каждом втором цикле, чтобы снизить издержки на эти процессы. Это незначительные улучшения, но в сумме они дают весомый эффект, и уже довольно скоро игровой движок стал работать намного быстрее практически без потерь в качестве изображения.
Программистам, для которых отладка производительности является относительно новой областью, я искренне рекомендую не прибегать к такому способу обнаружения узких мест. Можно исполь¬зовать множество инструментов, помогающих выявлять проблемы производитель¬ности вашего приложения, причем эти средства не только выявляют узкие места, но и указывают на природу проблемы. Один из таких бесплатных инструментов — пакет Intel® Graphics Performance Analyzers. Это решение профилирует ваше приложения в ходе его работы и предоставляет снимок всей деятельности программы: что именно она делает и сколько времени это занимает. При демонстрации игры на конференции я обнаружил несколько проблем, которые я впослед¬ствии исправил, чтобы повысить производительность и плавность игры.
![]()
![]()
Рисунок 5. До и после: снимки экрана игры до и после оптимизации.
Как видно на рисунке 5, мне удалось повысить скорость с 20 до 62 кадров в секунду при крайне незначительных различиях в качестве графики. На снимке экрана «после» удалено мощное динамическое освещение вокруг игрока, а также применен менее агрессивный шейдер фрагментов.
«Голодные» шейдеры
Мы быстро определили, что наибольшее снижение производительности было на этапе отрисовки графики.
![]()
Рисунок 6. Панель метрики производительности из начальной версии с низкой кадровой скоростью.
Как видно на рисунке 6, горизонтальная строка, отмеченная как «Отрисовка», потребляла большую часть доступных циклов. При более подробном анализе выяснилось, что крайне много ресурсов расходовалось на отрисовку объектов на экране. После этого стало понятно, что сцена, состоящая из сотен тысяч полигонов (причем для каждого используется ресурсо-емкий шейдер фрагментов), резко снижает производительность. Но насколько именно? Добавив к шейдерам параметры MEDIUM и LOWEST, а также несколько ограничив «аппетит» отрисовки пикселей, нам удалось добиться шестикратного повышения производительности.
Чтобы определить, как на самом деле работают параметры LOWEST и MEDIUM, сначала нужно было определить «наименьший общий знаменатель» для компонентов игры. Определив, какие компоненты для игры совершенно необходимы, и убрав все остальное, я создал в шейдере новый параметр LOWEST. Были удалены почти все элементы: все тени, обычные карты, динамическое освещение, перекрытие текстур, зеркальное отображение и т. п. Поскольку я «обрубил все под корень», можно было запустить игру и понять, какой производительности можно добиться на Ultrabook в наилучшем для этого шейдера случае. Сравнив снимки экрана с параметром HIGHEST и с параметром LOWEST, я обнаружил самый важный отсутствующий компонент, который вызвал бы отрицательную реакцию пользователей при снижении качества графики. Шейдер содержал тени и перекрытия текстур. При отсутствии каждого из этих элементов качество изображения резко снижалось. Вернуть перекрытие текстур можно было без особых затрат. Чтобы протестировать, насколько больше ресурсов будет потреблять игра, я просто вернул код шейдера для этого элемента и снова запустил игру. С тенями все было гораздо сложнее: это касалось и их создания в другой части игрового движка, и их использования в самом шейдере. Учитывая важность этого аспекта для сохранения высокого качества изображения, я потратил достаточное количество времени на изучение различных подходов и наконец, обнаружил достаточно быстрое решение, которое я описываю ниже.
Создать параметр MEDIUM для шейдера было довольно просто: нужно было написать шейдер, промежуточный по качеству между самым высоким и самым низким качеством графики, но всегда склоняясь в пользу производительности. Цель этого параметра — достижение всех преимуществ по скорости, присущих параметру LOWEST, но с добавлением наименее ресурсоемких эффектов, таких как фонарик игрока, динамическое освещение и чуть более высокое качество теней.
Если бы я просто снизил качество всех графических элементов до минимума в режиме LOWEST, мне бы за один прием удалось добиться наибольшей производительности, но игроки относятся к плохой графике столь же отрицательно, как к плохой производительности. Я постарался сохранить 90 % качества изображения на самых высоких настройках и выделить элементы, которые можно было бы исключить или ограничить. Так мне удалось добиться значительного повышения скорости с минимальными потерями качества. С 5 кадров в секунду мне удалось перешагнуть за 40 — неплохое достижение.
Чтобы узнать, почему ваша игра для настольного ПК так медленно работает на Ultrabook, я настоятельно рекомендую разложить по полочкам весь ваш конвейер отрисовки графики и постараться понять, на что тратится время. Для этого можно использовать мой «хирурги-ческий» метод и удалять целые уровни функциональности до тех пор, пока не повысится скорость, или же применить более современный подход и задействовать средства анализа производительности. Какой бы метод вы ни выбрали, после обнаружения проблемы следующая задача — придумать такое решение, при котором возрастает скорость работы, но не снижается качество изображения.
Вот некоторые методики, которые я применил для устранения обнаруженных узких мест производительности.
Тени без затрат
Чтобы решить упомянутую выше проблему с тенями, мне пришлось найти альтернативные решения методики так называемых «каскадных карт теней». Я не стану подробно описывать эту методику, но дополнительные сведения о ней вы найдете здесь: http://msdn.microsoft.com/en-gb/library/windows/desktop/ee416307(v=vs.85).aspx. Работает она примерно так: в поле зрения камеры игрока немедленно рисуются четыре цели отрисовки с тенями всех объектов, каждая с разным уровнем детализации.
![]()
Рисунок 7. Каскадные карты теней — представление отладчика игрового движка.
Затем шейдер получает инструкции изменить цвет того или иного пикселя на экране на основании того, попадает ли этот пиксель в область предварительно вычисленной тени. Проблема в том, что это очень ресурсоемкий эффект шейдера, потребляющий много видеопамяти. Ниже приведен код шейдера фрагментов. Обратите внимание, что несколько раз используется ветвление IF, а производительность некоторых графических процессоров ощутимо падает для каждой новой ветви IF. В крайних случаях некоторые системы вычисляют все изменения каждого выходного пикселя, то есть ветвление кода не дает вообще никаких преимуществ.
fPercentLit = 0.0f;
if ( iCurrentCascadeIndex==0 )
{
fPercentLit += vShadowTexCoord.z > tex2D(DepthMap1,float2(vShadowTexCoord.x,vShadowTexCoord.y)).x ? 1.0f : 0.0f;
}
else
{
if ( iCurrentCascadeIndex==1 )
{
fPercentLit += vShadowTexCoord.z > tex2D(DepthMap2,float2(vShadowTexCoord.x,vShadowTexCoord.y)).x ? 1.0f : 0.0f;
}
else
{
if ( iCurrentCascadeIndex==2 )
{
fPercentLit += vShadowTexCoord.z > tex2D(DepthMap3,float2(vShadowTexCoord.x,vShadowTexCoord.y)).x ? 1.0f : 0.0f;
}
else
{
if ( iCurrentCascadeIndex==3 && vShadowTexCoord.z<1.0 )
{
fPercentLit += vShadowTexCoord.z > tex2D(DepthMap4,float2(vShadowTexCoord.x,vShadowTexCoord.y)).x ? 1.0f : 0.0f;
}
}
}
}
Необходимо снизить нагрузку на видеопамять и зависимость от ветвей IF. Решение (одно из возможных) — создать единую очень большую текстуру теней и поместить в эту цель отрисовки результаты самого низкого уровня детализации.
Я написал новую, менее ресурсоемкую методику, которая просто считывала данные из этой большой текстуры без всяких ветвлений. Особенности такого подхода выходят за рамки этой статьи, но общий смысл в том, что сначала нужно выявить причину снижения производительности, а затем придумать такое решение, которое работало бы быстрее, но давало бы изображение такого же качества.
Поддержание качества изображения
При оптимизации игрового движка необходимо следить за сохранением качества изображения на всех этапах разработки игры. Нетрудно просто вырезать все красивые, но ресурсоемкие эффекты ради прироста производительности, но лучше рассматривать каждую проблему как возможность повышения производительности с сохранением требуемого качества картинки. При этом вы не только добьетесь желаемых результатов, но и игра будет еще лучше работать на мощных компьютерах, что дает вам возможность добавлять новые компоненты и элементы при дальнейшем развитии игры.
![]()
Рисунок 8. Сравнение игровой сцены при чрезмерном снижении качества изображения.
Разрабатывая игру на настольном ПК, вы наверняка захотите использовать сложные шейдеры фрагментов для создания разнообразных эффектов поверхностей. Если просто удалить их из игры, изображение ухудшится настолько, что станет совсем не похоже на исходное. Для сохранения целостности игры важно поддерживать однородный визуальный стиль для всех методик работы шейдеров. Новые пользователи могут сначала впечатлиться великолепным снимком экрана в интернет-обзоре игры, но будут разочарованы, когда запустят вашу игру и увидят на экране что-то совсем иное.
Во всех возможных случаях старайтесь применять методики, воспроизводящие эффекты ресурсоемких шейдеров с меньшими затратами. Например, можно использовать заранее наложенные текстуры или применять ресурсоемкие пиксельные эффекты только в самой близкой к игроку области.
Уделяйте больше внимания своим близким.
Звучит как хороший жизненный совет, но это еще и неплохая стратегия для оптимизации шейдеров на Ultrabook. Одной инструкции ветвления IF достаточно, чтобы определить, насколько близко к игроку находится вычисляемый пиксель. Если близко, то можно, как и ранее, использовать ресурсоемкий эффект пиксельного шейдера, но если далеко, можно использовать намного менее затратную имитацию или заранее просчитанные эффекты.
![]()
Рисунок 9. Эффект смешения в действии: обратите внимание на эффекты карты нормалей вблизи.
Вместе с описанной выше методикой также можно использовать смешение, а если добавить одну дополнительную ветвь IF, можно проверять, на каком расстоянии между двумя точками удаления от игрока находится каждый пиксель. Вблизи игрока (ближе первой точки) можно использовать ресурсоемкие эффекты, а за пределами второй точки можно применять эффекты попроще. Между первой и второй точками следует вычислять смешанный эффект, промежуточный между первым и вторым подходами. Важно, чтобы расстояние между этими двумя точками было сравнительно небольшим, чтобы избежать удвоенного расхода вычислительных ресурсов. Расстояние смешения должно быть настолько большим, чтобы переход остался не замеченным игроком. В приведенном ниже фрагменте кода каждый пиксель обрабатывается в зависимости от его расстояния от камеры обзора: если расстояние составляет от 400 до 600 единиц, вычисляются обе ветви кода.
float4 lighting = float4(0,0,0,0);
float4 viewspacePos = mul(IN.WPos, View);
if ( viewspacePos.z < 600.0f )
{
// work out surface normal per pixel
lighting = lit(pow(0.5*(dot(Ln,Nb))+0.5,2),dot(Hn,Nb),24);
}
if ( viewspacePos.z > 400.0f )
{
// cheapest directional lighting
lighting = lerp ( lighting, cheaplighting, min((viewspacePos.z-400.0f)/200.0f,1.0f) );
}
Результат получается на удивление хороший, а переход очень плавный и совершенно незаметный при отрисовке. При этом в 90 % сцены теперь используется весьма экономный с точки зрения нагрузки эффект, поэтому скорость игры значительно повышается.
Обработка на лету и предварительная обработка
На оптимизацию игры было затрачено немало времени и усилий, но все равно скорость пока еще отставала от заветных 60 кадров в секунду. Баланс между качеством изображения и возможным повышением производительности был достигнут, но другие части игрового движка, помимо системы шейдеров, образовывали немалый объем вычислительных издержек и снижали скорость игры.
В игровом движке была внутренняя система оценки производительности, которая грубо измеряла каждый крупный сегмент всего конвейера отрисовки. В дополнение к графике, движок также измеряет ресурсы, затрачиваемые на вычисление искусственного интеллекта, физики, оружия, отладки, объемного света и т. п. Один из счетчиков следил за отрисовкой травы в реальном времени: такая методика использовалась в игре для формирования иллюзии бесконечного травяного поля. Снизив ресурсоемкость обработки графики, мы обнаружили, что относительная ресурсоемкость процесса отрисовки травы резко возросла и стала следующей по величине во всем конвейере. При оптимизации нужно всегда следить за такими пиками, а если обнаружится, что они используют слишком много игровых циклов, нужно повнимательнее их изучить. Следует знать, какой уровень потребления ресурсов для того или иного компонента графики является разумным, а какой — явно чрезмерным. В данном случае трава явно не должна была расходовать свыше 10 % всех циклов, особенно с учетом крайнего их дефицита. На настольном ПК это было не столь заметно, но на Ultrabook это существенно повлияло на скорость. Помимо роста потребления ресурсов было замечено, что при игре, всякий раз, когда перед игроком происходила отрисовка новой травы, кадровая скорость резко падала, поскольку пиковая нагрузка мешала обычному плавному выполнению игры.
![]()
Рисунок 10. Зеленая, зеленая трава: отрисовка травы в реальном времени может оказаться чрезвычайно ресурсоемкой.
Решение состояло в том, чтобы перенести всю систему отрисовки травы на этап предвари-тельной обработки, происходящий еще до запуска самой игры. Вместо формирования травы «на лету» ее просто переместили перед игроком, причем на глаз практически никакой разницы не было заметно. Теперь ничего не требовалось создавать на лету: траву нужно было всего лишь передвигать. Мой Ultrabook вздохнул с облегчением, поскольку удалось высвободить очень много драгоценных циклов CPU для всего остального игрового движка. Я, в свою очередь, тоже вздохнул с облегчением, поскольку удалось достичь волшебных 60 кадров в секунду, игра пошла с нужной скоростью.
Загадочное дело таинственной неравномерности
Добившись идеальной скорости игры и проехав через полмира, чтобы представить игру и ее движок на конференции, я обнаружил, что на демонстрационных устройствах игра работает неравно¬мерно: то и дело происходят рывки, игра словно спотыкается. На настольных компьютерах этих рывков не было, как не было их и на Ultrabook, который я использовал для тестирования. Рывки возникали только на этих устройствах, причем, что интересно, они были мощнее, чем те устройства, на которых я вполне успешно тестировал игру.
После длительных обсуждений и изучения эту проблему удалось связать с так называемым «разрешением внутреннего таймера». Коротко говоря, во всех играх, скорость действия в которых не зависит от компьютера (то есть, к примеру, персонажу игры нужно одинаковое количество времени, чтобы пробежать из точки А в точку Б вне зависимости от того, на каком компьютере запущена игра), так вот, во всех таких играх требуется доступ к команде GetTime(). Существует несколько команд этого семейства, но самой популярной является команда timeGetTime(), возвращающая количество миллисекунд с момента включения компьютера. При этом предполагается, что результат дается с разрешением в 1 миллисекунду, и действи¬тельно, на многих настольных компьютерах время передается именно с такой точностью. Оказывается, на Ultrabook и других мобильных устройствах, где во главу угла ставится экономия электроэнергии, это разрешение не фиксировано, оно может составлять не 1 миллисекунду, а 10—15. Если вы используете этот таймер для управления физикой в игре, как это было в нашем игровом движке, игра начнет «дергаться» и «спотыкаться» совершенно произвольным образом, поскольку вызовы обновления физики будут хаотично перепрыгивать с одного полученного времени к другому.
Причина перехода от разрешения в 1 мс к 10—15 мс в том, что некоторые системы могут сократить потребление электроэнергии, снизив частоту работы процессора, а из-за этого и частота тактовых импульсов может непредсказуемо измениться. Для этой проблемы существует несколько решений. Мы рекомендуем использовать команду QueryPerformanceTimer(), гарантирующую точность возвращаемого значения времени за счет второй команды, возвращающей частоту работы таймера.
5. Подсказки и советы
Что нужно сделать
- Дополняйте шейдеры добавочными технологиями, а не заменяйте их при оптимизации для Ultrabook. Ваша игра должна работать и на настольных компьютерах, и на Ultrabook; процесс распространения игры намного проще, если вся игра упакована в один двоичный файл. Шейдеры DirectX* и OpenGL* позволяют создавать разные технологии в рамках одного шейдера. Поскольку ваша игра содержит все необходимое, код игры может определять, на какой платформе игра запущена в данный момент, и выбирать оптимальную процедуру отрисовки, которая на этой платформе даст наибольшую скорость и наивысшее возможное качество.
- Предложите пользователям экран настроек, где можно выбрать нужный уровень производительности и качества. В подавляющем большинстве случаев компьютерные игроки рассчитывают на наличие таких настроек. Всегда хорошо определять и заранее устанавливать настройки, оптимальные для данной конкретной системы, но у пользователя должна быть возможность изменять эти настройки; кроме того, выбранные вами настройки по умолчанию должны всегда быть работоспособными в системе пользователя.
Чего не стоит делать
- Не исходите из того, что ваша игра обязана работать со скоростью 60 кадров в секунду. На большинстве современных устройств можно настроить интервал обновления экрана, чтобы пропускать один или даже три сигнала вертикальной развертки: при этом сохранится нужная плавность игры, но при скорости в 30 кадров в секунду. Разумеется, все будет не настолько чудесно, как при 60 кадрах в секунду, но если правильно отрегули¬ровать синхронизацию, игра все же будет восприниматься очень хорошо.
- При разработке игры не следует недооценивать ресурсоемкость шейдеров фрагментов, особенно если предполагается использовать не самое мощное графическое оборудование. Если скорость игры недопустимо низка, откажитесь от использования шейдеров или ограничьте их использование, действуя методом исключения.
- Не следует заранее выбирать разрешение экрана вместо пользователя: выбранное вами разрешение может не поддерживаться экраном устройства. Используйте API Windows* API для опроса устройства и получения совместимого разрешения по умолчанию.
- • Не полагайтесь на то, что timeGetTime() возвращает время с интервалами в 1 милли-секунду. На Ultrabook при включенных технологиях экономии электроэнергии интервалы могут составлять 10—15 мс!
6. Краткие советы по работе с Ultrabook
Дальнейший текст может показаться цитированием очевидного, но тем не менее: предлагаю краткое и полезное руководство по тестированию, запуску и демонстрации ваших игр и трехмерных приложений на Ultrabook.
Экономия электроэнергии
При демонстрации для большой аудитории, если вы хотите показать свою игру в лучшем виде, обязательно подключите Ultrabook к электросети. Не работайте от аккумулятора: для экономии электроэнергии система будет ограничивать производительность оборудования, тогда как вам требуется полная мощность.
![]()
Рисунок 11. Управление электропитанием на Ultrabook.
На всякий случай найдите «Управление электропитанием» на панели управления и убедитесь, что при питании компьютера от сети все меры экономии электроэнергии отключены, а все возможные параметры установлены на максимум.
Графика
На панели управления есть еще один раздел, где вы можете управлять ускорением графичес-кого адаптера устройства. Вы найдете параметры, отвечающие за работу GPU и драйвера в режиме экономии электроэнергии. Нужно выбрать режим наибольшей производительности (или эквивалентный ему), чтобы гарантировать наиболее быструю работу графического процессора.
![]()
Рисунок 12. :Параметры ускорения обработки графики на Ultrabook™
Необходимость таких действий может вызвать недоумение, но помните, что во главу угла при разработке Ultrabook ставится экономия электроэнергии везде и всегда, где это возможно, что позволяет таким устройствам подолгу работать без подзарядки. Самый простой и действен¬ный способ достижения максимальной производительности Ultrabook — включить его в розетку и выставить все настройки на максимум.
Фоновые задачи
Опытные разработчики, да и опытные пользователи согласятся с этим простым, но эффектив-ным советом: нужно посмотреть, какие фоновые задачи запускаются на Ultrabook при загрузке Windows. Предполагалось, что фоновые программы будут полезными, и при этом не будут потреблять слишком много ресурсов, но когда их много, они имеют нехорошую тенденцию довольно серьезно загружать CPU.
Сколь бы важными ни были эти задачи, когда вы демонстрируете, насколько быстро ваша трехмерная игра может работать на Ultrabook, разумно отключить вообще все задачи, которые не нужны непосредственно для этой цели. За фоновые задачи не беспокойтесь, при следующей загрузке Ultrabook они снова появятся, но зато сейчас в течение всего оставшегося сеанса Windows все ресурсы устройства будут предоставлены одному-единственному приложению — вашему!
7. Выводы
Тема оптимизации игр весьма обширна. Разработчики должны рассматривать оптимизацию как неотъемлемую часть своей повседневной работы. Цель в том, чтобы вашу игру можно было запускать на как можно более широком наборе оборудования. Для достижения этой цели потребуется весь ваш опыт, все знания и умения. Применяя такие средства Intel®, как VTune™ Analyzer и Intel Graphics Performance Analyzers, можно ускорить решение этой задачи. Статьи, подобные этой, подскажут возможные решения, но в конечном итоге все зависит от вашей сообразительности. Как можно добиться этого же результата другим способом? Можно ли сделать это быстрее? Можно ли сделать это умнее? Вот с таких вопросов следует начинать, и чем чаще вы станете их задавать, тем эффективнее сможете оптимизировать свои игры и приложения. Как я предположил в начале этой статьи, вы не только станете выпускать более качественный код, но и расширите свои позиции на стремительно растущем рынке!
Другие материалы по теме
Codemasters GRID 2* on 4th Generation Intel® Core™ Processors - Game development case study
Not built in a day - lessons learned on Total War: ROME II
Developer's Guide for Intel® Processor Graphics for 4th Generation Intel® Core™ Processors
PERCEPTUAL COMPUTING: Augmenting the FPS Experience
Об авторе
Во время, свободное от написания статей, Ли Бэмбер руководит британской компанией The Game Creators (http://www.thegamecreators.com)), которая специализируется на разработке и распространении средств создания компьютерных игр. Эта компания ведет свою историю с 1999 года. Среди плодов работы этой компании вместе с окружающим ее разработчиком игр — множество популярных брендов, в том числе Dark Basic, FPS Creator, а также App Game Kit (AGK). Ли также ведет хронику своей повседневной работы разработчика вместе со снимками экрана и видеороликами: http://fpscreloaded.blogspot.co.uk
Intel®Developer Zone offers tools and how-to information for cross-platform app development, platform and technology information, code samples, and peer expertise to help developers innovate and succeed. Join our communities for the Internet of Things, Android*, Intel® RealSense™ Technology and Windows* to download tools, access dev kits, share ideas with like-minded developers, and participate in hackathons, contests, roadshows, and local events.
Any software source code reprinted in this document is furnished under a software license and may only be used or copied in accordance with the terms of that license.
Intel, the Intel logo, Ultrabook, and VTune are trademarks of Intel Corporation in the U.S. and/or other countries.
Copyright © 2014 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others.
button corresponding to the target you want to build. The Intel XDK uploads your project files to your account on the Intel XDK build server. Once there, the build server may request additional information to complete the build process. Always review the Build log - if needed, fix app settings in the Projects tab and rebuild your app.
Рисунок 1. Топология с использованием одного монитора. Видео с камеры MJPEG отображается в правом нижнем углу. Обработанное видео отображается во весь экран. При включении режима использования нескольких мониторов (например, в режиме Miracast) программа обнаруживает данное изменение, в результате чего видео с камеры MJPEG и обработанное видео автоматически выводятся на разные мониторы.
