Grapple 0.9.8

сейчас будет сотня шуток про грабли

Ненужно. Игры надо делать нынче на Qt+OpenGL, в Qt все есть.

или на wxWidgets + OpenGL ;)

Звук через фонон выводить?

То есть в кьюте есть это нижеперечисленное?

Basic Features
Keeps all clients aware of all other clients
Passworded servers
Synchronised variables, allowing use without messages

Advanced Features
Network messenging by either a push or a pull model, or a mixture of both
Multiple methods of querying users
User Groups for client bandwidth saving
Network load reacting data transmission and retransmission
Background pinging to monitor network states
Server failover
A fully functional lobby system
NAT traversal using STUN and TURN

>Qt все есть.
У тебя Qt головного мозга? Зачем тащить в игру зависимости от какого либо тулкита? Так только последние дебилы делают.

А на чём интерфейс предлагаете делать? Изобретать свой велосипед для отрисовки кнопочек через OpenGL?

>А на чём интерфейс предлагаете делать? Изобретать свой велосипед для отрисовки кнопочек через OpenGL?

ну, вообще-то, игроделы, как правило, ~так и делают— используют некие минимальные GUI библиотеки написанные на SDL&co специально для игр

> или на wxWidgets + OpenGL ;)

А в wxWidgets есть прослойка для работы с сетью?

> А в wxWidgets есть прослойка для работы с сетью?

есть и неплохая

> А на чём интерфейс предлагаете делать? Изобретать свой велосипед для отрисовки кнопочек через OpenGL?

Да, можно свой велосипед, а можно готовый - http://www.cegui.org.uk/

> Да, можно свой велосипед, а можно готовый - http://www.cegui.org.uk/

Не меня, интересует ответ автора выражения "Зачем тащить в игру зависимости от какого либо тулкита?". Вариантов-то немного, и не понимаю, чем отличается зависимость от cegui от зависимости от Qt. Qt выглядит в этом отношении даже привлекательнее, т.к. с большей вероятностью уже установлен на компьютере.

> > Да, можно свой велосипед, а можно готовый - http://www.cegui.org.uk/

> Не меня, интересует ответ автора выражения "Зачем тащить в игру зависимости от какого либо тулкита?".

Мне тоже не понятно, зачем тянуть в игру тулкит, который не предназначен для игр.

> Вариантов-то немного, и не понимаю, чем отличается зависимость от cegui от зависимости от Qt.

Ну слава богу разработчики понимают, чем отличается зависимость игры от Qt от своего велосипеда или от того же cegui.

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

Ничего привлекательного в Qt для игр нет.

> Мне тоже не понятно, зачем тянуть в игру тулкит, который не предназначен для игр.

можно полюбопытствовать, в чём заключается острая непредназначенность для игр? Что именно мешает использовать Qt в игре?

> Ну слава богу разработчики понимают, чем отличается зависимость игры от Qt от своего велосипеда или от того же cegui.

Как разработчику, мне приятнее работать с Qt: отличная документация, куча примеров, удобство работы. На изобретение своего велосипеда уходит значительное время, и всё равно багов не оберёшься

> Ничего привлекательного в Qt для игр нет.

Qt привлекательна для игр кроссплатформенностью, хорошей документацией, кучей примеров, быстрой отрисовкой двумерной векторной графики, полной поддержкой юникода, работой с xml, svg, сетью, звуком, развитой системой локализации приложения, встроенным скриптовым движком на javascript

>Вариантов-то немного, и не понимаю, чем отличается зависимость от cegui от зависимости от Qt.

Qt может в 100 раз больше, чем нужно — больше потенциальных источников проблем, больше требования к ресурсам, труднее допилить под себя. И вообще я не уверен, что Qt можно совместить с полноэкранным OpenGL с FSAA/etc. Большинство тулкитов, на сколько я помню, нельзя.

Qt скорее решает проблемы, чем добавляет. Баги бывают, но быстро фиксятся (вообще, я за 4 года знакомства с Qt4 только на два бага наткнулся). Пилить под себя не приходится - всё сделано универсально, в отличие как раз от всяких мелких наколенных либ. Полноэкранное приложение сделать не проблема, как и поместить виджет opengl на всю площадь окна приложения, отрисовка производится с помощью обычного набора вызовов. Да, для 3D шутеров Qt не очень хорошо смотрится, но для двумерных игр (особенно казуалок) - преотлично.

> можно полюбопытствовать, в чём заключается острая непредназначенность для игр? Что именно мешает использовать Qt в игре?

Нет, это вы скажите, чем Qt подходит для игр?

> Qt привлекательна для игр кроссплатформенностью, хорошей документацией, кучей примеров, быстрой отрисовкой двумерной векторной графики, полной поддержкой юникода, работой с xml, svg, сетью, звуком, развитой системой локализации приложения, встроенным скриптовым движком на javascript

Признайтесь, игры вы не разрабатывали ;)

> Да, для 3D шутеров Qt не очень хорошо смотрится, но для двумерных игр (особенно казуалок) - преотлично.

Только не вздумайте сказать об этом гейм-дизайнеру. Он от такого захлебнется.

> Нет, это вы скажите, чем Qt подходит для игр?

см. выше

> Признайтесь, игры вы не разрабатывали ;)

www.hedgewars.org

> > Нет, это вы скажите, чем Qt подходит для игр?
> см. выше

Там нет ни одного аргумента, за исключением "я на Qt пишу уже 4 года".

> > Признайтесь, игры вы не разрабатывали ;)
> www.hedgewars.org

Вы автор? Посмотрел зависимости, окромя паскаля и sdl вы тянете qt-svg и qt-gui, но хоть убейте, не пойму зачем они вам понадобились. Просто не осилили cegui?
Опять же даже если это ваше игра, но она не является показателем нужности использования Qt для "рисования" интерфейса в играх.
Если так не нравится cegui, то обратите внимание на gui из HGE - там элементарные вещи, но их легко наследовать, добавляя нужный функционал. При этом пользователю не приходится ставить в систему монстра, который ему нафиг не нужен.

> Там нет ни одного аргумента, за исключением "я на Qt пишу уже 4 года".

цитирую себя: "кроссплатформенностью, хорошей документацией, кучей примеров, быстрой отрисовкой двумерной векторной графики, полной поддержкой юникода, работой с xml, svg, сетью, звуком, развитой системой локализации приложения, встроенным скриптовым движком на javascript"

> Вы автор? Посмотрел зависимости, окромя паскаля и sdl вы тянете qt-svg и qt-gui, но хоть убейте, не пойму зачем они вам понадобились.

я автор, начал проект, являюсь его руководителем. Движок на паскале+sdl. В процессе разработки было решено сделать фронтенд для запуска движка. Сейчас этот фронтенд обеспечивает настройку игры, создание команд ежей, соединение по сети и много других мелочей, для которых пришлось бы писать свои велосипеды/использовать сторонние либы (например, QSettings для файла настроек, класс для md5 хэша).

> Просто не осилили cegui? Не уверен, что в 2005м годы было что осиливать: рассматривался и вариант построения гуя на OpenGL, но ничего хорошего в интернете не нашёл.

> Опять же даже если это ваше игра, но она не является показателем нужности использования Qt для "рисования" интерфейса в играх.

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

> Если так не нравится cegui, то обратите внимание на gui из HGE - там элементарные вещи, но их легко наследовать, добавляя нужный функционал.

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

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

А велосипеды ему нужны? Либы для одной игры? Qt4 чаще всего уже стоит в системе, не являясь таким уж большим монстром: в hedgewars при статической компиляции собственно Qt занимает не больше 10 мегабайт.

> цитирую себя: "кроссплатформенностью, хорошей документацией, кучей примеров,

Все это есть и в других библиотеках, которые больше подходят для игр.

> быстрой отрисовкой двумерной векторной графики,

Так а кто запрещает использовать OpenGL? ;)

> полной поддержкой юникода,

Что значит полной, или поддержка есть, или ее нет. Опять же нет никаких сложностей с юникодом.

> работой с xml,

Ну на ЛОР об этом много судачат ;)

> svg,

Далеко не во всех проектах в этом есть необходимость.

> сетью,

Кажется в проекте была зависимость от SDL_net.

> звуком,

Тут SDL_mixer (хотя гадость). Лучше OpenAL или BASS (он кроссплатформенный, хотя и закрытый).

> развитой системой локализации приложения,

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

> встроенным скриптовым движком на javascript"

Есть Lua. Да и далеко не для каждой игры (особенно казуальной) нужны скрипты.

> я с cegui просто не знаком. В Qt приятно то, что наследовать мало что и нужно - всё удобно, легко настраивается (в том числе внешний вид), хорошо протестировано.

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

> А велосипеды ему нужны? Либы для одной игры? Qt4 чаще всего уже стоит в системе, не являясь таким уж большим монстром: в hedgewars при статической компиляции собственно Qt занимает не больше 10 мегабайт.

Целых 10 мегабайт, а ради чего так и не ясно. Я понимаю, что ресурсы в игре съедают львиную долю размера дистрибутива, но это не повод добавлять к дистрибутиву своп от windows95 ;)

>> цитирую себя: "кроссплатформенностью, хорошей документацией, кучей примеров,

> Все это есть и в других библиотеках, которые больше подходят для игр.

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

> Так а кто запрещает использовать OpenGL? ;)

В Qt работа именно с двумерной графикой удобнее, чем напрямую через вызовы OpenGL. Вдобавок может работать через разные бекенды

> Кажется в проекте была зависимость от SDL_net.

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

>> развитой системой локализации приложения,

> Да какая тут система - стринги в utf-8 во внешнем файле.

а вот и нет. А как с множественным числом работать? 1 юнит, 2 юнита, 5 юнитов. В разных языках к тому же разные правила на этот счёт. Опять свой лисапед городить, лингвистику поизучать попутно?

> Вывод текста через freetype2 с использованием кеширования (своего желательно, во freetype2 это пока не отлажено).

Ну вот... и тут велосипед городить. Справедливости ради уточню, что в движке такой велосипед изобретён. Вывод, правда, идёт через SDL_ttf, но это непринципиально.

>> встроенным скриптовым движком на javascript"

> Есть Lua. Да и далеко не для каждой игры (особенно казуальной) нужны скрипты.

Есть, никто не спорит. Но в Qt javascript уже органично вплетён, а lua надо самостоятельно пришлёпывать. Если не нужно - так на то Qt и модульный, лишнего таскать не нужно. А если нужно - вот оно уже, с теми же доками, от тех же разработчиков.

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

Возможно, но менять что-либо уже поздно

> Целых 10 мегабайт, а ради чего так и не ясно

Ради удобства и простоты программирования. Когда есть свободное время на проект, хочется использовать это время по полной, без написания велосипедов и поиска либ для потребовавшейся простейшей функциональности, навроде либы для файлов ini. Я практически уверен, что если для всех полезняшек, которые использованы в hedgewars, найти по сторонней либе, то выйдут те же 10 мегабайт, только в виде 20-30 либ, а не одного Qt.

> Вы автор? Посмотрел зависимости, окромя паскаля и sdl вы тянете qt-svg и qt-gui, но хоть убейте, не пойму зачем они вам понадобились. Просто не осилили cegui? Опять же даже если это ваше игра, но она не является показателем нужности использования Qt для "рисования" интерфейса в играх.

Чувак, не тупи. Игры - это не только плоский интерфейс плюс отрендеренная картинка. Одна только человеческая работа со строками в Qt упрощают разработку и локализацию. Плюс встроенная поддержка векторной графики (да, SVG), плюс встроенная поддержка сети, плюс встроенная поддержка работы с процессами - для хардкорщиков раздолье, плюс работа с OpenGL, плюс встроенное чтение/вывод звука (и ненужен SDL/SDLmixer). И все это в едином кроссплатформенном тулките. Плюс фоновая подмена копирования объектов на использование ссылок везде где это возможно, так что работа с объектами сильно упрощается и ускоряется без каких-либо ухищений ипрямого управления памятью.

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


> Если так не нравится cegui, то обратите внимание на gui из HGE - там элементарные вещи, но их легко наследовать, добавляя нужный функционал. При этом пользователю не приходится ставить в систему монстра, который ему нафиг не нужен.

При этом пользователю не нужно ставить на систему зоопарк библиотек.

> а вот и нет. А как с множественным числом работать? 1 юнит, 2 юнита, 5 юнитов. В разных языках к тому же разные правила на этот счёт. Опять свой лисапед городить, лингвистику поизучать попутно?

nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);

Это ?

> По факту Qt уже является аналогом DirectX, только кроссплатформенным и более "широким"...

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

> При этом пользователю не нужно ставить на систему зоопарк библиотек.

...аха юникс вэй :)

> Чувак, не тупи. Игры - это не только плоский интерфейс плюс отрендеренная картинка.

Спасибо, не знал.

> Одна только человеческая работа со строками в Qt упрощают разработку и локализацию.

Чего не хватает в std::string?

> Плюс встроенная поддержка векторной графики (да, SVG), плюс встроенная поддержка сети, плюс встроенная поддержка работы с процессами - для хардкорщиков раздолье,

И все это нужно для любой игры? ;)

> плюс работа с OpenGL,

Для работы с OpenGL нужен Qt? Без Qt никак? ;)

> плюс встроенное чтение/вывод звука (и ненужен SDL/SDLmixer).

О да, чтение звука так нужно в казуальной игре..
Кроме SDL_mixer есть audiere, fmod, bass, etc.

> И все это в едином кроссплатформенном тулките.

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

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

Вау ;)

> По факту Qt уже является аналогом DirectX, только кроссплатформенным и более "широким".

По факту все ваши аргументы притянуты за уши.

> Это несколько уменьшает его ценность для геймдевелопинга, в отличие от узкозаточенного DirectX.

Что то не уловил вашей фразы.

> Но, как тебе уже сказали, для казуалок Qt - это офигительная вещь,

Сказали, но ни один "аргумент" я не могу принять.

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

Шустрый софтверный рендеринг есть и у D3D, но никто в здравом уме не использует его. Одно дело софтверно блитнуть сурфейс с альфой, другое дело софтверно его подкрасить/рисайзнуть/повернуть.
Сколько получится FPS при софтверном рендеринге системы частиц, без коих в игре не обойтись.

> При этом пользователю не нужно ставить на систему зоопарк библиотек.

Пользователь установит игру, за установку зависимостей отвечает инсталлятор/менеджер пакетов.
И 10 библиотек по 100-200 Кб меньше, чем одна библиотека в 10 Мб (полагаю, полный набор либ Qt весит больше 40 Мб).

> лично я не знаю таких всеобъемлющих библиотек, да ещё с и отличной документацией.

Я не знаю, что значит отличная документация.

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

Это я понял, и моя попытка донести это до вас провалилась.

> В Qt работа именно с двумерной графикой удобнее, чем напрямую через вызовы OpenGL.

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

> Вдобавок может работать через разные бекенды

Ну кто мешает сделать разные рендереры или воспользоваться готовым? ;)

> > Кажется в проекте была зависимость от SDL_net.
> Говно говном, плюс у них в хедере накосячено с функцией перевода между различными endianess. Используется только в движке.

Может и так. Я просто указал на факт того, что вы используете ее. Но далеко не всем играм нужна поддержка сети.

> > Да какая тут система - стринги в utf-8 во внешнем файле.
> а вот и нет. А как с множественным числом работать? 1 юнит, 2 юнита, 5 юнитов. В разных языках к тому же разные правила на этот счёт. Опять свой лисапед городить, лингвистику поизучать попутно?

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

> > Вывод текста через freetype2 с использованием кеширования (своего желательно, во freetype2 это пока не отлажено).
> Ну вот... и тут велосипед городить. Справедливости ради уточню, что в движке такой велосипед изобретён. Вывод, правда, идёт через SDL_ttf, но это непринципиально.

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

> > Мне кажется, для вашей игры лучше подошел бы именно cegui.
> Возможно, но менять что-либо уже поздно

Да я же и не настаиваю ;)

> Я практически уверен, что если для всех полезняшек, которые использованы в hedgewars, найти по сторонней либе, то выйдут те же 10 мегабайт, только в виде 20-30 либ, а не одного Qt.

Мой движок со всем перечисленным функционалом (за исключением скриптов на Lua) плюс загрузка и рендеринг 3D моделей, прочий мало нужный в большинстве 2D игр функционал занимает менее 300 Кб. Если добавить сторонние библиотеки, которые использует движок, то получится около 1.5 Мб.

>> В Qt работа именно с двумерной графикой удобнее, чем напрямую через вызовы OpenGL.

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

Не составляет. Но в Qt есть готовая продуманная система классов. Кстати, там есть и обработка коллизий объёктов.

>> Вдобавок может работать через разные бекенды

> Ну кто мешает сделать разные рендереры или воспользоваться готовым? ;)

А кто мешает написать всю игру на асме без сторонних библиотек? Ничего, но зачем писать своё, когда есть готовые классы с готовыми бэкендами?

> А в Qt это есть для всех языков?

Да, для всех

> правила переноса иероглифа в японском на новую строку для меня не известны. В этом мне сможет помочь Qt?

Не знаю

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

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

> Мой движок со всем перечисленным функционалом (за исключением скриптов на Lua) плюс загрузка и рендеринг 3D моделей, прочий мало нужный в большинстве 2D игр функционал занимает менее 300 Кб. Если добавить сторонние библиотеки, которые использует движок, то получится около 1.5 Мб.

ну на то он и специализированный движок

Что ещё хочу сказать: изучая Qt для своей игры, я нахожу ему применение в своей работе. Если я изучил стили виджетов - я получил опыт использования CSS, если использовал скриптовой движок - то это стандартный Javascript, который пригодится мне где-то ещё, т.о. я расширяю свой кругозор по большей части не в области игровых технологий, а в том, что пригодится для зарабатывания денег :)

> Но в Qt есть готовая продуманная система классов. Кстати, там есть и обработка коллизий объёктов.

У меня тоже ;)

> > Ну кто мешает сделать разные рендереры или воспользоваться готовым? ;)
> А кто мешает написать всю игру на асме без сторонних библиотек?

Это уже крайности ;)

> Ничего, но зачем писать своё, когда есть готовые классы с готовыми бэкендами?

Так я и говорю -есть сторонние, но вы упираетесь только в один Qt ;)

> > правила переноса иероглифа в японском на новую строку для меня не известны. В этом мне сможет помочь Qt?
> Не знаю

Ну вот ;)

> > Принципиально, SDL_ttf рендерит текст на сурфейс. Рендерить каждый кадр глупо, для динамики использовать тоже глупо. В любом случае SDL_ttf для ленивых, кому хватает скудного функционала.
> Тем удобно, что рендерит на поверхность. Фритайп по сути то же самое делает, и использование фритайпа напрямую для простых задач - это оверкилл.

Если мне не изменяет память, то SDL_ttf использует freetype2. Так что использование SDL_ttf да еще и с ограниченным функционалом является оверкиллом ;)

> Что ещё хочу сказать: изучая Qt для своей игры, я нахожу ему применение в своей работе.

Вот с этого и нужно было начинать. Ведь наш спор начался немного с другого.

> Так я и говорю -есть сторонние, но вы упираетесь только в один Qt ;)

да никто не упирается, идёт дискуссия о якобы неприменимости Qt для создания игр, для опревержения чего рассматриваются возможности Qt ;)

>> Что ещё хочу сказать: изучая Qt для своей игры, я нахожу ему применение в своей работе.

> Вот с этого и нужно было начинать. Ведь наш спор начался немного с другого.

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

В конце концов, чем же так отличается Qt от суммы десятков либ, что это делает его непригодным для игр?