ИМХО единственный минус Qt это то что приходится с прогой таскать довольно тяжеленькие длл библиотеки, но это плата за отсутствие WinAPI

читывая то что в VS кросплатформенностью и не пахнет то правильней будет сравнивать Qt и GTK+

В GTK+ лучше программировать под Гном но с КДЕ могут возникнуть проблемки

Qt only. Без вопросов.

GUI систему пишут сами

На Qt пишется различные оконные приложения - тулсет (разного рода редакторы) для движка например

Ну дак тогда ессно Qt. Интерфейс редактора весь делаешь на нем, а realtime картинку рисуешь движком в специальную отдельную область окна. И все будет ок.

дык это и так понятно =)

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

А как там насчёт подключения физики типа Havok или Physics?

А зачем мне какой то "ГНОМ" с KDE? я собираюсь только под Винду с линуксом компилить

мой двиг

ну так я и собираюсь написать тулсет это будет редактор(как UDK или CE) который будет взаимодействовать с библиотеками и разными другими приложениями для него.

А там - это где? Вообще еще есть разница в том, как именно этот Qt использовать. Его можно применять просто как либу для написания тулсета и подключать к нему движок, либо можно использовать еще и в качестве базы для самого движка (ОС специфичные вещи, QtOpenGL например). В первом случае движок вообще существует отдельно как вид, с Qt никак не взаимодействует. Когда пишется Qt-шный редактор, то к нему подрубается движок со своей физикой и прочими плюшками и просто рисует в окно редактора. Ну и с помощью интерфейса они (редактор и движок) "общаются" между собой ессно. Во втором случае с редактором все похоже, но некоторые Qt библиотеки существуют как часть движка, который на них считай построен (но которые можно легко заменить, скажем, с помощью STL + кое-чего своего). При всем при этом сам редактор желательно делать в QtCreator, а движок писать в MSVS и если нужно, то в нем же можно использовать Qt'шные либы. Это я попытался немножко внести ясность в понимание "движок на Qt" А проблем с подключением, что в первом, что во втором случае быть не должно, если с руками все в порядке P.S. Всякие Havok или PhysX, да и в целом 3Д - довольно сложны и лучше сразу с них не начинать. Для начала не слишком навороченное 2д будет в самый раз.

тогда советую тебе еще взглянуть на Python, абсолютное большинство игровых редакторов и 3D редакторов (самые известные из них Blender, Maya) пишутся с использованием Python. А Python + Qt это вообще мощная тема.

Впервые слышу что бы на Кьюте писать Питоном

плохо слушал

тебе твсе равно перед стартом придется месяца два - три вычитывать спец литературу

Просто хочется не сильно морочиться с интерфейсом и побыстрее приступить к граф части

Ну вот и не беги вперед паровоза Зачем тебе прямо сейчас редактор понадобилcя? Он не должен писаться первым, ибо он не является самодостаточным, т.к. его возможности прямо зависят от возможностей и функционала движка, но никак не наоборот. Т.е. движок является центральной фигурой, его можно использовать отдельно и редактор является к нему лишь приятным дополнением (и без движка он ничего не умеет ессно). Поэтому если хочется писать движок - его и пиши, не думай пока о редакторах (+ само их написание отнимает приличное кол-во времени). Все, что нужно для тестирования и обкатки (загрузка ресурсов, позиционирование объектов в мире, etc) можно либо прописывать хардкорно в коде (для начала сойдет), либо прикрутить скрипт систему (что лучше и гибче, но сразу лишнее). Для каких-нибудь действий и тестов в риалтайме есть (обязаны быть) клавиатура и консоль , в добавок можно позже прикрутить внутриигровой GUI и несколько полезных контроллов выводить на экран. Как-то так вообщем. А вот когда движок более ли менее сформируется и будет виден его функционал, то тогда уже можно подумать и о редакторе. Удачи с разработкой

ох..ты порвал прямо таки мой шаблон Ну разве всё неначинается с редактора?