Давно известно, что 11.2 на старте xbox one имел пару фич еще разрабатывавшегося 12 (в частности command bundles). Это не делает его особо уникальным, и не факт, что кто-то вообще успел воспользоваться. Т.к. системы для Xbox и PC разрабатываются параллельно, но релизы не синхронизированы, то логично, что иногда возникают подобные отличия. Практически все API, созданные специально для бокса (xinput, xaudio), раньше или позже добираются до десктопа и становятся на нем основными. Сейчас MS хочет окончательно убрать разделение со своим UWP.

Ничего про производительность там я не увидел. Код конечно не будет идентичен, потому что для бокса есть/необходим отдельный XDK. Но это отличия на уровне "vulkan под unix vs windows", код отличается на стадии инициализации API/устройства, но значимая его часть остается неизменной.

4e_alex выше был замечен валидный поинт, что система памяти на XBO отличается заметно от традиционной ПКшной. Разработчики любят жаловаться на то, что под неё сложно оптимизировать. И под неё нужно оптимизировать специально. А так я не знаком с XDK. Стал бы этот разработчик DOOM вообще отмечать разницу если она была бы почти что полностью только в инициализации? Это не имеет смысла. Кого волнует разница в инициализации

http://www.eurogamer.net/articles/digit ... ystation-4
http://www.eurogamer.net/articles/digit ... tform-game
В обоих случаях видим классическое "на низкоуровневые оптимизации не хватило времени".

http://wccftech.com/crytek-explains-xbo ... dth-gains/
Они разбили сцену на тайлы, это даже не низкоуровневый какой-то подход.
Тупость MS состоит в том, что они засунули esram к GPU, который рендерит не тайлами (что заставляет эмулировать такой рендеринг самого разработчика).

Ну то есть у нас 2 примера для относительно новых PS4/XBO, которые ещё не так катастрофически отстают от ПК в производительности, как отставали XB360/PS3. Это для того, чтобы опровергнуть моё утверждение, что разработчики десятками лет на консолях использовали низкоуровневые API, чтобы выжать максимум? Gee, понятно, что и для XB360/PS3 поначалу многие могли использовать высокоуровневые обёртки, нужно было время освоить низкоуровневые, да и разрыв между консолями и ПК в производительности ещё не был так велик
Я вот сейчас попробовал погуглить, нашёл кучу ссылок, где говорится, что LibGCM был использован большинством разработчиков на PS3. Можете сами попробовать погуглить это название, чтобы найти остальные. У кого-то из разработчиков были свои высокоуровневые обёртки над ним, но сама Sony даже не предоставляла полноценной альтернативы, PSGL по своим возможностям ни для чего серьёзного не годился

Старье меня не интересует априори. На PS3 деваться было особо некуда с ее то "потенциалом". Это было в опровержение "сами просили о большем контроле на ПК". Прям представляю себе разработчика: "дайте мне API низкоуровневый, руки чешутся начать оптимизировать игру под миллионы возможных конфигов и десяток относительно живых архитектур GPU". Тут люди свой код то написать ленятся, даже id сдалась и в tech 6 понапихала middleware.

http://www.bit-tech.net/hardware/graphics/2011/03/16/farewell-to-directx/3
От тех же разработчиков Крайтек это точно не единственное подобное заявление, даже раньше 2011-го по-моему были. Есть и от других, но не буду же я их сейчас искать?

Ну то есть до DX12 было по-другому? DX12 вообще ничего принципиально в этом отношении не меняет, кроме того, что добавил разработчикам возможностей, которые при том не все видеокарты сейчас полноценно поддерживает

Добавлено спустя 32 минуты 50 секунд:

Который выбирает С++ для написания ядра движка. Вот хипстер. Мог бы Java использовать, но зачем-то захотел использовать AOT язык с мануальным управлением памятью и детерменистическим временем жизни объектов. Теперь ещё захотел кастомного контроля над памятью и не только от графического API. Crazy batshit

Конечно по-другому. За редким исключением рецепт был таким: кодим под наибольший общий делитель. Если у кого-то из вендоров что-то там в капсах в большую сторону выпирало, то оно просто игнорировалось (за исключением случаев, когда приходили специалисты от этого самого вендора с предложением помощи, в том числе финансовой). По такому рецепту было создано огромное количество шыдевров от EA, Ubisoft и пр.

Сомневаюсь, что управление памятью тут играет определяющую роль.
MS уже очень давно толкает свой C# как основной язык. Без NETFX боксовый XDK даже не установится. Правда, психов, пишущих код на нем, пока нет. Сказывается немощность консольных CPU и очень медленная работа JIT-языков.

А причём тут сам по себе DX12? Новые фичи, которые слабо поддерживаются со стороны видеокарт, могли( и добавили ) в 11. Суть в том, что DX12 не такой уж низкоуровневый API, писать что-то под конкретную карту нужно не больше, чем это было раньше, с 11-ым. Но лишние, именно лишние абстракции, в нём убрали. Кто хочет получить более высокий уровень с более простой моделью программирования, может использовать надстройку над 12-ым. Или 11-ый, который всё ещё не списан со счетов

По-моему, уже скоро как 15 лет будет, как они это делают. Но для ядра движков всё равно выбирают С++, какой бы уродливый сам язык и не был. Майкрософт сами пытались переписать ядро Windows на C#, Vista должна была быть первой ОС с ним. В итоге потратили несколько лет, задержали выпуск ОС, но в итоге у них ничего не вышло и пришлось оставить С++ ядро

Одну из определяющих. Реально на замену С++ теперь появился Rust, который, в отличие от огромного числа конкурентов до этого, не полагается на GC. Для игрового движка, который не может себе позволить неожиданные остановки в работе и перерасход памяти, GC до сих пор не особо подходит, как бы он там хорошо не выглядел на бумаге и как бы не обещал не останавливать мир ни в коем случае

Диез можно компилировать и не париться с JIT.
Правда сам язык далеко не фонтан.



А что сразу не Go или Swift? Все "убийцы C/C++" заканчивают одинаково нишево.

Там не такое ядрёное GC, как в Java, например. А кому нужно, GC можно вообще отключить.
А ещё есть Nim, например. В котором можно использовать GC, но который прямо заточен под мягкое реальное время (те же игры).

Ну и в Rust собираются GC добавить в будущем, срачи на этот счёт уже идут.

Не совсем ясно, при чем тут конкретно DX12, если фича работает только в LDA-режиме. Ничто не мешало ее реализовать хоть 10 лет назад, опомнились.
Думаю, что в каком-то виде оно и было уже, иначе бы храфик frametime был слишком мохнатым.

Вот это приговор дх 12. На радеонах без буста, на нвидиа - занижение производительности

knight_asd да я бы не стал такие выводы делать. Мелкомягкие его совсем для иных целей разрабатывали. Другой момент что набежали "любители красного потанцевала и халявы" и стали "втирать дичь" выдавая чемоданы за некий скрытый резерв. Мб через лет 5, когда он зайдет на рынок плотно и будут первые реальные успехи. Если к тому времени все консолепорты не угробят(

Надо смотреть буст на слабых процессорах

zzzzzzz то не буст, а неумение дров амд работать в мультипотоке в дх 11. На нвидиа ситуация обратная

У них dx11-драйвер умный слишком)
В dx12 сфера его ответственности резко упала, поэтому руки разработчиков он исправить не может. Хотя, ИМХО, разработчики Хуанга уже должны вовсю думать, куда влезть чтобы возможность маневра вернуть.

devl547 Выше писали, что в дх 12 драйвером тоже можно работать, но не так активно.
Амд драйвер не поддерживает differred contex, от этого и такая процесорозависимость. Почему амд так и не написала драйвер - хз.