Некоторые мысли о SDL + Qt + OpenGL для игрового движка - PullRequest
3 голосов
/ 10 марта 2012

Я исследовал идеальные части для игрового движка, который я создаю.Сначала я пытался просто начать с нуля и писать все с нуля, используя лишь небольшое количество нативных библиотек, таких как Win32, X11, OpenGL, Glew, GLX и т. Д.

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

Итак, я собираюсь написать игровой движок с использованием OpenGL + SDL + Qt.Причина, по которой я хочу использовать SDL со всем этим, заключается в создании контекста и поддержке инициализации OpenGL.Мне нравится реализация Qt (по большей части), но, честно говоря, я предпочитаю SDL.Моя основная идея - использовать Qt для разработки строго графического интерфейса пользователя (например, внутриигровые меню, отладочные консоли, рендеринг HUD и т. Д.).

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

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

Некоторые мысли

  • Мне нравится голая реализация OpenGL, а не Qt, главным образом потому, что я чувствую, что у меня больше контроля.

  • Я предпочитаю иметь больший контроль над главным циклом, поэтому я использую что-то вроде SDL, а не реализации Qt - проблема в том, что я не уверен, рекомендуется ли это на самом деле, учитывая, насколько отличаетсяэти два.

В общем, я уверен, что некоторые люди скажут мне просто использовать QWidget и пусть так и будет.Дело в том, что я относительно новичок в графическом программировании в целом и чувствую, что изучение оригинального API через raw opengl было бы лучшим подходом.Однако, если я ошибаюсь, тогда я определенно хотел бы знать.

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

Кажется, что это определенно сложная тема для объективности, поэтому я сформулирую критерии с точки зрения гибкости и поддержки OpenGL + GUI, поскольку это действительночто мне нужно.

Ответы [ 2 ]

6 голосов
/ 10 марта 2012

А потом я понял, что это займет вечность только для игрового движка.

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

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

Моя главная идея - использовать Qt для разработки строго графического интерфейса

Не совсем хорошая идея.Хотя можно интегрировать Qt в SDL и использовать сигналы / слоты (предоставляя пользовательский цикл событий в сочетании с циклом событий SDL), таким образом вы не получите доступ к виджетам Qt в полноэкранном приложении.В полноэкранном режиме все блокируется, поэтому для использования Qt 4 для внутриигрового графического интерфейса весьма вероятно, что вам придется разрабатывать свой собственный графический интерфейс на основе Qt для SDL с нуля.Хотя это можно сделать, это займет время.У вас не будет этой проблемы, если приложение не является полноэкранным, хотя графический интерфейс Qt не совсем подходит для этого сценария.Имеет смысл интегрировать Qt 4 в приложение SDL, чтобы получить доступ к QFont / QSharedPointer / QString и аналогичным классам «нижнего уровня», но если вы планируете интегрировать QWidget, то это того не стоит.Есть несколько теоретически возможных способов (я не пробовал) заставить Qt подчиняться и заставить его виджет рисовать себя на экране SDL, но я думаю, что это не стоит усилий - решение будет либо слишком сложным, либо слишком неэффективным,или будут иметь серьезные ограничения.

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

Что бы я хотел знать, если это хороший подход,

Интеграция Qt 4 в SDL для использования Qt 4 GUI в приложении SDL - не очень хороший подход , если Ваша цель - плавно интегрировать виджеты Qt 4 в сцену, нарисованную в окне SDL.

и если нет, то есть ли их лучшие подходы?

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

3 голосов
/ 10 марта 2012

Итак, я собираюсь написать игровой движок с использованием OpenGL + SDL + Qt.

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

Мне нравится голая реализация OpenGL, а не Qt, главным образом потому, что я чувствую, что у меня больше контроля.

Нет «голого» OpenGL. В любом случае, вы должны приветствовать окно, и SDL кажется разумным выбором. Кстати: есть специальные библиотеки GUI на основе OpenGL, предназначенные для игр.

...