Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 112
Хороший перевод! Хоть я и не писал графические приложения, было очень интересно читать.
Вопрос к знатокам: У ARB был шанс реабилитироваться с выходом OpenGL ES 2.0 и OpenGL 4.0. Получилось или не очень?
Я не припомню момента, когда OpenGL жил в играх. История игр — это история DirectX. А так, да, оба живы. С трудом представляю себе какую-нибудь САПР, на директе. Мне кажется, сравнение не совсем корректное. OpenGL — это чисто графическая библиотека, а DirectX — это комбайн технологий для ИГР.
Homeworld. Ради него мне пришлось поставить OpenGL.
Это исключение. Можно назвать еще несколько игр. Можно вспомнить, что некоторые игры поддерживают обе библиотеки. Но тем не менее, это исключение.
поставить OpenGL
что?
Раньше существовали отдельно OpenGL драйвера для видеокарт.
Помню что Serious Sam, еще первый, не запускался если не стояли драйвера OpenGL.
Помню что Serious Sam, еще первый, не запускался если не стояли драйвера OpenGL.
MS не включила его в W2k.
Простите, но это не правда. О чём, собственно, и написано по ссылке. M$ подумывали вообще исключить OpenGL (со временем), потому что тогда участвовали в проекте Farenheit, который должен был создать более продвинутое API на замену OpenGL и Direct3D.
В связи с этим они перенесли в Win2k политику Win98: Все драйверы, идущие вместе с операционной системой, если поддерживают 3D ускорение, то только для Direct3D, аппаратную поддержку OpenGL производитель должен делать сам (если захочет). Поскольку в Win9x так и было, а в NT4 вообще не было родного аппаратного 3D ускорения (только с драйверами и только OpenGL), то для пользователей не изменилось ровным счётом ничего.
Потом подобные страшилки были во времена Vista, когда все кричали «а-а-а-а! M$ выкидывает OpenGL!!!1111» А оказалось, что лишь обновили свою програмную реализацию с 1.1 до 1.4. Хотя вряд ли кто-то сможет ответить — на фига… Ни то, ни то в тот момент было абсолютно никому не интересно. Да ещё и в програмном варианте.
В связи с этим они перенесли в Win2k политику Win98: Все драйверы, идущие вместе с операционной системой, если поддерживают 3D ускорение, то только для Direct3D, аппаратную поддержку OpenGL производитель должен делать сам (если захочет). Поскольку в Win9x так и было, а в NT4 вообще не было родного аппаратного 3D ускорения (только с драйверами и только OpenGL), то для пользователей не изменилось ровным счётом ничего.
Потом подобные страшилки были во времена Vista, когда все кричали «а-а-а-а! M$ выкидывает OpenGL!!!1111» А оказалось, что лишь обновили свою програмную реализацию с 1.1 до 1.4. Хотя вряд ли кто-то сможет ответить — на фига… Ни то, ни то в тот момент было абсолютно никому не интересно. Да ещё и в програмном варианте.
Кстати, в 8+ уже программная поддержка на уровне 2.0, текстуры до 1024x1024 и даже есть поддержка S3TC. При чем, я подозреваю, что там не сугубо программно все, а враппер над DirectX — уж слишком хорошо работает. Если бы не прибитый гвоздями размер текстур, уже бы работали некоторые 3D пакеты и разумного уровня игры из коробки.
Это все создает видимость, что OpenGL в системе есть и работает, некоторый софт пытается запуститься и падает в середине, а не сразу при запуске. И почти ни одна программа не может толком сообщить, что именно оказалось поломано.
Это все создает видимость, что OpenGL в системе есть и работает, некоторый софт пытается запуститься и падает в середине, а не сразу при запуске. И почти ни одна программа не может толком сообщить, что именно оказалось поломано.
Autodesk Inventor на DirectX
Новый Doom. Насчет других не знаю. Warzone 2100 (специфическая вещь), да и тот же Minecraft.
Практически все игры на движках от id Software, а их не мало, работали через OpenGL.
Quake 3 и игры на его движке, по моему уже о многом говорит.
Unreal был мультидвижковый.
Half-Life лично у меня в OpenGL шёл в разы лучше.
Unreal был мультидвижковый.
Half-Life лично у меня в OpenGL шёл в разы лучше.
Я специально залез на вики, когда читал статью и нашел вот такой лист игр. Причем там не только «старые», но и новые игры. И к тому есть игры, которые запускаются под Windows. Как пример:
Wolfenstein: The Old Blood
Wolfenstein: The New Order
Spore
Amnesia: A Machine for Pigs
Amnesia: The Dark Descent
Так что и крупные проекты на нем разрабатывают.
Wolfenstein: The Old Blood
Wolfenstein: The New Order
Spore
Amnesia: A Machine for Pigs
Amnesia: The Dark Descent
Так что и крупные проекты на нем разрабатывают.
Прекрасно. А теперь делаем точно такой же список игр под DirectX. Подозреваю, что получим нечто в десятки раз более объемное ;) О чем и была речь. Более того, DirectX <> Direct3D. В нем куча подсистем, аналогов которого у
OpenGL в принципе нет. DirectSound, DirectPlay — это как минимум.
OpenGL в принципе нет. DirectSound, DirectPlay — это как минимум.
Ну дык и
И говорить только из-за этого, что линух для геймдева мертв как-то некорректно.
и под линух игорь нет
И говорить только из-за этого, что линух для геймдева мертв как-то некорректно.
А как же Android?
а что андроид? что там, что, подозреваю, на яблоках, на чернике и вообще всем кроме винфона(или там тоже?) бал правит Open GL _ES_. но опять же, даже топовые смартфоны, кмк, как раз болтаются в плане производительности на том уровне, когда «большой» опенгл еще был «жив».
Ну андроид — это совсем свежая история. Описанные события — про царство винды
Здрасьте, приехали!!! Несметное колличество игр на OpenGL!!! — это все игры id Software — думы, квейки, вольфенштейны new order, rage — и игры сторонних разработчиков, которые купили движки id Tech 3, 4, 5 (Brink, Prey, Star Wars Jedi Knight II, Medal of Honor: Allied Assault, Dishonored 2, The Evil Within и др.). А теперь будут игры на id Tech 6
сразу видно вы игрок ещё тот!
сразу видно вы игрок ещё тот!
KSP гораздо лучше ведет себя на OpenGL — практически без ущерба для графония (он там кстати и так не самый крутой, но все же!!) отжираемые ресурсы падают в 1,5-2,5 раза!
Ну сами посудите, на максимуме настроек на дирХ он жрет ~350Мб видеопамяти и (в ангаре с кораблем на 60 деталей), а на опенГЛ — всего 225 при тех же условиях и в том же ангаре. Я уж не говорю, что на опенГЛ существенно снижается потребность в оперативе для ресурсов и игра позволяет строить крафты на 160-200 деталей без лагов и регулярных вылетов, тогда как на дирХе — только 70-100 деталей максимум и начинается слайдшоу…
Ну сами посудите, на максимуме настроек на дирХ он жрет ~350Мб видеопамяти и (в ангаре с кораблем на 60 деталей), а на опенГЛ — всего 225 при тех же условиях и в том же ангаре. Я уж не говорю, что на опенГЛ существенно снижается потребность в оперативе для ресурсов и игра позволяет строить крафты на 160-200 деталей без лагов и регулярных вылетов, тогда как на дирХе — только 70-100 деталей максимум и начинается слайдшоу…
И все же основная нагрузка в KSP идет не на видеокарту или оперативу(если быть честным, оперативу там жрут не детальки, а моды, т.к. игра загружает их целиком в оперативку и держит там всё время, даже когда они не используются), а на процессор т.к. вся сложная физика в игре просчитывается именно на нём. То, что вы описываете, актуально для совсем уж древних сборок с малым количеством оперативы и видеопамяти.
я так считаю, что мое железо прямо древним назвать нельзя — 8гб оперативной памяти, ксеон 5440 в разгоне (3.22ГГц), гтс450. Да, это не топовая железяка за пару тысяч у.е., но так и игра имеет весьма скромный графоний, который до уровня кукурузисов не дотягивает и близко, тем более — с учетом относительно невысокого разрешения (1400х1050р). Во всяком случае, более тяжелые игрульки этот системник пока еще вполне тянет.
Затык именно в том, что у меня версия 1.0.4 х86 и всего с тремя модами — ну, на данный момент, коненчо (хеви рокетс, реалсолар и аттачсистментс) и она оперативы более 3Гб не умеет адресовать. Это влечет за собой крэши регулярные. Использование библиотек опенГЛ, как ни странно, снижает запросы по оперативке, очевидно — благодаря оптимизации текстур, которые так или иначе обрабатывает процессор.
Затык именно в том, что у меня версия 1.0.4 х86 и всего с тремя модами — ну, на данный момент, коненчо (хеви рокетс, реалсолар и аттачсистментс) и она оперативы более 3Гб не умеет адресовать. Это влечет за собой крэши регулярные. Использование библиотек опенГЛ, как ни странно, снижает запросы по оперативке, очевидно — благодаря оптимизации текстур, которые так или иначе обрабатывает процессор.
«Я не припомню момента, когда OpenGL жил в играх.» — вы забываете про мобильники. В iOS и Android, до выхода Metal и Vulkan, безраздельно правил OpenGL ES. Да и сейчас ситуация не сильно изменилась.
Статья описывает те времена, когда из игровых платформ самой популярной была винда. На ней подавляющее большинство игр были директовыми. Да, Опенгл поддерживала куча игр, да были даже чисто опенглные игры, что не противоречит тому, что самая часто используемая библиотека — директ. Сейчас ситуация меняется коренным образом. Тут и мобильные платформы, тут и стим и другие. И я не за директ и не за опенгл. Я — за разнообразие. Больше библиотек — лучше программистам.
Он умер и воскрес…
Нужно быть очень хорошим кодером чтобы разобраться во всем этом зоопарке API и одновременно разрабатывать проект.
Нужно быть хорошим ПРОГРАММИСТОМ. Хороший программист примерно за 14 дней разберется в любом API.
Ок, давайте перенесем вас на 15 лет назад дадим железки тех времён и посмотрим что вы будете делать. Поддержка первых видеокарт, поддержка софверного рендера, поддержка экзотических API и т.д. И что бы все это работало.
Не верю, что за 14 дней можно изучить все «особенности» любого API. Скажем, в документации к API будет сказано, что для вывода точки красного цвета, надо вызывать функцию API «putPixel(x, y, z, color.RED)». Программист на 15-й день так и пишет в коде. Точка выводится зеленым цветом. Двое суток отладки, чтения форумов, блогов и исходников (если они вообще есть). Выясняется, что если инициализация была выполнена в отладочном режиме, то color.RED заменяется на color.GREEN.
Ну, надуманный пример, но каждый, кто работал с библиотеками, знает, что все они полны подводных камней. Помню, в 90-х года еще было принято среди некоторых личностей, в том числе, очень известных разработчиков, все писать самостоятельно с нуля, включая, там, какой-нибудь парсер модного тогда XML. Потому что порой стоимость поиска и обхода ошибок в чужих библиотеках и API была намного выше.
Ну, надуманный пример, но каждый, кто работал с библиотеками, знает, что все они полны подводных камней. Помню, в 90-х года еще было принято среди некоторых личностей, в том числе, очень известных разработчиков, все писать самостоятельно с нуля, включая, там, какой-нибудь парсер модного тогда XML. Потому что порой стоимость поиска и обхода ошибок в чужих библиотеках и API была намного выше.
Не верю, что за 14 дней можно изучить все «особенности» любого API.
Все — нельзя. Разобраться и начать работать — можно.
Скажем, в документации к API будет сказано, что для вывода точки красного цвета, надо вызывать функцию API «putPixel(x, y, z, color.RED)». Программист на 15-й день так и пишет в коде. Точка выводится зеленым цветом. Двое суток отладки, чтения форумов, блогов и исходников (если они вообще есть). Выясняется, что если инициализация была выполнена в отладочном режиме, то color.RED заменяется на color.GREEN.
Пример как раз про КОДЕРА, а не про ПРОГРАММИСТА. Двое суток отладки на такую херню — явный перебор. Но дело не в этом. Дело в том, что тонкости и подводные камни не мешают писать код. И досконально некоторые библиотеки можно изучать и год и два. Однако ПРОГРАММИСТ за 14 дней способен разобраться и в чужом коде и в новой для него библиотеке и т. д. И сможет эффективно работать.
Помню, в 90-х года еще было принято среди некоторых личностей, в том числе, очень известных разработчиков, все писать самостоятельно с нуля, включая, там, какой-нибудь парсер модного тогда XML. Потому что порой стоимость поиска и обхода ошибок в чужих библиотеках и API была намного выше.
Сейчас такой подход тоже популярен. Только дело не в стоимости поиска чужих ошибок, а, зачастую, в криворукости. Хотя да, в ряде случаев проще самому написать парсер xml. Особенно, если не используется ни валидация, ни трансформация, ни еще какие-то новомодные штуки. Дело еще и в том, что ради какой-нибудь минорной функции тащить в проект целый фреймворк — это тоже не комильфо. Ну и плюс не все фреймворки одинаково полезны.
Жалко, что автор не упомянул, как MS беспардонно выдавливает OpenGL последние годы со своих систем — ограниченные или вообще отсутствующие драйвера по-умолчанию, существенно заниженная производительность и т.д. Буквально, кросс-платформенный продукт может быть напиан с OpenGL + OpenAL для всех платформ, но на Windows 10 и Windows Phone разумно написать альтернативный рендерер или использовать Angle.
И это очень печально для меня, как пользователя Windows
При разработке новых игр уже имеет смысл смотреть на Vulkan, а не на OpenGL, поскольку Vulkan на современных видеокартах быстрее. Да и большую свободу разработчикам даёт.
Смотря каких игр. Если уровня ААА — то да, возможно стоит смотреть на Vulkan.
Иначе просто нет смысла — современного OpenGL хватает за глаза.
Иначе просто нет смысла — современного OpenGL хватает за глаза.
В четвертом думе вулкан быстрее, чем OGL. Причем, не только на тестах, это заметно невооруженным взглядом. Хотя железка древняя (AMDшный рефренс R9 270).
А больше я его нигде и не видел, вулкан этот. Хотя я не игрок, поэтому наверное сей факт неудивителен :)
А больше я его нигде и не видел, вулкан этот. Хотя я не игрок, поэтому наверное сей факт неудивителен :)
В idTech 6 VK-рендер на одном уровне с OGL4.5-ррендером (вероятнее всего потому что разработчики использовали AZDO в OGL4.5-рендере) и они оба обгоняют OGL4.3-рендер. Фокус в том, что на Radeon Software idTech 6 позволяет заюзать либо Vulkan, либо OpenGL 4.3.
То есть все могли бы жить-поживать и добра наживать с OpenGL 4.5 и AZDO, но необходимость в замене OpenGL да и ребрендинге таки назрела — потому и имеем Vulkan.
То есть все могли бы жить-поживать и добра наживать с OpenGL 4.5 и AZDO, но необходимость в замене OpenGL да и ребрендинге таки назрела — потому и имеем Vulkan.
Прирост заметный именно на амд картах. На нвидии он совсем не большой. Причина я думаю в том, что гл драйвар у ати-амд всегда был хуже нвидевского. Это не считая кучи глюков с которыми мне пришлось лет за 10 кодинга столкнуться…
Так камрад выше разъяснил, почему так — на радеонах используется OGL4.3, на нвидии — OGL4.5, поэтому в последнем случае разница между VK и OGL минимальна.
Ну а глюки радеонов — это да. Даже как пользователь, отмечу, что более глючные драйверы были пожалуй только у каких-нибудь там Savage или Permedia.
Ну а глюки радеонов — это да. Даже как пользователь, отмечу, что более глючные драйверы были пожалуй только у каких-нибудь там Savage или Permedia.
Это немного не совсем так.
AZDO реализуется спокойно на 4,3 железе.
buffer storage — 4.3
multidraw inderect — 4.1
bindless textures — 4.0
texture arrays — вообще на гл3 доступны
Я не копал вулкан, тк не интересно, но гляде примеры это очень похоже на гл45 с низкоуровневым доступом.
AZDO реализуется спокойно на 4,3 железе.
buffer storage — 4.3
multidraw inderect — 4.1
bindless textures — 4.0
texture arrays — вообще на гл3 доступны
Я не копал вулкан, тк не интересно, но гляде примеры это очень похоже на гл45 с низкоуровневым доступом.
Это вы верно подметили, тогда может дело в том что у AMD реализация чаще по спецификации, чем у nVidia? (Больше проверок в коде драйвера.)
AMD реально маниакально придерживается спецификаций. Но когда приходилось развертывать циклы, тк на амд шейдер без проблем компилировался, но рисовал чОрный экран, это вообще как? А развернешь все работает… Это при том, что шейдер совсем простой… А когда на 5ххх серии выборочно не пахал оклюжен квери и кондишенл рендер? Мы тогда этого Абрашу Селлера просто баг репортами задолбали.
Для любого вендора можно составить список эпичных провалов, суть не в этом, а в том что вряд ли тормознутость OGL4.3-рендера DOOM на Radeon Software связана с ними — рендеринг же корректный. Скорее с проверками, как мне кажется. Абрашу закидывать багрепортами нужно и полезно, чтобы он активнее подпинывал китайцев :)
Возможно)) Но самый лютый треш, это были опенгл драйвера интела ))
[задумывается] С точки зрения пользователя самым трешем были драйверы под Savage 4.
Хочешь поиграть в HL? — пуск батника с установкой одного пакета драйверов->рестарт->играем.
Хочешь в Q2? Мммм… нужно ставить другую версию, т.к. в текущей на Q2 выпадают текстуры. А на версии, где Q2 идет без глюков, HL превращается в белесое слайд-шоу.
А уж бох-ты-мой, ежели вдруг приспичило запустить что-то под DX — то там сразу 3 версии, под разные игрухи своя, иначе тормозит.
Первая TNT казалась божеством стабильности после S4 :) Хотя по скорости кое-где уступала.
Хочешь поиграть в HL? — пуск батника с установкой одного пакета драйверов->рестарт->играем.
Хочешь в Q2? Мммм… нужно ставить другую версию, т.к. в текущей на Q2 выпадают текстуры. А на версии, где Q2 идет без глюков, HL превращается в белесое слайд-шоу.
А уж бох-ты-мой, ежели вдруг приспичило запустить что-то под DX — то там сразу 3 версии, под разные игрухи своя, иначе тормозит.
Первая TNT казалась божеством стабильности после S4 :) Хотя по скорости кое-где уступала.
Первая ТНТ?) О да) Была у друга, я позже взял рейдж128 атишную. Билинейка была жуткая просто… А трилинейка ок. И 16бит цвет жуткий был. 32 уже ок. Как щас помню 42фпс на 1024 в ку2 (тирлинейкаи 24бита колор))) Ати еще конкретно подсиживали тем, что до 128й у них не было альфа блендинга… Что д3д, что гл
А что насчет DX12 против Vulkan? Что лучше?
Они практически идентичны. Но тут опять возникает вопрос, что даст больший профит. DX12 — это windows и xbox. Вулкан — это только windows. Довольно мало смысла, если выбросить из головы идеологические принципы. В перспективе, DX12 однозначно получит намного лучшую поддержку драйверами. Пока что конечно и там, и там наблюдаются проблемы молодости.
Direct3D 12 даёт разработчику доступ к Windows 10, Windows 10 Mobile и Xbox One,
Vulkan даёт разработчику доступ к Windows 7, 8.1, 10, GNU/Linux, Android и через MoltenVK — к MacOS и iOS.
То есть даже при разработке эксклюзивно для десктопной Windows разработчик получит доступ к большей аудитории выбрав Vulkan.
Vulkan даёт разработчику доступ к Windows 7, 8.1, 10, GNU/Linux, Android и через MoltenVK — к MacOS и iOS.
То есть даже при разработке эксклюзивно для десктопной Windows разработчик получит доступ к большей аудитории выбрав Vulkan.
Про доступность понятно. Интересен именно технический аспект.
Насколько я понимаю технический аспект — если код пишите лично вы, значит вам придётся в движке писать некоторую немалую часть того, что раньше на себя брал видеодрайвер, вне зависимости от того, какой API выберите. Если вы настолько хорошо разбираетесь в работе видеокарт, чтобы решать эту задачу самостоятельно, то вы уже знаете что выбрать. Ну а если не разбираетесь — тогда OpenGL или готовый движок с поддержкой нужных платформ.
если код пишите лично вы, значит вам придётся в движке писать некоторую немалую часть того, что раньше на себя брал видеодрайвер, вне зависимости от того, какой API выберите.
На мой взгляд в вашей фразе следующие проблемы:
1) В ДВИЖКЕ — это крест. Работу с API нужно выносить в отдельный слой. Тогда движок получится универсальным и кроссплатформенным. Особенно актуально, если посещают мысли об охвате нескольких платформ.
2) Делать то, что брал на себя видеодрайвер не нужно по определению. Задача драйвера — работа с оборудованием. Это слой абстракции. То, ради чего драйверы и были придуманы.
3) API берет на себя низкоуровневые функции. Ради этого он и нужен. Так что, будь то OpenGL, DirectX или любая другая библиотека — разбираться в архитектуре и особенностях работы с видеокартой не придется.
1) Согласен, просто назвал общим словом, не вдаваясь в детали.
2) Местами таки нужно — например, поддержку нескольких GPU придётся писать самим, драйвер тут не поможет.
3) В случае Vulkan и D3D12 какие-то функции берёт, а какие-то брать перестал, вот о чём речь. И сравнение с OpenGL и Direct3D до 11 включительно на мой взгляд некорректно — например сравните SLOC helloworld-ов на Vulkan и OpenGL.
2) Местами таки нужно — например, поддержку нескольких GPU придётся писать самим, драйвер тут не поможет.
3) В случае Vulkan и D3D12 какие-то функции берёт, а какие-то брать перестал, вот о чём речь. И сравнение с OpenGL и Direct3D до 11 включительно на мой взгляд некорректно — например сравните SLOC helloworld-ов на Vulkan и OpenGL.
2) Местами таки нужно — например, поддержку нескольких GPU придётся писать самим, драйвер тут не поможет.
Что подразумевается под поддержкой нескольких GPU? CrossFire и иже с ними?
И сравнение с OpenGL и Direct3D до 11 включительно на мой взгляд некорректно
Я изначально об этом говорил
2) Да, SLI или CrossFire, но помнится что возможен и более творческий подход в асимметричных конфигурациях, где слабому GPU отводиться какая-то отдельная роль, например заниматься только сглаживанием. На практике мы однако наблюдаем, что разработчики игр пока боятся браться даже за симметричные конфигурации, хотя казалось бы — вот она, возможность сделать идеальный multi-GPU без всех этих хаков со стороны драйвера и рендера. Но не делают, и тут обиднее всего за обладателей видеокарт с двумя чипами на одной плате, хотя их и мало.
3) То есть вы согласны с тем что в случае OpenGL и D3D11 драйвер берёт на себя многие задачи, а в случае с Vulkan и D3D12 разработчику придётся решать эти задачи своими ручками, которые для задействования потенциала новых API, притом должны быть весьма очумелыми?
3) То есть вы согласны с тем что в случае OpenGL и D3D11 драйвер берёт на себя многие задачи, а в случае с Vulkan и D3D12 разработчику придётся решать эти задачи своими ручками, которые для задействования потенциала новых API, притом должны быть весьма очумелыми?
То есть вы согласны с тем что в случае OpenGL и D3D11 драйвер берёт на себя многие задачи, а в случае с Vulkan и D3D12 разработчику придётся решать эти задачи своими ручками, которые для задействования потенциала новых API, притом должны быть весьма очумелыми?
В случае с Vulcan и D3D12 я не в теме, потому спорить не компетентен. Но изначально фраза заставила словить жесткий спотыкач мозгов.
Не может быть, потому что с OpenGL столько проблем, что игроки воют с каждым релизом игр на нем, тем более что он не покрывает ниодну из консолей. Намного лучший вариант это основной рендер на DX и на том, что у playstation. Если надо порты, то кое как переносить на OpenGL. Таким образом сделаны все топовые движки. Основной рендер это DX. Исключение лишь IDTech, который все равно толком нигде не используется и не сильно интересен сам по себе.
Подозреваю, что во всех ТОПОВЫХ движках есть слой абстракции. Так что переключение под другой рендер — вопрос далеко не самый сложный. Это, кстати, и объясняет, почему в настройках кучи игр есть выбор между православным DirectX и вражеским OpenGL.
Кучи игр? Это каких же. Возьмем вот frostbite. На данный момент лучшее, что есть на рынке в плане оснащения. Но к сожалению in-house. Он вообще не имеет версии под opengl. На нем выходят все игры EA.
А на счет слоя абстракции. Да, он есть. Но не думаете же вы, что это так просто, как подменить макросами одни функции на другие? Они похожи, но все равно имеют свои различия. И DX очевидно уделяется намного больше внимания. Он покрывает Windows и Xbox, поэтому это не удивительно. Для playstation есть своя библиотека. В итоге OpenGL не осталось места, и он попросту не нужен в современном геймдеве. Есть какие-то надежды только у вулкана. Да, люди любят приводить в пример IDTech и еще редкие редкие примеры, но они не меняют картины. Объективно, нет никаких причин использовать OpenGL. Он все равно не даст необходимой кроссплатформенности, а на единственной Windows принесет лишь проблемы с драйверами.
А на счет слоя абстракции. Да, он есть. Но не думаете же вы, что это так просто, как подменить макросами одни функции на другие? Они похожи, но все равно имеют свои различия. И DX очевидно уделяется намного больше внимания. Он покрывает Windows и Xbox, поэтому это не удивительно. Для playstation есть своя библиотека. В итоге OpenGL не осталось места, и он попросту не нужен в современном геймдеве. Есть какие-то надежды только у вулкана. Да, люди любят приводить в пример IDTech и еще редкие редкие примеры, но они не меняют картины. Объективно, нет никаких причин использовать OpenGL. Он все равно не даст необходимой кроссплатформенности, а на единственной Windows принесет лишь проблемы с драйверами.
Но не думаете же вы, что это так просто, как подменить макросами одни функции на другие? Они похожи, но все равно имеют свои различия.
Цель слоя абстракции подняться на уровень чуток повыше. Т.е. будет два разных слоя для работы с графическими фреймворками, а вот движок и игровая механика — останутся независимыми от API. Нет, это не просто подменить макросами. Это именно написание двух и более (сколько требуется) промежуточных слоев, которые с одной стороны покрывают потребности движка, с другой стороны работают с API. Результаты такой работы я видел. Игры под PS, XBOX и винду. Порт занимает относительно немного затрат времени.
В итоге OpenGL не осталось места, и он попросту не нужен в современном геймдеве.
О чем я и говорил. Для каждой задачи — свой инструмент. Для написания своей сапрообразной проги я, например, использовал OpenGL — и мне пофиг на наличие акселератора и аппаратного ускорения — цели другие. OpenGL для несложной работы с графикой показался проще, чем Direct3D.
У Xbox тоже свой API графический, а не D3D. DX12 базируется на API Xbox One, но не идентичен ему.
Сколько проблем с DOOM? Неужели больше, чем с последним Бэтменом? Если рассуждать так же, как рассуждаете вы — можно брать глюки, которые есть у каждой выходящей игры и заявлять, что все беды от Direct3D.
Утверждение об отсутствии покрытия консолей ложно — есть Steam Machine. Вы конечно же сейчас станете возражать в духе «нищитова» но данное ложное утверждение от этого не перестанет быть ложным.
А теперь, давайте вместе подумаем, зачем в Unreal Engine, Unity Engine и CryEngine добавили поддержку OpenGL, если он такой плохой? И как в idTech 6 из OpenGL 4.5 выжали столько же кадров в секунду, сколько из Vulkan?
Утверждение об отсутствии покрытия консолей ложно — есть Steam Machine. Вы конечно же сейчас станете возражать в духе «нищитова» но данное ложное утверждение от этого не перестанет быть ложным.
А теперь, давайте вместе подумаем, зачем в Unreal Engine, Unity Engine и CryEngine добавили поддержку OpenGL, если он такой плохой? И как в idTech 6 из OpenGL 4.5 выжали столько же кадров в секунду, сколько из Vulkan?
Проблемы с openGL? Если только на картах ати-амд и интела.
Помню в 95 винде игра работала приемлемо. Но стоило поставить обновление с ИЕ и OpenGL в комплекте, как сокрость DX игры падала катастрофически. Если с чистой виндой хватало 486DX2, то с обновлением понадобился уже пентиум. Откуда такое взялось для меня загадка.
и AMD (которая сейчас ATI)
Наоборот.
С дуба рухнуть, сравнивать работающий почти на голых микроконтроллерах, открытый стандарт, занимающий 90% рынка если взять и смартфоны, и прочее с закрытым набором либ, прибитым гвоздями к одной ОС. Какое противостояние то? В игрушках.
Сколько рынка эти игрушки занимают в деньгах против всего остального? Для интереса.
Мобильные игрушки тоже немало денег приносят, уж поверьте мне.
Ну и не забываем про консоли — на тех же плойках хоть и порезанный, но все же OpenGL.
Ну и не забываем про консоли — на тех же плойках хоть и порезанный, но все же OpenGL.
Так я не утверждаю обратного. Реально интересно сравнить долю pc+xbox относительно остального. Если есть такие оценки, конечно.
Никто всерьез не программирует на PS на OpenGL, насколько я знаю. Там как раз никакие абстракции не нужны.
Его никто не использует и есть он там чисто для галочки как враппер вокруг нормальной проприетарной библиотеки. Пора уже заканчивать пытаться воскресить OpenGL этим аргументом. В играх, которые имеют значение, т.е. не мобильные, DX доминирует и никуда деваться не собирается.
В играх, которые имеют значение, т.е. не мобильные
Вы не находите свое утверждение черезчур громким?
Не имеют значение для кого? Конкретно для вас? Или для людей в целом?
Многомиллиардные обороты в этой области говорят об обратном.
Если вы располагаете конкретными цифрами — приведите мне что мобильные игры не имеют значение.
Я уже кучу лет слышу от вьюношей, которые в жизни не написали ни строки кода под д3д или гл что гл умер. А уж апломба в их заявлениях столько, что кажется, что они написали как минимум какой нибудь край энджин с нуля в одиночку))))))
Один Pokemon Go за полгода (!) заработал 500 мегабаксов. За год ожидают ярд.
Ага, в основном секторе применения этих библиотек. И так уж получилось, что DX там занимает практически весь рынок
Какой нынче ад для хардкорных (не путать с редактор-обезьянами) геймедевелоперов, каждый тянет свой API: MS — DX, Apple — Metal, остальные — вулкан (ну и старенький OpenGLES для мобилок). Это же надо писать игровые движки с костылями под каждую платформу :( Вот вроде Вулкан так хорош, но почему эпл его не продвигает? На сайте вулкана нет информации о поддержки оного яблочных платформ — какой же он тогда кроссплатформенный?
Разговаривал с некоторыми геймдевами, они, наоборот, рады, мол, лучше 10 хороших API под разные платформы, чем 1 плохое под все платформы.
Что хорошео в том, что надо делать абстракцию между разными апи = получать некоторый оверхед из-за разности подходов.
Я не оспариваю, что Apple вообще фигней страдает. По поводу Metal был сначала энтузиазм, но он поутих, потому что Vulkan оказался пусть и сложнее, но не хуже по итоговому выхлопу, и в играх Vulkan используется прямо сейчас, в отличие от Metal, который кроме как в бенчмарках, технодемках и некоторых мобильных играх не первого эшелона нигде не используется.
Ну и к OpenGL благожелательность повысилась, так как последние версии API стали удобноваримыми, конформанс-тесты стали строже, и драйверы ведут себя всё более предсказуемо. Поэтому Apple со своим GLES 3.0 и GL 4.0 выглядит совсем странно. Так что Apple тут начинает создавать разработчикам уже больше проблем, чем OpenGL. Даже известный фанат Metal Пранчкевичус из Unity перестал оспаривать нелепость решения Apple не развивать свою реализацию GL+ES и не пускать Vulkan.
Ну и к OpenGL благожелательность повысилась, так как последние версии API стали удобноваримыми, конформанс-тесты стали строже, и драйверы ведут себя всё более предсказуемо. Поэтому Apple со своим GLES 3.0 и GL 4.0 выглядит совсем странно. Так что Apple тут начинает создавать разработчикам уже больше проблем, чем OpenGL. Даже известный фанат Metal Пранчкевичус из Unity перестал оспаривать нелепость решения Apple не развивать свою реализацию GL+ES и не пускать Vulkan.
Хорошего? Структуризация кода. А вот оверхед — нужно оценивать, скорее всего им можно пренебречь ради повышения качества итогового продукта.
Похоже, что аналогичная история сейчас разворачивается вокруг веб-технологий: W3C — это полный аналог ARB, тоже всё делают не вовремя и костыльно.
Многие разработчики уже с нетерпением ждут, когда же в мире останется всего один браузерный движок, чтобы его владелец наконец получил возможность послать W3C куда подальше и сделать всё по уму, а главное — быстро.
Многие разработчики уже с нетерпением ждут, когда же в мире останется всего один браузерный движок, чтобы его владелец наконец получил возможность послать W3C куда подальше и сделать всё по уму, а главное — быстро.
Многие разработчики уже с нетерпением ждут, когда же в мире останется всего один браузерный движок
А остальные всё ещё помнят что из этого вышло в прошлый раз.
К сожалению посредством Chrome/blink это уже происходит.
Сначала Opera начала поддерживать хромовые префиксы — умерла.
Теперь FF тоже начинает поддерживать их и прикидываться хромом… Если посмотреть на графики, то видно что к сожалению его ожидает таже судьба что и мою любимую оперу.
А в руках гугла веб уже превращаться в тормозящую анимацию с material design, попутно выжирающую всю оперативную память.
Сначала Opera начала поддерживать хромовые префиксы — умерла.
Теперь FF тоже начинает поддерживать их и прикидываться хромом… Если посмотреть на графики, то видно что к сожалению его ожидает таже судьба что и мою любимую оперу.
А в руках гугла веб уже превращаться в тормозящую анимацию с material design, попутно выжирающую всю оперативную память.
Что-то такое я уже где-то читал.
https://habrahabr.ru/post/123194/
и, вроде как, vulcan очередная пробежка по граблям: попытка стандартизировать проприетарный mantle от amd
Не знаю почему, но манера подачи материала напомнила мне почти такую же эпичную историю про фатальный недостаток.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Direct3D vs OpenGL: история противостояния