Создание графических приложений
Цилюрик О.И.
Настоящая статья является дополнением к книге «Инструменты Linux для Windows-программистов». Это не описание как делать GUI приложения в Linux, это описание того, как ПРИСТУПИТЬ к созданию графических приложений в Linux, и, хотелось бы надеяться что это прозвучит — чем принципиально программирование графики в Linux отличается от того же занятия в Windows. Главным требованием здесь была простота. Сделав простейший шаблон GUI прложения, дальше двигаться уже гораздо проще. Кроме того, все эти простейшие приёмы программирования показаны сравнительно: на основе основных графических технологий (библиотек), используемых в UNIX.
Все примеры к тексту вы можете скачать в виде общего архива.
Создание приложений, взаимодействующих с пользователем посредством графического интерфейса (GUI приложений), является частным классом задач, отдельной областью программирования. Из числа других подобных областей приложения можно было бы привести, как примеры:
- реализация алгоритмов цифровой обработки сигналов (DSP): быстрые спектральные преобразования (FFT и другие), вэйвлеты, авторегрессионные разложения. ;
- обработка аудио-потоков (пакеты: sox, ogg, speex и другие);
- задачи IP-телефонии, SIP протокола, реализация разнообразных программных SoftSwitch;
Это сравнительный ряд автономных областей развития приведен как пример таких частных классов, одним из которых является и разработка GUI приложений. И как частный класс, со своей спецификой инструментов и средств, он не заслуживал бы отдельного упоминания, если бы не одно обстоятельство — принципиально отличающееся, диаметрально противоположное отношение к GUI в операционных системах семейства Windows и в UNIX (и в Linux, как его частный вид):
- В Windows каждое приложение является принципиально GUI, неотъемлемым атрибутом любого приложения в Win32 API (низкого уровня) является главное окно приложения, уже само приложение «вяжется» вокруг его главного окна. Операционная система регистрирует классы окон и уже далее к ним соотносит конкретные приложения. Не может существовать приложения (взаимодействующего с пользователем, не системные службы) без окна, с этим были связаны и первоначальные сложности Windows в реализации консольных (терминальных) приложений.
- в UNIX картина принципиально обратная: первичным является приложение, которое, по умолчанию, является консольным, текстовым, вся графическая система не является составной частью операционной системы, а является надстройкой пользовательского уровня. Чаще всего такой графической надстройкой является X11 (в реализации Xorg или X11R5), но и это не обязательно: практиковались и другие графические системы, хороший пример тому графические системы Qwindow, а затем Photon в операционной системе QNX, сосуществующие там одновременно с X11.
- Показательно в этом смысле то, что вся оригинальная часть реализации X11 работает в пространстве пользователя, не в привилегированном режиме ядра (супервизора): работа с аппаратурой видеоадаптеров, устройствами ввода и другое. Отдельные реализации (видеосистемы NVIDIA или ATI Radeon) могут быть реализованы в режиме ядра (модули), но это а) сторонние относительно X11 разработки, и б) решение вопросов только производительности.
Из-за обозначенной специфики, разработка GUI приложений в UNIX (Linux) принципиально отличается:
- вся работа GUI приложений ведётся через промежуточные слои (библиотеки) пользовательского уровня;
- из-за того, что это ординарный пользовательский уровень, для разработчика предлагается широкий спектр альтернативных инструментов (библиотек), практически равнозначных, и конкурирующих друг с другом: Xlib, GTK+, Qt, wxWorks и многие другие.
- базовый API работы с X11 предоставляет Xlib, все другие используют уже её функционал, как это показано на рисунке.
- разработчик имеет возможность широкого выбора тех уровня и инструментов, которые он предполагает использовать, начиная от Xlib и выше (хотя уровень Xlib и слишком низок и работа с ним громоздкая).
Из-за названной специфики GUI приложений в Linux, все они, независимо от используемых средств создания, имеют абсолютно сходную структуру. Рассмотрим, для сравнения, код нескольких простейших GUI приложений, подготовленных с помощью различных инструментов. Важнейшей задачей такой экспозиции будут команды компиляции и сборки, чтобы, исходя из таких примеров, показать возможность начать создавать свои собственные GUI приложения.
Средства Xlib (архив Xlib.tgz ):
Средства GTK+ (архив GTK+.tgz ):
$ gcc gtk.c -o gtk `pkg-config —cflags —libs gtk+-2.0`
Средства Qt (архив Qt.tgz ):
Средства Qt предполагают написание приложений на языке С++, и имеют развитый инструментарий, в частности, построения сценария сборки приложения. Создадим в рабочем каталоге (изначально пустом) файл исходного кода приложения с произвольным именем:
Теперь проделываем последовательно:
Исходя из «подручных» файлов исходных кодов, у нас сгенерировался файл проекта и, далее, сценарий сборки ( Makefile ). Далее проделываем традиционную сборку, а заодно и посмотрим опции компиляции и сборки, которые нам сгенерировал проект:
g++ -c -pipe -Wall -W -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector —param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables
g++ -o Qt index.o -L/usr/lib/qt-3.3/lib -lqt-mt -lXext -lX11 -lm
index.cc index.o Makefile Qt Qt.pro
Средства wxWidgets (архив wxWidgets.tgz):
$ g++ simple.cc `wx-config —cxxflags` `wx-config —libs` -o simple
Средства GLUT (архив glut.tgz):
OpenGL Utility Toolkit, как и следует из названия, это средства использования технологии OpenGL в приложениях, которая требует определённой поддержки со стороны видео оборудования.
$ gcc glut.c -o glut -lX11 -lglut
То, что показано выше, это фактически не приложения, а скелеты приложений, но они позволяют: а) сравнить подобие всех GUI технологий в X11, и б) быть отправной точкой для сборки более содержательных GUI приложений. Показано только несколько GUI технологий, применяемых в X11 (большинство из них являются кросс-платформенными, и применимы в большинстве существующих операционных систем). Каждая из этих технологий, а названы только немногие из значительно большего числа, присутствующих в UNIX, могут быть полной альтернативой любой другой из этого же ряда, они взаимно заменимы, и даже взаимно дополняемые.
В данной статье были показаны образцы кода GUI приложений. Естественно, визуальные образы таких приложений строятся не путём непосредственного кодирования, а при использовании некоторых визуальных построителей, в составе тех или иных интегрированных средств разработки (IDE).
Графические библиотеки для C (3D, 2D)
В общем, что на сегодняшний день релевантно в области графических библиотек (3D, 2D) для C? На данный момент щупаю OpenGL. Может стоит сначала разобраться в OpenGL, а потом переходить на какой-нибудь SDL2 (для 2D, а для 3D оставить OpenGL)
Я думаю, писать подобное на С на сегодняшний день совершенно нерелеванто. Хотя бы потому, что в случае с SDL2 придётся переизобретать на C то, что люди давно написали на плюсах в SFML (графическое API которого — плюсовая обёртка над OpenGL, те же шейдеры использовать очень удобно).
Зачем тебе opengl если собираешься переходить на sdl? А еще есть вулкан. Че делать то собрался? Если для изучения комп графики, забудь про sdl и прочие врапперы.
Может стоит сначала разобраться в OpenGL, а потом переходить на какой-нибудь SDL2
SDL2 можно освоить за вечер, а OpenGL это любовь на всю жизнь 🙂
Любовь с первого взгляда?
Ну интерес у меня больше академический, чем практический
У меня скорее академический интерес, поэтому что то переизобретать я не боюсь
SDL2 изучай, тебе все равно окно для OpenGL создавать чем то надо. Хотя я хз зачем тебе такие низкоуровневые либы.
Ну в таком случае, с помощью OpenGL можно и всякие двухмерные вещи рисовать без каких-либо проблем. А на SDL2 переложить создание окна, OpenGL контекста, обработку ввода, кроссплатформенный I/O и т.д.
Значит смотри на 10-15 лет вперед. Я серьезно. Ray tracing, алгоритмы, развитие железа, там много направлений. Дохрена чего. Убить кучу времени на опенжеле ты всегда успеешь. Получишь незабываемых впечатлений, это да. Конечно, может и стоит немного времени на это потратить, но не зацикливайся.
А sdl это спрайты двигать, утилитарщина одним словом.
SDL2 изучай, тебе все равно окно для OpenGL создавать чем то надо.
Я пока использовал GLUT для создания окон.
Хотя я хз зачем тебе такие низкоуровневые либы.
Узнать как все это работает под капотом. Чтобы понимать, как устроен sdl
Взгляни на Corange. Ничто не мешает использовать SDL как просто инициализатор контекста, а всё остальное делать без призязок к нему.
Изучай OpenGL спокойно, а SDL используй просто как упрощение своей жизни. Открыть окно, получать эвенты, всё то что к OpenGL отношения не имеет, но также всё то что делает изучение удобнее. Ты же хочешь вывести квадратик на экран и двигать его мышкой? Ну так выводит через OpenGL, а двигай через SDL. Это два API которые дополняют друг друга, а не заменяют. И да можешь смело просто не использовать функции типа SDL_GLblablabla это всё опционально и не обязывает ни к чему.
Хм, да, надо будет почитать про это на досуге.
Спасибо за такой развернутый ответ. А что можете сказать про Vulkan? Стоит его трогать?
P.S. Если честно, ждал вашего ответа, так как иногда видел ваши работы и удивлялся им. Можно ли где-то найти ссылку на ваш гитхаб? Было бы очень интересно посмотреть на ваш код.
Если задача не только движки для игрушек делать, то ещё взгляни на физически корректный рендеринг.
Вот известный материал по этому. (pdf).
Весьма интересно, но помимо этого нужно оптику осилить, если профессионально заниматься решишь.
Выглядит очень интересно. За пдфку спасибо, будет что почитать скучными вечерами.
Не надо недооценивать SDL. Про спрайтодвигатель это вообще лол. Он просто даёт тебе аппаратно ускоренное API для 2D графики, а что ты будешь там рисовать дело десятое хоть спрайты хоть всю десткопную графику выводить.
Ида это фундаментальная «утилитарщина» именно благодаря которой можно удобно и практично изучать алгоритмы, развитие железа и рейтрейсинг (тебя маркетологи покусали? ахах, это вещи которым 100 лет уже)
На OpenGL вообще зацикливатся не надо. Текстуры, буферы, шейдеры в удобных обёртках под себя и вуаля рисуй что хочешь и как хочешь. Весь OpenGL знать не надо. Надо только то чем ты будешь пользоваться, а это чаще всего лишь десяток функций и десяток констант и всё.
Ты как то завуалировано предлагаешь ему использовать готовые движки.
За вечер такое вряд ли осилишь (или кто-то осилит вообще), но я видел примеры самописных движков у которых получалось.
UPD: Ещё интересно выглядит Lisp в компьютерной графике, за счёт того что можно писать красивые анимации в красивом коде IMHO. Вот примеры 1, 2.
И ещё потому что программа изменяется прямо на ходу без перезапуска.
Поскольку у тебя Haskell и Emacs в подписанных тегах, то тебе это будет весьма занимательно.
Нубские туториалы по графике есть только для опенжоеля/d3d. Но для «Узнать как все это работает под капотом» очевидно курят и вулкан, да и после вкуривания опенжоеля 3+ особого труда не составит.
Ничего адекватного для 3D нет. Для 2D хоть отбавляй.
ро спрайтодвигатель это вообще лол.
man образное выражение
Ты как то завуалировано предлагаешь ему использовать готовые движки.
Я ему завуалировано предлагаю забить на opengl и sdl (что рано или поздно произойдет и так, если он не собирается быть граф программистом), и вместо этого просто посмотреть на перспективы. Скорее всего он просто не знает что делать (исходя из ОП). Втыкание в экран на котором плавает треугольник эту проблему не решит. А интерес, как он написал у него академический. Но т.к. он скорее всего школьник или первокурсник, то я даже ванговать не буду что он сделает в конце концов.
удобно и практично изучать алгоритмы, развитие железа и рейтрейсинг
да, особенно развитие железа : ) но скажем так, пользы их я и нигде не отрицал
Если первое — твоё железо и дрова его могут и второе — если ты готов смирится что твой код не будет работать на железе 5ти летней давности и свободных дровах. Ну то есть у меня Radeon HD 6850 я катаю в csgo (OpenGL версию нативную) но не смогу даже с проприетарными дровами запустить ничего на Vulkan ибо там сделанно всё что бы сделать железо прошлых поколений просто нерабочим причём намеренно. Но Vulkan позволит тебе то что OpenGL делает за тебя делать руками. Ну например в OpenGL ты говоришь вот тебе массив вершин вот тебе шейдер и вот тебе текстуры -> рисуй. В вулкане ты говоришь вот тебе массив вершин вот блок текстур вот индекс вот устройство вот последовательность рисвоваания вот тебе банк памяти (ещё пяток всего при полном контроле) -> рисуй. Короче то что в OpenGL делает драйвер в вулкане это делается руками. Если у тебя супералгоритм какой то да ты более свободен. Если тебе нужно как и всегда было нужно рисовать по правилам которые ты установил в шейдере и всё и тебя не заботит как будет видеокарта с памятью разруливать траблы то OpenGL.
Это на ютубчике чтоль? =)
Ну на гитхабе у меня пусто считай я по сути сам учился на коде Corange https://github.com/orangeduck/Corange можешь там issue и пул-реквесты глянуть (fedor-elizarov это я там) закрытые я туда пару демок пропихнул в том числе некоторое которое есть на ютубчике. Возьми к примеру демку с чайником, там по сути всё в одном. Даже основной рендер не используется. А в демке parallax типа продвинутые шейдеры и ты можешь с ними играться как угодно (например вот тебе задачка взять эффект из shadertoy и запустить его на corange =))
Клонируй Corange запускай демки и смотри как они работают. Потрать время и разберёшься. А потом либо чисто своё начнёшь либо просто за основу коранж можно взять.
Что бы просто не терятся в терминах и не грузится лишним можно глянуть сюда https://learnopengl.com/ на хабре есть переводы
сюда http://steps3d.narod.ru/articles.html на gamedev.ru статьи посмотреть. Не что бы зазубривать ТООООННЫ иныф нененене. Просто ради интереса и фана поглазеть (даже если нихрена не поймёшь оно уже будет на слуху и не будет пугать)
Не старайся заучивать всё прям изучааать там. Практика и только она и лучший способ это взять готовое и глянуть как оно работает чтобы избежать всяких непоняток.
Лично я OpenGL знаю нуууу 1% где то. Но лично мне этого хватит чтобы отрисовать что угодно как угодно и на чём угодно с расчётами хоть на CPU хоть на GPU. Да и программистом я не являюсь. Чисто любитель.
И да, ещё раз читай всякие статьи. Обычно их пишут в весёлой манере. Но это лично из своего опыта что бы подогревать интерес и не пугаться непонятных слов которые в сути своей являются как оказывается вполне обычными вещами.
Ну, а так. Бури и кодируй. Создал окно. Узнал как получить тектуру, узнал как загрузить буфер вершин, узнал как написать шейдер и потом как запустить всё это вместе и это 99% фундаментального кода которое ты опишешь 1 раз а потом только разве что коректировать будешь.
Короче дерзай. Главное практируй что-бы видеть результаты и радваца что квадратик рисуется, пусть маленький пусть кривой, пусть непонятно чё с ним делать но он твой бляха муха цикатуха! и всё тут. Короче играйся больше с кодом.
PBR не стоит упоминать на ранних этапах обучения графике. Он реализуется при должных знаниях за 1 день в 1 шейдере. Да и если честно PBR это эмммм. Это тупо хайп. Внезапно появившаяся философия того что надо рисовать как в жизни. Типа тренд. А в сообществе игровых движков сразу типа — «Нет пайплайна для PBR ты лох и твой ивиг тоже лох, фуууу днищеее» и всё такое.
Настоящий PBR в том виде который он должен быть никто включая юнриал, юнити,крайтеки не используют ибо это красивое в теории да на словах. А на деле памяти под это всё надо до жопы поэтопу все делают так что результат как в PBR а на деле подходы разные.
И ваще это больше к созданию контента, всё дело в текстурах, если раньше дифуз + нормаль ну и ещё моожет быть спекуляр и всё то сейчас минимум 6 текстурных карт на объект. Да их упаковывают но всё же.
Хотя просто почитать про это всё интересно. Это да.
Так для игр его и не стоит применять, это для фильмов, и для 3d анимации. Если ты смотрел Короля Льва 2019 года, то там эта технология реализована. Лучше графики чем в нём, ещё не видел.
Не стоит применять? Это наибольший реальный буст к графонию в игорях, по сравнению ним все остальные графические фичи говно полное, чисто греющее видеокарту впустую.
Вот когда твоя видеокарта будет тянуть его в Real-Time, то ради Б-га. А так на современных видеокартах только недавно Ray Tracing начали внедрять.
Ну, одну две недельки поковыряется и решит. Да я остаюсь на C+SDL2+OpenGL2/3/4 или Нет мне надо что-то повыше уровнем.
В любом случае зайди на любой форум где люди делают игры и прочее с графикой, очень часто даже используя движки они вынуждены спускаться на уровень чистого OPENGL или узнавать что-то о SDL который как подсистема встроен почти во все AAA даже движки как прослойка. Работает жрать не просит. Вон Gamedev_ru тему начинают как префаб в юнити использовать, а заканчивают какой уровень мипмапа устанавливать для новой текстуры и какую разрядность установить для Depth текструры Gбуфера 😀 Что по итогу к юнити никакого прямого отношения не имеет в плане интерфейсов, но даёт понимание почему жрётся память и то или иное возможно или невозможо. Короче вреда он точно не получит.
Я тебе открою тайну PBR использовали ещё до появления термина как такового. Сразу же как только позволила видеопамять. Ещё во времена первых крузисов =) Просто тогда это не выделяли в нечто отдельное и применялось только к оружке и подобному что в глаза тыкается =)
Нашёл твой канал но YouTube и весьма заинтересовался EGNAROC. На гите у тебя репозитория не нашёл.
Ууууу, да нифига подобного. Посмотри любой доклад по геймдеву начинают за блюпринты и мышевозие заканчивают про ручной заход солнца с побитовыми манипуляциями памяти и бенчмарками фандаментальных вызовов графических API с сотней нюансов и хаков =) шобы пропихнуть графон в лимит филрейта видюхи. И по итогу для общих случаев да выбирают готовые обёртки, а для 90% всего остального выбор либо топать в библиотеку ассетов где всё додумали заместо тебя и выложить доллары денег либо опускаться в фундаментальщину и писать всё самим что чаще всего и делают. И тут внезапно надо уметь знать как оно там работает в реальности. Потому что в ряде случаев надо под свои потребности сам SDL править =) Да и часто если выбирают для графона C++ то пишут по итогу всё равно на С потому что плюшки плюшками, а кадр 16 мс и выкручивайся как хочешь. А сейчас ваще по хорошему над на кадр 7мс надо ибо у людей герцовка и они требуют, я уж молчу про экшоны где на кадр в идеале хотят
3-5мс а в игре 10 подсистем и на каждую бюджет уже наносекунд по итогу. И сидишь такой. Смотришь на все эти менстрим технологии десктопо строения и плакаешь от зависти — как же они счастливы можно целую секунду думать после нажатия кнопки в интерфейсе! 😀
EGRAROC это форк CORANGE 😀
Исходников нет, я делаю игру и затачиваю форк специально под игру. Некоторые приколюхи изредка возвращаю обратно в Corange правлю там баги и добавляю демки.
Но у меня подход к движку другой Сorange идеальный для старта затачивания под себя. Будет время предложу динамические отражения, более продвинутые частицы, анимированные текстуры, воспроизведение видео через собвственный примитивный но быстрый видеокодек, реализацию gui контейнеров для мышевозного создания ui элементов и так далее включая компиляцию в 1 файл вместе со всеми зависимостями и ресурсами игровыми. Всё это и ещё некоторое есть но находится в ужасном состоянии. Выкладывать такое стыдно. Доработаю. Доделаю игру. Выпущу в Steam. Отшлифуется предложу Даниэлю свои фичи, может примет что-то. А так у меня нет желания выкладывать EGNAROC в опенсорс во первых кроме меня он нахрен не нужен никому, он по сути полигон где я каждый день ломаю обратную совместимость с самим собой и Corange уж подавно. Я так и оставлю его чисто для себя и своей игры. А 100% рабочие вещи буду портировать обратно в Corange по возможности. Да и вообще я заболел концепцией ECS и тотальной оптимизации всего и вся и тут некоторая архитекрура уже мне не нравки, если решусь то буду делать с нуля микродвиг на тотальном ECS. Тогда просто выкину все наработки EGRAROC и забуду про него. Но пока здравый смысл меня останавливает.
Короче, всё что ты видел на ютубчике можно сделать на Corange, параллакс я уже добавил, работу с физикой тоже, работу с gui тоже,для всего этого есть демки там, в issue есть код для реализации SSLR. Ну, а остальное lua скриптинг к примеру у меня есть но на зачаточном уровне. Всё это валом на одного меня откровенного быдлокодера тяжело. Да и делается всё не по приколу а чисто для игры. Хотя… почему не по приколу, по приколу конечно =) Но сутьв том что я всеми силами стараюсь делать именно игру, а не бесконечно пилить ещё один двиг
Ахаха. Ты даже подписался =) Мама я ютуер ТЫШЬ табуреткой по голове мааааааам не бей меня мааааааам ))))))))
Через месяц пресс релиз моей игры…. Будешь ржать если увидишь ахаха. И я настолько наглый что выйду с ней в ситим Габеееен пасиба за билетики в библиотетики =)
Ахаха. Ты даже подписался =) Мама я ютуер ТЫШЬ табуреткой по голове мааааааам не бей меня мааааааам ))))))))
Через месяц пресс релиз моей игры…. Будешь ржать если увидишь ахаха. И я настолько наглый что выйду с ней в ситим Габеееен пасиба за билетики в библиотетики =)
Разве кроме демок ещё что-то есть?
Пока нету. Да я так полушутя в целом. Есть куча наработок, которые начал, но не доделал. Короче ладно фиг со всем этим.
Основная суть в том что Corange топ если хочется С/SDL/OGL то рекомендую. Благо он устроен так что можно удобно выкидывать ненужное и добавлять своё.
А видосы это просто помойка когда надо скинуть что-то разок показать не более.
К слову на этом форуме касательно этой темы лучше не на меня внимание обращать, а на 
EXL eagleivg i-rinat и подобных и не стесняться их кастовать по вопросам 😀 Они в отличии от меня реальные вещи делали, а не полувымышленые
Ну, не знаю почему, но ваши сообщения, в интересных для меня тредах, я видел чаще, поэтому я точно знал, что вы знаете что к чему. Ну и как-то неловко людей кастовать для такого нубского треда.
Если для саморазвития, то лучше учи OpenGL, на хабре есть серия обучающих статей. SDL2 — это не для 2D рисования (несмотря на то что рисовать спрайты им можно), а для кросс-платформенных вещей типа ввода, звука, первоначальной инициализации, управления окнами и прочего. Ну и плюсую сюда уже упомянутый COrange — легкий для изучения движок начального уровня.
Лично мне opengl нужен для отображения картинок (как натянутую на прямоугольник текстуру) и иногда 3d. Поэтому GLUT мне за глаза хватает (правда, для 3d нужно иногда применять VBO или как они там).
Как это народ еще не начал орать: «шейдеры учи»?
Ну интерес у меня больше академический, чем практический
тогда тебе хватит книжки по матосновам комп. графики 🙂
Очередной самозванец-эмитатор (п)эдика?
на железе 5ти летней давности и свободных дровах
gcn 1.0 вышла в 2012 году, и в ней есть vulkan (хоть и помечен эксперементальной возможностью). Это уже почти 8 лет
terascale окончательно похоронили в 2013, последние незатычки на terascale вышли в 2011, а твоя 6850 вообще 2010 года.
там сделанно всё что бы сделать железо прошлых поколений просто нерабочим причём намеренно
ога, намеренно не доложили в видеокарту 64битные вычисления, в 2010 году-то. OpenGL 4 тоже намеренно поломали?
btw, David Airlie пытается там реализовать эмуляцию 64битных вычислений — можешь пойти помочь человеку отполировать код, да потестировать
это разом бампнет версию OpenGL с 3.3 до 4.3 на твоей видеокарте. А там глядишь и до 4.6 недалеко, который совместим по требованиям к железке с vulkan
Если … тебя не заботит как будет видеокарта с памятью разруливать траблы то…
лучше взять готовый движок, умеющий в современное api
Так почему амуде тыкваит видеокарты дровами, не реализуя там вулкан для старых карт и кидает своего потребителя?
а что собираемся рисовать ? цель-то какая..
Я про вендора говорил, в свободном исполнении да завести возможно, работы идут я пытался вникнуть (был тред где я пытался углубится) но по итогу максимум я не тестирование осилю. И да одна из целей Vulkan именно вывоз нового железа на рынок. Не главная, но цель есть. И это факт отрывать слитый список рассылки комиссии не буду 100 лет назад видел. 6850 да вышла при царе горохе, только вот продавалось оно через редбендинг чуть ли не до сегодняшнего времени как эконом вариант. В том и суть. Вот именно это и присикаеться это даже хорошо.
Я не имею ничего против современных ништяков, но если хочется и древнее железо и современное то ГЛ3/2 самое то. Если хочется всех благ и железо позволяет то большой смысл ГЛ4.6 или сразу Вулкан.
Решать ТС, а я предупредил, что в случае Вулкана особенно на линуксах особенно на свободных дровах оринтироватся нужно только на новое железо. Да и в целом если у него академический интерес по 3d графике то API это десятое дело выберет то что ему удобнее основные принципы одни и теже. Подход к реализации просто разный.
И да одна из целей Vulkan именно вывоз нового железа на рынок.
это можно сказать про любое api, в тч ogl2, ведь он поломал Radeon R100/R200
6850 да вышла при царе горохе, только вот продавалось оно через редбендинг чуть ли не до сегодняшнего времени как эконом вариант
6850 никогда не ребрендилась
возможно ты путаешь с 5450 или 6450. У них есть поддержка ogl3 и dx10/dx11, но она им никуда не всралась — нет мощности
Я не имею ничего против современных ништяков, но если хочется и древнее железо и современное то ГЛ3/2 самое то.
для не3D-приложений всё что выше opengl es2 в принципе не всралось, а по-хорошему и gles 1.1 достаточно
Почему именно он? Если в двух словах, то в чём его достоинства и недостатки?
С ним познается сегфолтно-ориентированное программирование.
Сишный синдром утёнка.
Все базовые функции любого современного движка на месте (кроме редактора вестимо) Отложенный рендеринг, перезагрузка ресурсов, простые форматы данных без завистмостей кроме SDL2. Написано так что всё не переплетено, а просто расширяет друг друга, структура проекта такая что легко выкидывать ненужно и дополнять нужное. Всё явно и прозрачно. Ну и сам язык С предрасполагает к этому. Идеален для заточки под что-то конкретное это и плюс и минус. Идеален для изучения работы с 3D, не большой. Интересно его изучать.
- 3D форматы obj,ply,smd
- Скелетная анимация smd (с особенностями)
- Поддержка обработки коллизий (тела коллизий в виде obj моделей)
- LUT цветокоррекция с возможностью импорта кривых acv а также своего формата (просто 3D текстура)
- Генератор ландшафта через карту высот
- Текстуры загружаются из TGA,BMP,DDS
- Bitmap шрифты
- Частицы (спрайтовые) Ну и бла бла бла остальное тоесть если хочется простенькую игру без допила движка то можно просто поиграться.
Минусы, тонна багов. Не заточен под скорость, даже наоборот. Придётся вручную править двиг для получения желаемого. Нет документации, нужно читать код. Ну я не программист мне это не доставляет огромных проблем так что не критично код понятный. Нет редактора.
Если брать его как он есть это просто библиотека где ты можешь очень легко взять obj модельку
Но можешь забыть всё вышесказанное Коранж это если ты хочешь — На С писать игру где самые основные вещи уже есть и можно просто дёграть функции не понимая как что рботает, но одновременно при это иметь возможность делать восход солнца руками тогда когда хочется без утопания в тонне непонятного кода и или если тебе интересно как всё на самом деле работает внутри и ты хочешь возможно не только понять, но и привнести свои идеи так что-бы инструмент тебя вообще принципиально никак не ограничивал со всеми плюсами и естественно минусами
Если хочется движок типа взял и просто работаешь с ним это мимо. Даже не смотри в его сторону. Если хочешь сделать софт или игру где всё должно быть заточено и ничего лишнего. Бери выкидывай всё лишнее и затачивай.
Но ещё раз если у тебя есть уже идея игры то АХТУНГ влика вероятность что вместо написания игры ты увлечёшься переписыванием движка и игра RIP табличку сделает.
Тут много оговорок и но как для плюсов так и для минусов. Так как если уж по прямому этот двиг не для игр а для экспериментов с компьютерной графикой. Но я свой форк перепиливаю потихоньку. Мне норм =) Хотя может тоже оставлю его как просто фор-фан и буду дальше экспериментировать, а игру перенесу на godot попозже. Не знаю.