Обратная совместимость для консолей и не сильно нужна, если честно. По крайней мере, эти возможности не пользуются большой популярностью и в многочисленных комментариях, которые я читал, жалоб именно на это я не видел. Лишнее подтверждение тому и отношение к эмуляции со стороны Microsoft и Sony в текущем поколении — им вообще плевать на нее было. МС свой эмулятор практически забросила поддерживать, sony вообще вырезала эту возможность в начале поколения. И это для Sony с ее огромной библиотекой пс2 игр.
Непонятно зачем это делать, когда все писали под LibGCM. Ну и как я уже писал выше, в презентации о killzone 4 есть слова о контроле командных буферов, в чем и есть вся суть LibGCM. В любом случае, будет только хуже, как по мне. Первое, переход на другую библиотеку. Второе, лишние накладные расходы API и меньший контроль над железом. Они конечно могут расширить OpenGL для этого, но зачем, когда уже есть LibGCM.
Пока я не ошибаюсь, а говорю то, что есть сейчас. ПК рынок не является приоритетным, консоли как были так и есть главный и самый прибыльный рынок. Изменится ли что-то в будущем — посмотрим. По крайней мере, эксклюзивы консолей пока никуда деваться не собираются.
А что до манипуляторов, то это кому как. Я использую контроллер xbox 360 на ПК во всех играх, где это возможно. В шутерах в том числе.
Писать чисто под Windows ничто не мешает, если я правильно вас понял. Но такой вариант я даже не рассматриваю — делать ПК эксклюзив сегодня мягко говоря странная затея. Основной и самый прибыльный рынок — это консоли, а там OpenGL нет.
Но какое это имеешь отношение к vendor-specific расширениям? Даже если речь о ПК эксклюзиве на OpenGL эти расширения все равно непригодны для реальных проектов именно из-за поддержки лишь одним вендором. Ладно, если бы была речь о каком-то хитро алгоритме фильтрации — такие вендорные фичи раньше успешно использовались. Здесь же речь о технологии, которая не только сильно скажется на архитектуре движка, так еще и на всем цикле разработки ресурсов. Нужны специальные инструменты для работы с такими текстурами, нужно специально готовить такие текстуры. Можно с уверенностью сказать, что это никому не нужно.
Dx сильно изменился именно к 10 версии и более не меняется существенно. Изменения эти существенны, но с ними библиотека стала намного более удобной для разработки. Поэтому записывать это в минусы мягко говоря странно. Тем более когда dx9 уже в стадии отмирания и все больше игр просто не поддерживают его.
OpenGL нет на консолях, главном игровом рынке, а значит о нем можно сразу забыть. Есть DirectX для Windows и xbox. Есть LibGCM для playstation. Все, ты готов, чтобы покрыть всю рынки, которые имеет смысл покрыть. Это первая и самая главная причина, чтобы не использовать OpenGL вообще.
Вторая, плохая поддержка со стороны драйверов на том же Windows. Багов тонны что у nvidia, что у AMD. Есть уверенность, что таких проблем полно и на других ОС. А раз на Windows лучше все таки остаться на DirectX, то почему бы не плюнуть на OpenGL вообще, когда он принесет с собой лишь поддержку, по сути, мертвых (не родившихся) игровых платформ — linux и mac os. Консоли то отпадают.
Даже если и было, то было на праве расширения одного из вендоров, что скорее их заслуга, а не OpenGL. Это значит, что в продакшн шансов у него попасть ровно ноль. Скорее как баловство для техдемок, как у той же nvidia. Если фича появляется в DirectX, то это означает автоматическую поддержку всем спектром совместимого железа, которое неизбежно появится, а значит все это рано или поздно попадет в игры. Так что, в OpenGL может быть много чего, но пока этого нет в DirectX пользы никакой не будет.
Кому нужны мобильные платформы, когда речь о проектах ААА класса? Там таких игр нет и вряд ли когда-то будут. Мало того, что по производительности мобильники безнадежно отстают даже от консолей xbox 360 и ps3, которым уже 8 лет. Так механика, которая пригодна для консолей, совершенно не пригодна для мобильных платформ. Поэтому о портировании можно вообще забыть, а разработка по сути нового проекта лишь по мотивам полноценного (как сейчас и делается) — это уже совсем другая тема. Поэтому на сегодня и получается, что удел OpenGL это мобильные игры. А все остальное это либо DirectX, либо какие-то свои библиотеки.
Даже на пс3 использовался LibGCM, а не OpenGL. Последний в консольных реалиях мало на что пригоден. Тот же DirectX на боксе это совсем не то, что на ПК можно увидеть. Консоли обязывают иметь как можно более низкоуровневый доступ к железу и LibGCM на пару с кастомным DirectX позволяют это делать. Для разработки чего-то серьезного OpenGL на пс3 даже в расчет не берется. Более того, на пс3 OpenGL был всего лишь оберткой над LibGCM. И нет ниодной причины, что на пс4 что-то по-другому. Наоборот, в презентации killzone 4 есть упоминания ручного контроля командных буферов, для чего LibGCM и создана.
Так что в итоге получается, для полноценных платформ есть DirectX, который покроет сразу ПК и Xbox. И есть LibGCM, который покроет playstation. OpenGL места тут не остается. Как бонус его можно получить разве что с некоторыми движками с мультирендерами, а писать свой велосипед, тем более чисто консольный — тут лучше обойтись DirectX и LibGCM.
Крутиться она то будет через HyperV, но низкий уровень доступа к железу это не отменяет — про это прямым текстом говорили. На xbox 360 DirectX позволял самому формировать командные буферы, записывать константы. Некоторые умудрялись вообще не использовать DirectX, а писали свое API чисто для работы с командным буфером без DirectX. Давало это впечатляющие результаты.
В таком случае даже наличие знакомой системы драйверов вряд ли чем поможет. Доступ железу намного ниже, нежели на ПК. Сами железки довольно существенно отличаются — общее адресное пространство, кеш в виде ESRAM и блоки Move Engines для пересылки данных между RAM и ESRAM. Сам GPU явно не просто с полки ПК комплектующих взят. Зная возможности xbox 360, доступ ко всем этим видам памяти возможен напрямую, а на Xbox one возможно использовать Move Engines, чтобы работа с ESRAM проходила полностью прозрачно. Так что есть вполне обоснованная уверенность, что по крайней мере Xbox OS просто так не «взлетит» и писать эмулятор по крайней мере подсистемы памяти придется.
Там будет ядро Win8, а не сам Windows 8. Возможно туда еще переехала часть подсистем, но явно совсем не в том виде, в котором они в настольной ОС. И ядро, и подсистемы скорее всего будут очень сильно переработаны. В том же Xbox 360 от былого Windows осталось довольно мало.
Более того, в боксе две ОС. На ядре Win8 крутится все, что не связано с играми. Для игр есть другая ОС. На каком она ядре не говорили, но там явно будет еще меньше общего с Windows 8.
OpenGL там не используется, по крайней мере написать что-то более менее вменяемое с ним не получится. Там своя библиотека LibGCM, которая работает на более низком уровне, нежели OpenGL. Прямой доступ к командным буферам GPU обычное дело, что на боксе, что на пс3. Пс4 не станет исключением.
Вы пытаетесь сравнивать совершенно разные вещи. Unity является игровым фреймворком. Не просто движок, это фреймворк, что подразумевает огромный инструментарий. Он конкурирует с такими вещами как UDK — это тоже фреймворк, в основе которого лежит Unreal Engine.
XNA является банальной managed оберткой над низкоуровневым DirectX. Все. Это никакой не фреймворк. Это даже не движок, даже близко не является движком.
А XNA тоже кроссплатформенный, по крайней мере среди платформ МС. ПК, мобилки, планшеты, xbox 360 — все это понимает XNA.
Морщины можно сделать блендингом карт нормалей или вообще их процедурной генерацией:
— В документации CryEngine 3 есть намеки на что-то подобное sdk.crydev.net/display/SDKDOC21/HumanSkin+Shader
— Вот пейпер о процедурной генерации карт нормалей в реальном времени wscg.zcu.cz/wscg2008/papers_2008/short/b71-full.pdf Методов полно, здесь явно тоже самое. Довольно глупо было бы тратить столько полигонов на одни морщины.
Доказательство можно видеть на 1:29 — если смотреть направо, на дальний глаз, то отчетливо видно две вещи:
1. Геометрия довольно проста, проглядываются грани полигонов.
2. Морщины под глазами сделаны не геометрией. Похоже на normal mapping, а может чего по-интереснее реализовали. Но что это не геометрия это видно явно.
В блоге автора написано, что рендерилось это на GTX680 при 180 fps. Не надо путать с недавним демо Nvidia, которой как раз крутилось на титане и, честно говоря, выглядит хуже.
Судя по такой производительности и сетке головы, это самый что ни на есть игровой персонаж и консоли следующего поколения вполне к этому готовы.
Я проводил небольшое исследование. Как я понял, она не ставит взломанные приложения. Все приложения были легально куплены в AppStore. Если посмотреть ipa пакеты, то все приложения подписаны Apple и куплены с одного AppleID. Задача программы лишь в передаче девайсу данных этого AppleID. Это так же подтверждает тот факт, что все бинарники шифрованы (взломанные приложения всегда расшифрованы) и при необходимости просят ввести тот самый AppleID. Именно поэтому нельзя установить через китайскую программу крякнутые ipa — iOS отказывается их устанавливать, потому что у них недействительная цифровая подпись.
Говоря о том, что сэмплы генерируются с с тем же темпом, что и процессор, я имел ввиду следующее. Я завел счетчик с периодом в тактах, равным 4194304/{частота дискретизации}, т.е. частота процессора деленная на частоту дискретизации. Он так же как и все остальные компоненты синхронизирован с процессором. Каждый его отсчет генерирует два сэмпла — для левого и правого уха. Звуковые каналы в процессе работы хранят свое выходное значение амплитуды — его я и забираю при каждом отсчете. Таким образом сэмплы накапливаются в буфер сэмплов, который потом вставляется в кольцевой буфер. Оттуда SDL забирает их на воспроизведение.
По сути, получается довольно грубая передискретизация (resampling).
Эмулятор при запуске просит ROM файл. Мне не очень хочется включать нелегальные ROM файлы игр в архив с эмулятором или давать ссылки на них здесь. При желании все находится в два счета.
Да, в предыдущей статье ссылка на готовый эмулятор. В репозитории Cookieboy лежат исходники и сборка готового эмулятора. Ссылку на репозиторий я продублировал в этой статье в самом начале.
А что до манипуляторов, то это кому как. Я использую контроллер xbox 360 на ПК во всех играх, где это возможно. В шутерах в том числе.
Но какое это имеешь отношение к vendor-specific расширениям? Даже если речь о ПК эксклюзиве на OpenGL эти расширения все равно непригодны для реальных проектов именно из-за поддержки лишь одним вендором. Ладно, если бы была речь о каком-то хитро алгоритме фильтрации — такие вендорные фичи раньше успешно использовались. Здесь же речь о технологии, которая не только сильно скажется на архитектуре движка, так еще и на всем цикле разработки ресурсов. Нужны специальные инструменты для работы с такими текстурами, нужно специально готовить такие текстуры. Можно с уверенностью сказать, что это никому не нужно.
OpenGL нет на консолях, главном игровом рынке, а значит о нем можно сразу забыть. Есть DirectX для Windows и xbox. Есть LibGCM для playstation. Все, ты готов, чтобы покрыть всю рынки, которые имеет смысл покрыть. Это первая и самая главная причина, чтобы не использовать OpenGL вообще.
Вторая, плохая поддержка со стороны драйверов на том же Windows. Багов тонны что у nvidia, что у AMD. Есть уверенность, что таких проблем полно и на других ОС. А раз на Windows лучше все таки остаться на DirectX, то почему бы не плюнуть на OpenGL вообще, когда он принесет с собой лишь поддержку, по сути, мертвых (не родившихся) игровых платформ — linux и mac os. Консоли то отпадают.
Так что в итоге получается, для полноценных платформ есть DirectX, который покроет сразу ПК и Xbox. И есть LibGCM, который покроет playstation. OpenGL места тут не остается. Как бонус его можно получить разве что с некоторыми движками с мультирендерами, а писать свой велосипед, тем более чисто консольный — тут лучше обойтись DirectX и LibGCM.
В таком случае даже наличие знакомой системы драйверов вряд ли чем поможет. Доступ железу намного ниже, нежели на ПК. Сами железки довольно существенно отличаются — общее адресное пространство, кеш в виде ESRAM и блоки Move Engines для пересылки данных между RAM и ESRAM. Сам GPU явно не просто с полки ПК комплектующих взят. Зная возможности xbox 360, доступ ко всем этим видам памяти возможен напрямую, а на Xbox one возможно использовать Move Engines, чтобы работа с ESRAM проходила полностью прозрачно. Так что есть вполне обоснованная уверенность, что по крайней мере Xbox OS просто так не «взлетит» и писать эмулятор по крайней мере подсистемы памяти придется.
Там будет ядро Win8, а не сам Windows 8. Возможно туда еще переехала часть подсистем, но явно совсем не в том виде, в котором они в настольной ОС. И ядро, и подсистемы скорее всего будут очень сильно переработаны. В том же Xbox 360 от былого Windows осталось довольно мало.
Более того, в боксе две ОС. На ядре Win8 крутится все, что не связано с играми. Для игр есть другая ОС. На каком она ядре не говорили, но там явно будет еще меньше общего с Windows 8.
XNA является банальной managed оберткой над низкоуровневым DirectX. Все. Это никакой не фреймворк. Это даже не движок, даже близко не является движком.
А XNA тоже кроссплатформенный, по крайней мере среди платформ МС. ПК, мобилки, планшеты, xbox 360 — все это понимает XNA.
— В документации CryEngine 3 есть намеки на что-то подобное sdk.crydev.net/display/SDKDOC21/HumanSkin+Shader
— Вот пейпер о процедурной генерации карт нормалей в реальном времени wscg.zcu.cz/wscg2008/papers_2008/short/b71-full.pdf Методов полно, здесь явно тоже самое. Довольно глупо было бы тратить столько полигонов на одни морщины.
Доказательство можно видеть на 1:29 — если смотреть направо, на дальний глаз, то отчетливо видно две вещи:
1. Геометрия довольно проста, проглядываются грани полигонов.
2. Морщины под глазами сделаны не геометрией. Похоже на normal mapping, а может чего по-интереснее реализовали. Но что это не геометрия это видно явно.
Судя по такой производительности и сетке головы, это самый что ни на есть игровой персонаж и консоли следующего поколения вполне к этому готовы.
Говоря о том, что сэмплы генерируются с с тем же темпом, что и процессор, я имел ввиду следующее. Я завел счетчик с периодом в тактах, равным 4194304/{частота дискретизации}, т.е. частота процессора деленная на частоту дискретизации. Он так же как и все остальные компоненты синхронизирован с процессором. Каждый его отсчет генерирует два сэмпла — для левого и правого уха. Звуковые каналы в процессе работы хранят свое выходное значение амплитуды — его я и забираю при каждом отсчете. Таким образом сэмплы накапливаются в буфер сэмплов, который потом вставляется в кольцевой буфер. Оттуда SDL забирает их на воспроизведение.
По сути, получается довольно грубая передискретизация (resampling).