Про графические API

Проще из железа все соки выжимать наверное, а «высокоуровневое» переехало в графические движки.

Мне под DOS на асме свои демки проще писать было, чем на D3D :)

По такой логике нужно избавиться от всяких Java, Python и ко, а писать всё на сишке, или ещё лучше, на ассемблере LLVM(ибо он переносимый, в отличие от, к примеру, nasm), так же железо используется эффективнее.

Не самая плохая логика. Логичная я бы сказал, не как обычно у программистов.

а писать всё на сишке

Так они и пишут. Вон Factorio на сишке написан.

OpenGL всегда был жутью. Я нарисовал на нём зелёный треугольник, и понял, что больше на этом я никогда ничего не нарисую. НЯП, очень мало кто на чистом OpenGL пишет, всё через прослойки.

А вулкан стал ещё большей жутью, и ещё больше прослоек получется

Ну, можно считать ЯВУ более высокоуровневым API к сишным библиотекам. :) Тем более, по уму оно так и делается нередко - движок игры на крестах для скорости, игровая логика на Lua для удобства.

Но за пределами игор почему-то этого массово нет, все известные крупные приложеньки пишутся на крестах (в шинде на сисярпе) целиком. В линуксе чтобы не страдать с крестами для мелких программ, опускаются до голой сишки с указателями, buffer overflow и текущей памятью. Зачем высокоуровневую логику на с/с++ писать или выдумывать DSL специальный внутри - я хз.

Ну C++ неплохо подходит для реализации логики, а вот Си действительно плохо подходит для этого, там из указателей вылезать не будешь. :)

Так чем более низкоуровневый, тем лучше. В идеале надо было бы все API свести к OpenCL, но индустрии нужен зоопарк для зарабатывания денег.

Обычные разработчики всё равно их не видят, а пишут код scene graph в терминах unreal/unity/godot и что там ещё сейчас популярно.

unreal/unity/godot

Первые два(про третий не знаю) - унылое тормозное говно(заметно по «продуктам» на сем чуде), и даже говнокодная реализация игры на чистом OpenGL будет быстрее.

По такой логике нужно избавиться от всяких Java, Python и ко, а писать всё на сишке

Да, это было бы классно.

Мне под DOS на асме свои демки проще писать было, чем на D3D :)

Вот уж точно!

На голом вулкане игры не пишут. На вулкане пишут игровой движок, а уже на движке делается игра. Игровой движок это и есть дружелюбие. Вулкан в этом случае выступает аналогом ассемблера — он должен быть низкоуровневым, чтобы можно было выжать все соки из железа.

Про то что теперь есть Unreal правильно написали, Unity и Unreal убили кучу домашних движков, Stalker на Unreal, GTA Definity Edition на Unreal, итд. Там и редактор сцен, материалов и прочего есть, можно сразу полетать посмотреть, и встроить потом его в свое приложение на электроне.

When I find my code in tons of trouble
Friends and colleagues come to me
Speaking words of wisdom
Write in C

Но за пределами игор почему-то этого массово нет

Ты прямо сейчас сидишь в самой массовой платформе, в которой движок написан на низкоуровневом языке, а вся логика на высокоуровневом. Эта платформа называется веб.

Не самая плохая логика

Ну если ты готов ждать пяток лет, пока, скажем, твой банк на ассемблере пишет мобильное приложение, то, может, и не самая.

Идея ведь в том, чтобы тупой однообразной работой занимались машины, а не человек.

Потому что эти API - они для построения конвееров рендеринга графических объектов. Соответственно примитивы и вызовы, которые предоставляются этими апихами, они заточены на расширение функционала именно построения конвееров и максимальной оптимизации утилизации железа. Те они упрощают именно эти задачи, а не задачу нарисовать что-то.

Все это потому что железо стоит денег (а его разработка - еще больших денег). Картинку же покрасивше хочется (она продается хорошо), а еще хочется чтобы аккум высаживался не за 5 минут.

Логика принятия решений тут примерно следующая: на уровне движков рендеринга выжимают максимальный графоний за счет утилизации железа и математики. На уровне производства графики - художников подешевле (чтобы красиво рисовали, но не слишком задумывались над технической частью). На уровне скриптовки - разрабы уже не думают как именно рисуется их моделька/спрайт/эффект. Следят за количеством дроуколлов и полигонов в сцене, а остальное прожует движок.

отчасти связано с ограничением ресурса и возрастающими хотелками к скорости. Чем более низкий уровень API/языка тем большую скорость можно выжать.

на пути от asm к С, С++ и так далее, возможности железа всегда серьёзно обгоняли фантазии софтоделов. Получилось даже что Python зашёл :-) «при написании этого текста задействовалось(простаивало) 16 ядер ЦП и 64Gb памяти»

с графикой всё вышло хуже - там всё всегда на пределе.

PS/ и вторая часть - «популяции разработчиков». API OpenGL/vulkan впрямую использует мизерное кол-во по сравнению с общеприкладным софтом. Комстролить high-level api или супер-удобный язык для такого мизера никому даже в голову не пришло :-) Их мало, они все де-факто хорошо подкованы и вполне обходятся тем что есть

По такой логике нужно избавиться от всяких Java, Python и ко, а писать всё на сишке

Да, это было бы классно.

Поддерживаю!

Надо вот тебе тупо по rest api забирать данные, парсить этот json, и класть в бд и рисовать график в пдф - а тут сишка как раз идеально подходит, бизнес готов платить за написание хедер файлов, траханье со стёком и буферами, выходы за границы массивов, компиляцию.

Нехер за пол дня на питоне с готовыми библиотеками такое делать, бизнесу нужны идеальные скоростные низкоуровневые приложения! Не важно сколько займёт разработка - бизнес, клиенты и конкуренты подождут!

Что там такого сложного должно быть в приложении на 5 лет?

стёком

Вдоль!

В основном инструментарий разработчика становится более дружелюбным со временем. От ассемблера к Си, от Си к C++ и тд

Цели разные, у инструментов разработки цель упростить сложность, заключить её в абстракцию удобную для использования.

У графических API цель иная, сделать низкоуровневый интерфейс над GPU с минимизацией влияния абстракций на производительность.

Пологаю подразумевается что разработчики игр будут работать не непосредственно с Vulkan, а используя игровые движки их их API. Вот игровые движки будут использовать преимущества низкоуровневого Vulakan и DX12.

А можно на го и быстро и производительно и с библиотеками :)

Почему ты детский труд не используешь? А, по этическим соображентям, хотя экономически — это очень выгодно, в 19-м веке так еще делали, а в азиях и африках так до сих пор. Так что не все поддается логике экономической целесообразности.

Но ведь использование готового движка в общем случае приведёт к снижению производительности, даже если он и использует вулкан, по сравнению с реализацией игры с нуля. Ведь специализированный движок под конкретную игру все равно производительнее, чем универсальный. А OpenGL для в качестве API для прямого использования очень неплох, его вызовы довольно высокоуровневые, а качество их реализации в драйверах в подавляющем большинстве случаев лучше, чем их реализация в движках на вулкане.

Но ведь схема

OpenGL -> Специализированный движок под игру -> Игра

в большинстве случаев оказывается быстрее схемы:

Vulkan -> Универсальный движок -> Игра

При этом написание движка на OpenGL одно удовольствие, по сравнению с вулканом, соответственно, можно выжать из железа ещё больше ресурсов.

При этом написание движка на OpenGL одно удовольствие

Кастани меня, когда напишешь, пожалуйста.

Я думаю, что ждать того, как я напишу что-нибудь на каком-нибудь Unity можно ещё дольше. А так, изучаю OpenGL понемногу, пока всё нравится.

Пожалуй, не буду ждать: https://magnum.graphics/showcase :)

использование готового движка в общем случае приведёт к снижению производительности

Относительно голого вулкана при условии, что голый вулкан будет написан максимально эффективно специалистом.

А OpenGL для в качестве API для прямого использования очень неплох,

Плох. Плох и как графический API, плох как API для рисования треугольничков – он плох всем и во всем.

его вызовы довольно высокоуровневые,

И?

а качество их реализации в драйверах в подавляющем большинстве случаев лучше, чем их реализация в движках на вулкане.

Бред. Статистику в студию.

Почему ты детский труд не используешь? А, по этическим соображентям, хотя экономически — это очень выгодно, в 19-м веке так еще делали, а в азиях и африках так до сих пор. Так что не все поддается логике экономической целесообразности.

Мы живём в рамках законов, нравится нам это или нет.

Ну и дети вряд ли напишут что-то стоящее для бизнеса на сях, на том же питоне у них больше шансов :-)

Дополню имеющиеся ответы.

OpenGL усложнялся

Потому что возможностей убогого OpenGL стало не хватать – и его пришлось усложнять, а когда стало ясно, что он концептуально не может делать то, что хочется – пришлось сделать Vulkan.

Никого не волнуют какие-то там параллели с языками (кстати там тоже бред написан), где там облегчение и где усложнение. Развитие происходит соответственно спросу.

И еще немного, как бы сюда и как бы к движкам. На Vulkan можно написать очень эффективную реализацию OpenGL. Более того, это уже сделали. Zink называется, и сейчас находится в стадии активной доработки и полировки.

На OpenGL ничего подобного Vulkan написать нельзя – несмотря на все усложнения и доработки.

Поэтому появился Vulkan. Потому что наличие тонкого контроля над низкоуровневыми деталями реализации лучше отсутствия.

Бред. Статистику в студию.

Просто личные наблюдения, что игры на UE и Unity тормозят, тогда как игры, которые имеют собственные движки работают хорошо(причём почти все подобные игры используют таки OpenGL).

Плох.

Мне наоборот понравился.

И еще немного, как бы сюда и как бы к движкам. На Vulkan можно написать очень эффективную реализацию OpenGL. Более того, это уже сделали. Zink называется, и сейчас находится в стадии активной доработки и полировки.

Zink таки написан разработчиками драйверов, что всё равно подтверждаёт моё утверждение, что реализации графических функций в драйвере лучше, чем в движках.

Просто личные наблюдения, что игры на UE и Unity тормозят, тогда как игры, которые имеют собственные движки работают хорошо(причём почти все подобные игры используют таки OpenGL).

Опять какой-то бред. Почему они тормозят? Потому что их пишут необразованные мартышки, которые х***к х***к бесплатные ассеты из магазина в формочку, и в стор?

Да, безусловно, там добавляется определенный оверхед – но это плата за обобщенность и умение работать с графикой практически любой сложности, причем предоставляя средства как для мартышки, так и для специалиста.

Но сможете ли вы свой специализированный, заточенный под вашу игру движок написать – пусть даже на Vulkan, отложим пока что OpenGL – так же эффективно? Вовсе не факт.

Мне наоборот понравился.

Ваше «Мне понравился» и «Мне не понравился» опять же никого не волнуют. Графические API развиваются не для вас и на вас даже не ориентируются.

что всё равно подтверждаёт

Никаким образом. Zink ничем принципиально не отличается от любого другого Vulkan приложения или библиотеки.

моё утверждение, что реализации графических функций в драйвере лучше, чем в движках.

Чем лучше? Чем лучше-то? Вы уже 36 постов пишете про абстрактное «лучше», про какую-то «сложность», «дружелюбность» и так далее. Какие-то конкретные критерии и статистика будут?

игры, которые имеют собственные движки работают хорошо

Написать движок - нетривиальная задача, потому что зависит не только от графики. Это и физика, и организация ресурсов игры, звук, события от органов управления и т. д. и т. п.

Кому-то нужна 3D-физика, а кому-то хватает и Box2D. Но на всех не угодить, что приводит к усложнению движка, дабы максимально удовлетворить запросы пользователей.

Тетрис и шахматы можно написать и на движке Doom, но зачем?

Чем лучше? Чем лучше-то?

Не видел ни одной не тормозной игры на Unity или UE. Тогда как вы заявляете, что Zink - эффективная реализация OpenGL поверх Vulkan. Причём написан он разработчиками Mesa, то есть разработчиками драйверов. И возникает вопрос - зачем нужен Vulkan, если по-настоящему эффективно на нём могут писать только те, кто сами реализуют его? Тогда как OpenGL представляет интерфейс, который вполне может использоваться даже не сильно квалифицированными разработчиками без прослойки в виде готового движка, и получится далеко не самая тормозная реализация игры.

Именно поэтому наиболее эффективно писать под каждую игру свой движок, наиболее полно удовлетворяющий конкретным задачам.

Не видел ни одной не тормозной игры на Unity или UE.

Соболезную.

«Тормозная» – в чем это выражается? По сравнению с чем? На каком железе?

Причём написан он разработчиками Mesa, то есть разработчиками драйверов.

И? Если разработчики Mesa напишут сайт, это тоже будет примером того, что сайты могут писать эффективно только разработчики драйверов?

И возникает вопрос - зачем нужен Vulkan, если по-настоящему эффективно на нём могут писать только те, кто сами реализуют его?

Откуда этот бред взялся? Прекратите спорить с голосами у себя в голове.

Тогда как OpenGL представляет интерфейс, который вполне может использоваться даже не сильно квалифицированными разработчиками

Нет, не может. От треугольничка до пусть даже двухмерной игры из спрайтов огромный путь – и это даже если не затрагивать ничего кроме графической части.

без прослойки в виде готового движка

Ога. Зато с огромной, крайне неэффективной относительно Vulkan и зачастую глючной прослойкой в виде готовой реализации OpenGL в драйвере.

И я еще немного подкину. Вот годичной давности (свежее не нашел) бенчмарки различных игр на Zink и на нативном OpenGL. Нетрудно заметить, что Zink примерно на том же уровне – местами отстает, местами опережает натив.

И это значит что неквалифицированные разработчики могут и дальше писать треугольнички на OpenGL, квалифицированные могут писать низкоуровневый код и получать лучшую производительность, а разработчики драйверов облегчить кодовую базу и выкинуть нативный OpenGL в пользу Zink.

Именно поэтому лучше выбрать Magnum, OGRE, GLScene, etc.
Потому что, если сегодня я пишу игру, то завтра могу захотеть написать симулятор планетария.

Манязаявления. Популярность юнити и анрила как бы намекают, что спецдвижок под игру это не фига не быстро и не удобно.

Для сравнения можешь посмотреть на sdk от сталкера, который слит в исходниках. Там кривое говно, с которым нужно бороться, чтобы что-то сделать. Не удивительно, что второй сталкер пытаются делать на анриле, а не на собственных костылях.

Для сравнения можешь посмотреть на sdk от сталкера, который слит в исходниках.

И где искать?

Ну и справедливости ради, сталкер это пример хорошей оптимизации конечного продукта, как пользователю мне глубоко плевать на внутренние детали реализации, и не плевать на то, что сталкер не тормозит даже на калькуляторе.

Ведь специализированный движок под конкретную игру все равно производительнее, чем универсальный.

Да, но индустрия компьютерных игр теперь по обороту больше чем киноиндустрия. Там большие инвестиции, рынок растет, нужны специалисты которые могут выдать продукт определенного качества за предсказуемые сроки. Тут как нельзя лучше подходят готовые движки у которых уже есть армия пользователей (инди разработчики, линейные сотрудники игровых студий, просто те кто пытаются написать свою первую игру и изучает какой-то движок), вот такими разработчиками средней руки можно укомплектовать студию и начать разработку проекта.

А тормозят новые игры только потому что инвесторы не хотят отодвигать релиз продукта. У них есть план когда деньги должны вернуться (ведь они эти деньги откуда-то вытащили), они высчитывают момент когда их продукт может собрать наибольшее количество денег. И разумеется в такой ситуации времени на оптимизации не остается. И получается что разработку не заканчивают, а просто прекращают к часу Х и объявляют релиз.

А OpenGL для в качестве API для прямого использования очень неплох

Пользуйся. OpenGL будет продолжать существовать, если не как прямая реализация, то как прослойка типа Zink.

а когда стало ясно, что он концептуально не может делать то, что хочется – пришлось сделать Vulkan.

Ну, вроде как ATI (в составе AMD) «пришлось сделать» Mantle, который после передачи Khronos’у стал уже Vulkan.

удовлетворяющий конкретным задачам

Кажись, конкуренция, у кого графика круче уже практически прошла. И требования стали: state of the art 3D. А этот state и задаёт, например, Unreal Engine.

Да и под конкретные трудоёмкие вычислительные задачи лучше ведь писать свою ОС. Но чаще всего всё равно пользуются свободным Линукс. А Unreal, будучи кстати открытым движком (хоть и не свободным), и стал, вроде, вот таким вот Linux в мире топ-игр. (Ну, это мои наблюдения со стороны.)

Классика же. Когда приходят корпорасты, то всё скатывается в сраное говно. И игры не исключение.

не знаешь, есть ли какая-нибудь годная литература по GLSL?

На многословность Vulkan жалуются даже в геймдеве, и, например, Apple со своим Metal пошла по другому пути. WebGPU тоже (который доступен на десктопе через Dawn для C++ и wgpu для Rust). Сохранив баланс между гибкостью и многословностью. Так что Vulkan скорее не правило, а исключение.

Но вообще большинство разрабов не пишет движок с нуля, а использует какой-то готовый, так что им не нужно напрямую взаимодействовать с графическим API.