Войти
Gamedev LectureСтатьи

Лекция #30. Спаривание редактора на C# с движком на С++ [Лектор - korak]

Автор:

[21:17:41] korak: для начала пара слов о выборе .Net и С#.
[21:18:34] korak: поднималось много тем что лучше для редактора. какой язык, какая библиотека... спор штука бесполезная. поэтому просто приведу аргументы своего выбора:
[21:19:31] korak: * использование одной и той же среды разработки без дополнительных зависимостей. т.е. везде где есть студия есть .Net framework
[21:20:03] korak: * низки порог вхождения. как для C# так и для WinForms в целом
[21:20:23] korak: * большое комьюнити в фриварными контролами.
[21:20:44] korak: * наличие механизма рефлекшена
[21:21:02] korak: вот основные причины. вопросы?
[21:21:36] Reystlin: что такое рефлекшен?
[21:23:34] korak: http://en.wikipedia.org/wiki/Reflection_(computer_science)
[21:23:47] Reystlin: сенкс
[21:24:29] korak: своими словами: это механизм посредством которого можно узнать информацию о типах которые содержит программа(модуль).
[21:24:45] korak: т.е. какие есть классы, какие у классов методы и т.д.
[21:25:33] Reystlin: понятно
[21:26:39] korak: ок. продолжаю.
[21:28:07] korak: первый блин использования .Net вышел комом.
[21:28:59] korak: причина была в движке. у него не было четкого порядка инициализации, т.к. какждый модуль был оформлен в виде сингельтона.
[21:30:51] korak: другая причина - попытка сделать "быстрее". было принять решение писать редактор "быстро" на CLI C++. и через 2 дня сглючил форм дизайнер. продолжать разработку на CLI C++ прекратили.
[21:32:33] korak: CLI C++ не глюкавый сам по себе. но MS решила не делать из него нормальный инструмент для написания оконных приложений. поэтому код получается совершенной ужасным + дизайнер форм работает медленно и периодически случаются глюки.
[21:34:51] korak: после этого грабли кончились :)
[21:36:13] korak: решили не "халявить". за 2 дня был написан прототип редактора который работал с движком через адаптер - .Net C++ CLI dll.
[21:37:39] korak: дальше буду расказывать о том хорошем что получили от .Net и С# и какие сложности предолели. если есть вопросы лучше задать.
[21:38:53] korak: ок. вопросов нет :)
[21:38:59] korak: есть.
[21:40:20] korak: egge: вы экспортили классы в длл?
[21:41:12] korak: в C# классы не экспортили. для классов писалась обвязка на CLI C++ - обвязка являлась .Net объектом и с ней уже  работал редактор.
[21:42:44] korak: egge: тоесть вы начали писать только после того как у вас движок был полностью написан?
[21:43:23] korak: нет, движок полностью написан не был. но базовые классы и механизмы движка уже были в стабильной стадии.
[21:44:51] korak: продолжаю.
[21:48:06] korak: манаджед языки имеют ограничения на создания найтив типов
[21:50:44] korak: очень полезным ресурсом по вопросам связанным с .Net оказался rsdn.ru
[21:52:08] korak: Но как часто бывает решения "наших" проблем там не было. писались классе хендлеры для оборачивания Boost::shared_ptr<> на игровые объекты, хелперные классы для перехвата лога движка и пр.
[21:54:34] korak: к сожалению из-за предновогодней суеты я не успел подготовить исходники по этим проблемам. исправлю это упущение в ближайшее время.
[21:58:08] korak: далее шли только "плюшки" от .Net. на codeproject была найдена библиотека контролов с поддержкой докинга и сохранением раскаладки, так была решена проблема кастомизации редактора под нужны программистов и артистов. там же был найдет и вставлен за пару часов контрол изменения цвета.
[21:58:46] korak: общая архитектура системы этот момент была такая:
[22:01:05] korak: создавался редактор. он передвал хэндл на окно для рендера в метод создания движка. движок грузил данные прописанные в "стартовом" xml файле
[22:01:40] korak: редактор узнавал об добавлении\\удалении объектов сцены через  callback
[22:03:07] korak: главный цикл крутился в редакторе, где и вызывались engine::tick и engine::render
[22:04:53] korak: изначально были написаны обвязки только для базовых типов движка. по мере необходимости дописались wrapperы для остальных типов. написание 1 врапера занимало <= 1 час.
[22:06:44] korak: выделив объект в списке объектов сцены, можно было редактировать его паблик совойства в property grid редактора.
[22:10:36] korak: список объектов сцены содержал только объекты базового типа. и этого было достаточно для работы механизмов выделения и редактирования св-в через property grid контрол.
[22:13:49] korak: кастомизация работы с контретными типами достигалась за счет использования RTTI - проверялся тип выбранного объекта и если он приводился, например к типу AnimatedObject, то создавалось окно со списком анимаций.
[22:16:19] korak: так же в врапперной DLL использовались 2 класса атрибутов. которыми помечались методы класса, для представления их в виде кнопочек редактора, один атрибут отвечал за кнопочки на toolbar другой - на tab panel объекта. параметрами атрибутов были: отображаемый текст, текст тултипа, имя файла с картинкой.
[22:17:50] korak: так же с помощью атрибутов превратили в кнопочки сервисные методы движка, как, например, перезагрузка всех текстур.
[22:18:14] korak: вопросы и закругляюсь.
[22:22:13] korak: egge: сколько было потраченно времени и стоит ли оно того? я имею ввиду вобще написание редактора
[22:22:32] korak: базовая версия была написана за неделю. потом только расширялась, причем другими людьми. впрочем об этом будет подробней в заключении.
[22:28:21] korak: xmvlad: как происходила сериализация и миграция данных между движком и редактором? то есть добавили пачку новых свойств как преобразовывались старые данные редактора?
[22:28:28] korak: что значит старые данные?
[22:28:48] korak: xmvlad: ну наклепали часть сцены. потом добавились новые свойства материалов например.
[22:29:27] korak: а причем тут редактор? загрузку он только делегирует движку. поддержка и расширения формата данных движка - тема, вероятно, другой лекции. причем не моей :)
[22:30:14] korak: заключение:
[22:31:23] korak: базовая версия редактора с 0 была написана где-то за 1 неделю. включая враперную DLL и редактирования базовых св-в игровых объектов, как то цвет, позиция, имя, т.д.
[22:36:01] korak: все цели которые ставились написанием редактора были достигнуты. основные проблемы были связанны с изначальной непродуманностью архитекторы движка в целом.
[22:36:12] korak: *архитектуры.
[22:36:58] kas: вот у меня вопрос - делали undo/redo? врапер не станет ли толстым слишком изза етого?
[22:37:24] korak: экспорт утилитарных методов в редактор занимал меньше времени чем тоже самое на ingame gui
[22:39:09] kas: ну, по опыту написания остального, тяжело было бы внедрить?
[22:39:34] kas: на что следует обращать внимание при написании движка, чтобы потом можно было безболезненно оборачивать?
[22:39:45] korak: нет. тут бы и проявился один из основных плюсов врапера - то что логика редактора никак не влияет на движок.
[22:40:34] korak: kas, класические советы. ничего более.
[22:40:45] viv_: nothing more
[22:40:52] korak: просто код должен быть кодом а не помойкой :)
[22:40:55] kas: ага. понимать. ещё раз спасибо :)
[22:41:23] viv_: Это можно подискусировать? /me счетает если код помойка - то это просто кажеццо
[22:41:32] egge: а что насчет функционала?
[22:42:06] kas: насамом деле приятно конечно, пропертигрид пропертя автоматом показывает, вынес во врапер всякого и радуйся...
[22:42:12] korak: очень лично меня радовало что разный крап связанный с логикой редактирования никак не добавлял мусора и багов  в движок :)
[22:44:04] ** *kas понял что его основная ошибка была с++/cli*

Страницы: 1 2 Следующая »

24 декабря 2006

Комментарии [9]