Войти
ПроектыФорумУтилиты

o2 (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
18:30, 14 мар. 2016

shda
> Расскажите про архитектуру
Все просто ) Основная и главная часть и редактор на С++. Функционал движка разбит по системам: рендер, ассеты, интерфейсы, приложение, граф сцены и т.д.
Пользователь в своем проекте использует исходники движка. В этом месте работает рефлексия - отдельная утилита генерирует код инициализации типов.
Подробнее можно прочитать тут.
Редактор - отдельный проект на этом же движке. Проект и редактор связываются через рефлексию и динамическую линковку ( пока нет, но так задумано =) ).
Грубо говоря исходники проекта компилируются в dll и далее используются в редакторе. Редактор не будет генерировать никакой код, максимум будет обновлять файл проекта для IDE.
Поверх всего этого скрипты и любые другие надстройки, в том числе редактора.


#16
6:53, 15 мар. 2016

anz
Спасибо за объяснение , интересная реализация рефлексии :).

#17
9:36, 4 апр. 2016

https://store.xamarin.com/

Visual Studio Community
FREE
A free, full-featured and extensible IDE for Windows users to create Android and iOS apps with Xamarin, as well as Windows apps, web apps, and cloud services.

#18
12:23, 4 апр. 2016

anz
Значит дождались и Xamarin стал бесплатным? А про small teams это применимо только для студии или для рантайма с библиотеками тоже? Другими словами, есть ли какие-то ограничения, если встроить этот xamarin в свой движок?

#19
18:26, 4 апр. 2016

gammaker
Как я понял, если ты Small team то можешь использовать как хочешь. Но если ты предприятие

«Предприятие» — это любая организация и ее аффилированные лица, которые совместно имеют (а) более 250 компьютеров или пользователей либо (б) годовой доход более 1 млн долларов США (или эквивалент в другой валюте), а «аффилированные лица» — это лица, контролирующие (через контрольный пакет акций) организацию, контролируемые ею или находящиеся под общим контролем с организацией.

то нужно общаться с ними по поводу платной лицензии.

В любом случае это уже очень хорошо, т.к. наличие C# в движке уже не будет требовать платной лицензии xamarin

#20
18:34, 4 апр. 2016

anz
> В любом случае это уже очень хорошо, т.к. наличие C# в движке уже не будет
> требовать платной лицензии xamarin
Но ведь не факт, что только маленькие команды будут пользоваться твоим движком? Если команда >5 человек или вообще предприятие будет использовать твой движок (без Visual Studio), то должны ли они будут покупать лицензию Xamarin? Или должен ли будешь ты покупать лицензию, чтобы внедрять C# в свой движок?

#21
19:48, 4 апр. 2016

gammaker
> Но ведь не факт, что только маленькие команды будут пользоваться твоим движком?
Да, но их будет большинство. Суть даже не в этом, а в том что для начала использования движка с C# не нужно будет покупать лицензию xamarin.

gammaker
> Если команда >5 человек или вообще предприятие будет использовать твой движок
> (без Visual Studio), то должны ли они будут покупать лицензию Xamarin?
Да, придется. Но это уже будут более крупные разработчики, которые могут себе это позволить. Вобщем то microsoft & xamarin тут можно понять :)

gammaker
> Или должен ли будешь ты покупать лицензию, чтобы внедрять C# в свой движок?
Если я буду выпускать свой движок и буду попадать в категорию "Предприятие" - то да ( на это я и надеюсь в конечном счете :) )

Они сделали правильный шаг - открыли мультиплатформенный C# для всех желающих, ну а кто хорошо зарабатывает (более 5 человек или 1млн долларов) уж не поскупятся на хороший продукт.
У меня и самого похожие представления о лицензии: хочешь попробовать, научиться использовать, выпустить что-нибудь небольшое - без проблем, бери и пользуйся. Ну а если ты крупная рыба или много заработал с движком - тогда небольшой процент

#22
(Правка: 22:24) 22:15, 21 мая 2016

anz
> Кто спорит - идите нахер ))
Не надо так грубо. Исправь.
Движек заинтересовал, буду следить.

#23
12:19, 25 окт. 2016

Немного новостей :)
Переделал систему рефлексии и кодогенерации. Раньше код, инициализирующий типы скидывался в один срр-файл. Решение оказалось неудачным, потому что компиляция такого огромного файла происходила долго и требовала некоторых настроек компилятора. А компилировался он при любом изменении класса с рефлексией. Теперь мета-информация о типах содержится там же, где и определен сам. Так же раньше код инициализации типов генерировался утилитой, написанной на C#. Переписал на С++, потому что утилита в силу архиеткуры и самого шарпа работала доволно долго - около 10 секунд при каждой компиляции. Не очень хорошо, если постоянно делаешь правки и перезапускаешь проект. На первом этапе код с C# был переписан в С++ без архитектурных изменений. Интересно, что вышел такой чистый и не синтетический тест двух языков. Одна и та же задача решена на двух языках, одинаковой машине и одним программистом. Результат - С++ утилита отрабатывала примерно в 1.5-2 раза быстрее. В итоге решил кешировать результаты работы, и время работы сократилось примерно до полусекунды.
Так же добавил возможность регистрировать кастомные сериализаторы типов. Это нужно для хитрой сериализации акторов, компоннентов или типа того. Например, у нас есть компонент, в котором есть указатель на какой-то актор. Ему мы присваиваем указатель на актор со сцены. Сохраняем сцену - загружаем сцену. Указатель сохранится не сырым, указывающим в никуда, а будет восстановлен и будет указывать именно на тот актор, на который ссылался до сохранения. То же самое с компонентами и тегами.
Следующий этап - прототипы. Что-то вроде префабов в юнити, только с наследованием. Суть проста, актор может иметь прототип. При загрузке создается прототип и применяются изменения из актора, для которого прототип используется. Соответственно акторы могут использовать в качестве прототипа любой актор, в том числе и актор с прототипом.

По редактору не так много изменений. Отрефакторил дерево акторов. Теперь не тормозит при большом количестве открытых элементов. Так же почти сделал нормальный Drag'n'drop с приличным интерфейсом. Понемногу доделываю окно свойств. Добавил обрамление компонентов в спойлер. Сделал шапку свойств актора.

В планах перевести систему интерфейсов на акторы. Вообще, немного поменялась идея организации сцены. Вместо одного универсального актора с налепленными компонентами будет объект сцены, с последующей типизацией: тот же актор, виджет, кнопка и тд.
Так же в планах заоптимизировать отрисовку UI в редакторе. Сейчас он весь рисуется движковым UI, каждый кадр заново. Оптимизация - рисовать только там, где интерфейс меняет состояние, остальное держать в буффере. Сейчас редактор откушивает 20% процессора, и это чисто из-за постоянной перерисовки.

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

Ну и небольшой скриншот
Изображение

AntonioModer
> Не надо так грубо. Исправь.
Нет.

#24
14:06, 25 окт. 2016

anz
О, у меня тоже отдельная тулза для кодогенерации рефлекшена. Давай дружить движками!

#25
22:05, 25 окт. 2016

Alprog
Ничесе )) Есть где поглядеть-поковырять?

#26
2:33, 26 окт. 2016

anz
http://www.gamedev.ru/projects/forum/?id=191495

#27
17:11, 31 дек. 2016

хэй! с новым годом, посоны! ))

немного новостей
итак, очередные подкручивания рефлексии (еще немного и я ее предложу комитету по стандартам с++ ха ха), теперь можно смело отличить по типу обычную переменную, вектор, указатель или свойство. Пришлось с головой окунуться в шаблоны С++. Надо сказать, когда-то я язык по истине любил и считал лучшим, но после такого становится все грустнее и грустнее..

+ Вероятно самое длинное определение шаблона, что вы видели

Ну и хрен с ним. Главное, благодаря этому окно со свойствами уже работает почти как нужно - умеет отображать обычные поля, массивы, объекты и т.д. Параллельно с этим поправил окно с ассетами, убрал несколько мелких багов, начал делать отображение свойств ассетов. Пока есть одна существенная проблема - при переключении директории заметные лаги, что не очень хорошо. Нужно кешировать, показывать только видимое, оптимизировать.
В ближайших планах на будущее - сделать удобные меню редактирования ассетов, и наконец сделать прототипы. Прототипы - что-то вроде префабов в юнити, но с возможностью переиспользования. Тобишь в качестве прототипа для объекта может служить совершенно любой объект, в том числе использующий прототип. При загрузке объекта сначала грузится прототип или берется из кеша, затем применяются изменения, затем он тоже кешируется.
Еще окончательно убедился в том, что для скриптов LUA лучше C#. Как минимум встроить легче и билд не будет конски огромным

И как всегда скриншот :)
Изображение

#28
(Правка: 3:12) 3:07, 10 янв. 2017

Видос

Актуализировал 0-пост

#29
7:02, 10 янв. 2017

Ого, ничоси.
Это типа как Construct2?

Страницы: 1 2 3 4 Следующая »
ПроектыФорумУтилиты