PMG

Всем привет!

Не хочется изобретать велосипед. Есть ли в природе готовые GUI-компоненты/библиотеки (например, в виде DLL)?
Поискал в интернете - сплошь и рядом библиотеки классов на С++.
Поскольку я пишу на FreePascal, то такой вариант не очень устраивает

_________________
С уважением.

Каких-то более или менее стандартных либ я не видел.

_________________
С уважением, Сергей

Лучше изобрети велосипед так лучше будет

_________________
С уважением,Блинов Андрей.

Блин... По всему выходит, что придётся самому делать. Не то что бы не хочется, просто времени жалко...
Если кому нужна такая библиотечка - подключайтесь, вместе дело быстрее пойдёт!

_________________
С уважением.

А ты что думал за день всё сделаеш люди есть это месяцами делают(Движки,GUI Lib итд)

_________________
С уважением,Блинов Андрей.

За день я бы не отказался. На ядро движка ушло полгода, впереди ещё ИИ, плюс симуляция полётов. Жалко переключаться на задачу типа GUI.
А то что люди это месяцами делают - где хоть одна приличная либа? Типа написал/забыл/снова велосипед изобретать?
Я бы понял, если делаешь гуй для коммерческого проекта. Но ведь это задача одноразовая - один раз написал, и всё!

_________________
С уважением.

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

_________________
С уважением, Сергей

Да можно, не спорю...
Только компонентных архитектур что-то не наблюдается. Классы/наследование - пожалста, а компоненты игровых объектов - фиг. Игровая семантика через скриптование классов - не самое лучшее решение, имхо.
Мне этот путь не очень нравится, вот и решил попробовать кое-какие идейки.
Физику взял Newton'овскую.
А вот либы толковые что-то не наблюдаются. Библиотеки классов - есть. Компонентов - нет. Или я не сумел увидеть, что вполне допускаю

_________________
С уважением.

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

_________________
С уважением, Сергей

"Компонентная архитектура" подразумевает использование "компонентов" при создании ПО. За подробностями, пожалуйста, к классикам: "Компонентное ПО". От себя могу сказать, что ближайший аналог - конструктор "Лего" или электронная схема. Я считаю, тут уже по-другому надо мыслить, нежели в терминологии ООП. Ну это ладно.
Лично меня интересует проблема максимального удобства конструирования игровых объектов. Наследование тут не совсем подходит, т.к. это завязка на компилятор. Скриптование классов, насколько я смог понять - это попытка вынести реализацию игровой логики (или, я рискну это назвать по-другому, - семантики игровых объектов) за пределы компилятора, чтобы не грузить гейм-дизайнера сложностью С++.
Как применить компонентную идеологию к игровым объектам? Я решил попробовать следующее - рассмотреть игровой объект (к примеру, "самолёт") как состоящий из компонентов ("семантических блоков"). 3d-модель - это один блок, физическое тело - другой блок, блок движения, блок ориентации, блок звука мотора и т.п.
В таком контексте, если иметь достаточно обширную библиотеку блоков - можно построить любую сцену. Заметь - компилятор не нужен! Все блоки уже откомпилированы, и дизайнер только указывает порядок сборки блоков.
Вот примерно так.
Я ни капли не считаю, что эта идея революционная и новая. Наоборот, в той или иной степени компонентная идеология в гейм-девелопинге задействована.
Просто я делаю движок, удобный для себя, вот и всё

_________________
С уважением.

А интрефейсы? Где ты возьмешь описание стандартных интерфейсов для этих случаев?

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

Скрипты - это просто возможность перенести работу с программистов, на дизайнеров уровней. У каждого своя работа.

_________________
С уважением, Сергей

http://www.cegui.org.uk/wiki/index.php/Main_Page - вот интересная либа по интерфейсам.

_________________
С уважением, Сергей

Если ты имеешь в виду интерфейсы компонентов, то это задача проектировщика библиотеки. Библиотека компонентов - это ось движка, её надо проектировать очень тщательно.



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


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

_________________
С уважением.

В принципе понятно, но это как и в ActiveX и DirectX - новое порождает новый компонент.

_________________
С уважением, Сергей

Идеология COM, да-да.
У меня получается такая штука - когда блоки стыкуются друг с другом, то образуется игровой объект, у которого интерфейс составной. Не знаю, хорошо это или плохо, но любой игровой объект можно соединить с любым другим.
Самый серьёзный минус такого подхода, на мой взгляд, заключается в том, что проверку типов интерфейсов надо делать вручную. Иначе звук соединяется с ориентацией и получится крэш
Но проверку сделать несложно, каждый компонент хранит информацию о своём типе - и загрузчик сцены пробежится по таблице соответствий и выскажет своё мнение, если что .

_________________
С уважением.