Графический api что это

Что такое API

Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API. Что же это за зверь такой? Давайте разбираться!

— А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…

А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.

Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.

Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:

• скучать в ожидании;
• проверять логику работы по API

Что такое API

API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:

• мои обязанности — внести такую то сумму,
• обязанность продавца — дать машину.

• Code first — сначала пишем код, потом по нему генерируем контракт
• Contract first — сначала создаем контракт, потом по нему пишем или генерируем код (в этой статье я буду говорить именно об этом стиле)

API — набор функций

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

Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:

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

Тут вы можете мне сказать:

— Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!

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

И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.

Как составляется набор функций

Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:

• отдельно API для входа в систему, где будет регистрация и авторизация;
• отдельно API для отчетности — отчет 1, отчет 2, отчет 3… отчет N. Для разных отчетов у нас разные формулы = разные функции. И все мы их собираем в один набор, api для отчетности.
• отдельно API платежек — для работы с каждым банком своя функция.
• .

Можно не группировать вообще, а делать одно общее API.

Можно сделать одно общее API, а остальные «под заказ». Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. А любые хотелки заказчиков выносятся отдельно.

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

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

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

При чем тут слово «интерфейс»

— Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс?

Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:

1. Инкапсуляция
2. Наследование
3. Полиморфизм

Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:

• что подать на вход;
• что получается на выходе;
• какие исключения нужно обработать.

Как вызывается API

Вызвать апи можно как напрямую, так и косвенно.

1. Система вызывает функции внутри себя
2. Система вызывает метод другой системы
3. Человек вызывает метод
4. Автотесты дергают методы

1. Пользователь работает с GUI

Вызов API напрямую

1. Система вызывает функции внутри себя

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

Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. И он же его потребитель! А значит, проблемы с неактуальной документацией нет =)

Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…

2. Система вызывает метод другой системы

А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.

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

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

Я подключаю подсказки по API. И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:

• Он вводит букву на моем сайте
• Мой сайт отправляет запрос в подсказки Дадаты по API
• Дадата возвращает ответ
• Мой сайт его обрабатывает и отображает результат пользователю

И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯

Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.

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

Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.

В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!

(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)

3. Человек вызывает метод

1. Для ускорения работы
2. Для локализации бага (проблема где? На сервере или клиенте?)
3. Для проверки логики без докруток фронта

Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!

Конечно, это можно сделать с помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?

Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.

И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!

Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.

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

Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.

4. Автотесты дергают методы

Есть типичная пирамида автоматизации:

• GUI-тесты — честный тест, «как это делал бы пользователь».
• API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
• Unit-тесты — тесты на отдельную функцию

Слово API как бы намекает на то, что будет использовано в тестах ツ

• операция: загрузка отчета;
• на входе: данные из ручных или автоматических корректировок или из каких-то других мест;
• на выходе: отчет, построенный по неким правилам

• Ячейка 1: Х — Y
• Ячейка 2: Z * 6
• .

GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.

API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.

Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.

Косвенный вызов API

Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.

То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает. Пользователь работает через GUI (графический пользовательский интерфейс).

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

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

И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!

Что значит «Тестирование API»

В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.

Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:

• автотесты на уровне API
• или интеграцию между двумя разными системами.

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

И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!

Резюме

API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

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

1. Система вызывает функции внутри себя
2. Система вызывает метод другой системы
3. Человек вызывает метод
4. Автотесты дергают методы
5. Пользователь работает с GUI

• автотесты на уровне API (умение автоматизировать)
• интеграцию между двумя разными системами (обычно SOAP или REST, то есть работу в SOAP Ui или Postman).

• Тестирование IT-систем
• Тестирование веб-сервисов

API – графические интерфейсы программ.

API (Application Programming Interface) – графический интерфейс программ — предоставляeт разработчикам аппаратного и про­граммного обеспечения средства создания драйверов и программ, работающих быстрее на боль­шом числе платформ.

3D API позволяет программисту создавать трехмерное программное обеспечение, использующее все возможности 3D-ускорителей не прибегая к низкоуровнему программированию. 3D API делятся на стандартные (универсальные: OpenGL, Direct 3D и др.) и собственные (специализированные: Glide, Rredline и др.). Стандартные API поддерживают широкий спектр 3D-ускорителей и освобождает программистов от низкоуровнего программирования. Собственный 3D API предназначен для одного семейства 3D-ускорителей и ограждает программистов от низкоуровнего программирования. Использование 3D API требует применения драйверов для этого 3D API. Наличие драйверов для Direct 3D и OpenGL для Win­dows является обязательным требованием ко всем 3D-ускорителям. В настоящее время существует несколько API — OpenGL (фирма SGI), Direct 3D (фирма Microsoft) и Glide (фирма 3Dfx). Glide поддерживается только набо­ром микросхем, выпускаемым фирмой 3Dfx. Остальные API поддерживаются большинством со­временных видеоадаптеров.

API Direct 3D. Direct 3D является частью API, называемого DirectX. Современное программ­ное обеспечение широко использует графические интерфейсы Х Win­dows и OpenGL. Этот API предназначен для облегчения программирования игровых программ. Direct 3D имеет два режима: RM (Retained mode) – абстрактный и IM (Immediale) – непосредственный. IM состоит из тонкого уровня, который взаимодействует с аппаратурой и обеспечивает самое высокое быстродействие. RM является высокоуровневым интерфейсом, обеспечивающим для программиста множество графических операций, включая инициализацию и трансформацию. Большинство 3D-игр используют режим IM. В Windows Vista реализована поддержка тех же интерфейсов Direct3D и DirectDraw, как в Windows XP, начиная с DirectX 3 (за исключением режима Retained Mode в Direct3D). Существует и еще одно ограничение для полноценных 64-битных приложений Windows XP Professional x64 Edition, поддержка функций которых под Windows Vista ограничена Direct3D9, DirectDraw7 и более новыми версиями интерфейсов.

API OpenGL. API OpenGL является открытым 3D API, который поддерживается ассоциацией крупнейших фирм таких как DEC, E&S, IBM, INTEL, INTERGRAPH, Microsoft , SGI. Этот API реализует широкий диапазон функций от вывода точки, линии, полигона до рендеринга кривых поверхностей NURBS, покрытых текстурой. OpenGL-драйвер может быть реализован в трех вариантах: ICD, MCD и мини порт. ICD (Installable Client Driver) полностью включает все стадии конвейера OpenGL, что обеспечивает максимальное быстродействие, но разработка такого драйвера очень трудоемкий и сложный процесс. MCD (Mini Client Driver) разработан для внесения абстракции в конвейер OpenGL, и поэтому написание драйвера менее трудоемко (MCD работает только в Win­dows NT). Драйвер мини-порт предназначен для одной конкретной игры, обычно для GLQuake и Quake 2. Мини-порт может работать по принципу ICD(Rage Pro), через собственый API (например, Voodoo 2) или через Direct3D (например, Intel 740). В последнем случае он называется враппером.

API Microsoft DirectX. Этот программный интерфейс был разработан еще для операционных систем Windows 95, Windows 98 и Windows NT/2000 и др. С помощью этого API увеличивается быстродействие игр, деловой графики, трехмерного звука и т. д. Несмотря на то, что DirectX был предназначен для игр, он также используется в программах NetMeeting, ActiveMovie и NetShow. Поскольку DirectX относится к уровню аппаратных абстракций (Hardware Abstraction Layer — HAL), разработчикам программного обеспечения необходимо использовать функции DirectX, а не обращаться напрямую к видеоадаптеру, звуковой карте, джойстику и другому ап­паратному обеспечению.

DirectX также относится к уровню аппаратной эмуляции (Hardware Emulation Layer — HEL), что позволяет разработчику программно эмулировать те функции, ко­торые не реализованы аппаратным обеспечением. Уровень HEL «медленнее», чем HAL, но луч­ше иметь нереализованную аппаратно функцию (пусть даже медленную), чем не иметь ничего.

Отношения между аппаратным, программным обеспечением и DirectX можно продемон­стрировать следующей схемой:

(Аппаратное обеспечение) > (Direc+X) > (Програм­мное обеспечение).

Обновление DirectX можно выполнять независимо от операционной системы. DirectX состоит из «основного» слоя, который обеспечивает доступ к звуковым устройст­вам, устройствам двухмерной и трехмерной графики, уст­ройствам ввода и процедурам установки. Программный интерфейс DirectX содержит слой Media, который состоит из API.

Слой Media DirectX пре­доставляет сервис для разработ­чиков игр, Web и интерактивных медиа-программ. Самая последняя версия DirectX доступна для бесплатной загрузки с Web-узла фирмы Mi­crosoft. Кроме того, DirectX является частью таких продуктов, как Internet Explorer, Win­dows 2000. Некоторые производители аппаратного обес­печения поставляют вместе со своими продуктами последнюю версию DirectX. Перед инсталляцией некоторые программы проверяют номер версии установленного про­граммного интерфейса. Если установленная версия устарела, то пользователю будет предло­жено установить последнюю версию. Программный интерфейс DirectX обратно совместим, т.е. последняя версия поддерживает функции всех предыдущих. Для корректной работы всех программ необходимо использовать последнюю версию программного интерфейса DirectX.

API — графический интерфейс прикладного программирования (ликбез).

API — графический интерфейс прикладного программирования (ликбез).

Г рафический интерфейс прикладного программирования (Application Programming Interface, API) был разработан для разработчиков игровых программ. Самые первые массовые ускорители использовали Glide — API для трёхмерной графики, разработанный 3dfx Interactive для видеокарт на основе собственных графических процессоров Voodoo Graphics, а затем уже появились API OpenCL, DirectX.

На программном уровне видеопроцессор для своей организации вычислений (расчётов трёхмерной графики) использует тот или иной интерфейс прикладного программирования (API). DirectX (как и OpenGL) — это графический интерфейс прикладного программирования (API). До появления API каждый производитель графических процессоров использовал собственный механизм общения с играми, и разработчикам игр приходилось писать отдельный код для каждого графического процессора, который они хотели поддержать. Поэтому для каждой игры указывалось, какие именно видеокарты она поддерживает. Чтобы решить эту проблему, которая являлась серьезным тормозом для игровой индустрии, и был разработан API, что позволило устранить зависимость между игрой и конкретным графическим процессором. Графические процессоры поддерживали определенные версии API, а разработчики игр писали коды под определенную версию API.

Существует два основных типа API: Microsoft DirectX и OpenGL. При этом нужно отметить, что большинство игр ориентировано именно на Microsoft DirectX.

Стандарт DirectX включает API для звука, музыки, устройств ввода и т.д. За 3D-графику в DirectX отвечает API Direct3D, и когда говорят о видеокартах, то имеют в виду именно его (поэтому понятия DirectX и Direct3D взаимозаменяемы).

Стандарт DirectX постоянно обновляется. Каждая версия DirectX поддерживает определенные версии шейдеров (программ обработки вершин (Vertex Shader) и пикселов (Pixel Shader). Эти версии шейдеров называются Shader Model. К примеру, DirectX 8 поддерживает Pixel Shader от 1.0 до 1.3 и Vertex Shader 1.0, а DirectX 8.1— Pixel Shader 1.4 и Vertex Shader 1.1. В DirectX 9 поддерживаются Pixel Shader 2.0 и Vertex Shader 2.0, а в DirectX 9.0c— Pixel Shader 3.0.

Сейчас поколения ускорителей в видеокартах можно считать по версии DirectX, которую они поддерживают. Различают следующие поколения:

— DirectX 7 — карта не поддерживает шейдеры, все картинки рисуются наложением текстур;

— DirectX 8 — поддержка пиксельных шейдеров версий 1.0, 1.1 и 1.2, в DX 8.1 ещё и версию 1.4, поддержка вершинных шейдеров версии 1.0;

— DirectX 9 — поддержка пиксельных шейдеров версий 2.0, 2.0a и 2.0b, 3.0;

— DirectX 10 — поддержка унифицированных шейдеров версии 4.0;

— DirectX 10.1 — поддержка унифицированных шейдеров версии 4.1;

— DirectX 11 — поддержка унифицированных шейдеров версии 5.0;

— DirectX 12 — поддержка унифицированных шейдеров версии 6.0;

С выходом DirectX 11 и появлением модели поддержки API Feature Level (FLxx), видеокарты в большинстве своем перестали быть привязаны к конкретной версии DirectX.

Первый графический процессор с поддержкой API DirectX 10 — это NVIDIA GeForce 8800.

Версия OpenGL обозначает то, какие операции графического ускорения поддерживает данная графическая карта:

OpenGL 1.1 — Объекты текстур;

OpenGL 1.2 — 3D-текстуры, форматы BGRA и упакованных пикселей;

OpenGL 1.3 — Мультитекстурирование, multisampling, сжатие текстур;

OpenGL 1.4 — Текстуры глубины;

OpenGL 1.5 — VBO, Occlusion Querys;

OpenGL 2.0 — GLSL 1.1, MRT, текстуры с размерами, не являющимися степенью двойки, Point Sprites, Two-sided stencil;

OpenGL 2.1 — GLSL 1.2, Pixel Buffer Object (PBO), текстуры sRGB;

OpenGL 3.0 — GLSL 1.3, Массивы текстур, условный рендеринг , FBO;

OpenGL 3.1 — GLSL 1.4, Instancing, Texture Buffer Object, Uniform Buffer Object, Primitive restart;

OpenGL 3.2 — GLSL 1.5, Geometry Shader, Multi-sampled textures;

Buffer Object: FBO (Frame), VBO (Vertex), PBO (Pixel), Texture, Uniform;

OpenGL 4.0 — GLSL 4.00, Тесселяция на GPU, шейдеры с 64-битной точностью.

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

В основном инструментарий разработчика становится более дружелюбным со временем. От ассемблера к Си, от Си к C++ и тд. Но почему в мире графических API всё наоборот? OpenGL усложнялся, а Vulkan стал ещё более низкоуровневым, чем OpenGL 4.* . C DirectX та же история, от DX11 к DX12. Чем можно это объяснить, что мир прикладного ПО идёт в сторону облегчения труда разработчиков, а мир графики строго наоборот?

Werenter ★★
02.06.23 18:01:06 MSK
← 1 2 →

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

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

yu-boot ★★★★
( 02.06.23 18:07:27 MSK )
Последнее исправление: yu-boot 02.06.23 18:08:08 MSK (всего исправлений: 1)

Ответ на: комментарий от yu-boot 02.06.23 18:07:27 MSK

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

Werenter ★★
( 02.06.23 18:12:22 MSK ) автор топика
Последнее исправление: Werenter 02.06.23 18:13:16 MSK (всего исправлений: 1)

Ответ на: комментарий от Werenter 02.06.23 18:12:22 MSK

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

lenin386 ★★★
( 02.06.23 18:13:39 MSK )
Ответ на: комментарий от Werenter 02.06.23 18:12:22 MSK

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

vbcnthfkmnth123 ★★★
( 02.06.23 18:14:10 MSK )

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

lenin386 ★★★
( 02.06.23 18:15:14 MSK )
Последнее исправление: lenin386 02.06.23 18:15:44 MSK (всего исправлений: 1)

Ответ на: комментарий от lenin386 02.06.23 18:15:14 MSK

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

Werenter ★★
( 02.06.23 18:16:22 MSK ) автор топика
Ответ на: комментарий от Werenter 02.06.23 18:12:22 MSK

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

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

yu-boot ★★★★
( 02.06.23 18:21:42 MSK )
Последнее исправление: yu-boot 02.06.23 18:24:18 MSK (всего исправлений: 1)

Ответ на: комментарий от yu-boot 02.06.23 18:21:42 MSK

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

Werenter ★★
( 02.06.23 18:24:46 MSK ) автор топика

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

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

snizovtsev ★★★★★
( 02.06.23 18:54:01 MSK )
Последнее исправление: snizovtsev 02.06.23 18:57:01 MSK (всего исправлений: 3)

Ответ на: комментарий от snizovtsev 02.06.23 18:54:01 MSK

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

Werenter ★★
( 02.06.23 20:48:05 MSK ) автор топика
Ответ на: комментарий от Werenter 02.06.23 18:12:22 MSK

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

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

BceM_IIpuBeT ★★☆☆☆
( 02.06.23 20:54:48 MSK )
Ответ на: комментарий от yu-boot 02.06.23 18:07:27 MSK

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

anc ★★★★★
( 02.06.23 20:57:05 MSK )

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

ox55ff ★★★★★
( 02.06.23 21:04:00 MSK )

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

MOPKOBKA ★★★
( 02.06.23 21:10:54 MSK )
Последнее исправление: MOPKOBKA 02.06.23 21:11:33 MSK (всего исправлений: 1)

Ответ на: комментарий от Werenter 02.06.23 18:12:22 MSK

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

buddhist ★★★★★
( 02.06.23 23:40:32 MSK )
Ответ на: комментарий от yu-boot 02.06.23 18:21:42 MSK

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

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

javascript ★
( 03.06.23 00:08:19 MSK )
Ответ на: комментарий от lenin386 02.06.23 18:13:39 MSK

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

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

Nervous ★★★★★
( 03.06.23 00:12:38 MSK )
Последнее исправление: Nervous 03.06.23 00:13:59 MSK (всего исправлений: 1)

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

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

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

Norgat ★★★★★
( 03.06.23 00:24:48 MSK )

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

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

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

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

MKuznetsov ★★★★★
( 03.06.23 00:28:51 MSK )
Последнее исправление: MKuznetsov 03.06.23 00:42:51 MSK (всего исправлений: 1)

Ответ на: комментарий от BceM_IIpuBeT 02.06.23 20:54:48 MSK

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

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

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

skyman ★★★
( 03.06.23 00:57:54 MSK )
Ответ на: комментарий от Nervous 03.06.23 00:12:38 MSK

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

MOPKOBKA ★★★
( 03.06.23 01:27:33 MSK )
Ответ на: комментарий от skyman 03.06.23 00:57:54 MSK

quwy
( 03.06.23 02:10:22 MSK )

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

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

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

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

Aber ★★★★★
( 03.06.23 02:40:07 MSK )
Ответ на: комментарий от skyman 03.06.23 00:57:54 MSK

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

mrdeath ★★★★★
( 03.06.23 03:43:45 MSK )
Ответ на: комментарий от skyman 03.06.23 00:57:54 MSK

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

BceM_IIpuBeT ★★☆☆☆
( 03.06.23 06:30:21 MSK )
Последнее исправление: BceM_IIpuBeT 03.06.23 06:36:25 MSK (всего исправлений: 1)

Ответ на: комментарий от Aber 03.06.23 02:40:07 MSK

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

Werenter ★★
( 03.06.23 08:02:48 MSK ) автор топика
Ответ на: комментарий от ox55ff 02.06.23 21:04:00 MSK

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

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

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

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

Werenter ★★
( 03.06.23 08:22:20 MSK ) автор топика
Последнее исправление: Werenter 03.06.23 08:23:22 MSK (всего исправлений: 3)

Ответ на: комментарий от Werenter 03.06.23 08:22:20 MSK

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

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

dataman ★★★
( 03.06.23 08:27:31 MSK )
Ответ на: комментарий от dataman 03.06.23 08:27:31 MSK

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

Werenter ★★
( 03.06.23 08:31:13 MSK ) автор топика
Последнее исправление: Werenter 03.06.23 08:31:33 MSK (всего исправлений: 1)

Ответ на: комментарий от dataman 03.06.23 08:27:31 MSK

dataman ★★★
( 03.06.23 08:57:24 MSK )
Ответ на: комментарий от Werenter 03.06.23 08:02:48 MSK

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

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

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

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

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

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

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

Siborgium ★★★★★
( 03.06.23 09:19:55 MSK )
Ответ на: комментарий от BceM_IIpuBeT 03.06.23 06:30:21 MSK

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

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

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

skyman ★★★
( 03.06.23 09:24:05 MSK )

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

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

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

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

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

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

Siborgium ★★★★★
( 03.06.23 09:28:14 MSK )
Ответ на: комментарий от Siborgium 03.06.23 09:19:55 MSK

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

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

Werenter ★★
( 03.06.23 09:30:56 MSK ) автор топика
Последнее исправление: Werenter 03.06.23 09:31:03 MSK (всего исправлений: 1)

Ответ на: комментарий от Siborgium 03.06.23 09:28:14 MSK

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

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

Werenter ★★
( 03.06.23 09:35:13 MSK ) автор топика
Ответ на: комментарий от Werenter 03.06.23 09:30:56 MSK

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

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

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

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

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

Siborgium ★★★★★
( 03.06.23 09:38:34 MSK )
Ответ на: комментарий от Werenter 03.06.23 09:35:13 MSK

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

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

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

Siborgium ★★★★★
( 03.06.23 09:42:46 MSK )
Ответ на: комментарий от Werenter 03.06.23 09:30:56 MSK

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

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

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

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

dataman ★★★
( 03.06.23 09:54:31 MSK )
Ответ на: комментарий от Siborgium 03.06.23 09:42:46 MSK

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

Werenter ★★
( 03.06.23 09:55:15 MSK ) автор топика
Ответ на: комментарий от dataman 03.06.23 09:54:31 MSK

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

Werenter ★★
( 03.06.23 09:56:08 MSK ) автор топика
Ответ на: комментарий от Werenter 03.06.23 09:55:15 MSK

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

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

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

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

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

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

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

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

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

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

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

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

Siborgium ★★★★★
( 03.06.23 10:13:19 MSK )
Последнее исправление: Siborgium 03.06.23 10:13:53 MSK (всего исправлений: 1)

Ответ на: комментарий от Werenter 03.06.23 09:56:08 MSK

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

dataman ★★★
( 03.06.23 10:14:04 MSK )
Ответ на: комментарий от Werenter 03.06.23 08:22:20 MSK

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

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

ox55ff ★★★★★
( 03.06.23 11:31:56 MSK )
Ответ на: комментарий от ox55ff 03.06.23 11:31:56 MSK

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

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

Werenter ★★
( 03.06.23 11:58:59 MSK ) автор топика
Последнее исправление: Werenter 03.06.23 12:01:46 MSK (всего исправлений: 1)

Ответ на: комментарий от Werenter 03.06.23 08:02:48 MSK

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

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

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

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

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

Aber ★★★★★
( 03.06.23 12:17:40 MSK )
Последнее исправление: Aber 03.06.23 12:18:50 MSK (всего исправлений: 2)

Ответ на: комментарий от Siborgium 03.06.23 09:28:14 MSK

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

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

gag ★★★★★
( 03.06.23 13:23:27 MSK )
Ответ на: комментарий от Werenter 03.06.23 09:56:08 MSK

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

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

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

gag ★★★★★
( 03.06.23 13:38:11 MSK )
Ответ на: комментарий от Aber 03.06.23 12:17:40 MSK

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

Werenter ★★
( 03.06.23 13:41:48 MSK ) автор топика

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

NorthernBlow ★
( 03.06.23 14:00:13 MSK )

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

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

KivApple ★★★★★
( 03.06.23 14:03:26 MSK )
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score ← 1 2 →

Похожие темы

• Новости Valve: Vulkan лучше чем DirectX 12 (2015)
• Форум Vulkan API сегодня (2016)
• Форум Вакансия Render/Graphics Engineer (C++, remote) в Mirror AI (2021)
• Новости Khronos Group анонсирует Vulkan, наследника OpenGL (2015)
• Новости Выпуск спецификации OpenGL 4.6 (2017)

• Форум Пишу «принципиально новый» (:D) 3D графический движок (2018)
• Новости Свободная графика для RISC-V (2021)
• Форум AMD представила мобильные чипы Kaveri (2014)
• Новости Представлен open-source драйвер Vulkan для видеокарт NVIDIA (2023)
• Форум Gentoo и хипстерские графические API (2016)