Проекты
GameDev.ru / Проекты / Форум / Judy (2 стр)

Judy (2 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
AlprogМодераторwww28 июля 201415:05#15
TirexiK
ant0n
Спасибо за поддержку, парни.

Gregorio
> окошки со своим редактором кода и пр. не имеющие отношения к движку вещи
У нас разное представление о том, что такое движок.

> сделай хотя бы отчет о внесенных изменениях
Будет выкладываться по мере создания.

jaguard
> По идее у тебя будет то же самое, если писать чисто на LUA. Чуть похитрее что-нибудь захочешь - и лезь в дебри с++
По крайней мере, туда можно будет лезть.

slatazan
> Надо мне учить Lua
Специально учить Lua необязательно. Она очень, скажем так, straightforward.
Можно с ходу начинать писать, обращаясь в справку только по мере надобности.

AlprogМодераторwww9 сен. 20143:35#16
Что-то у меня серьёзный затык в месте, где нужно делать сериализацию C++ класса в lua и обратно.

Легко представить, что такая структурка

//C++
struct Vector2
{
    float x;
    float y;
}

Vector2 vector{2, 8};

должна сериализоваться примерно в такую lua-табличку:

--//Lua
{
    ["@"] = "Vector2",
    x = 2,
    y = 8
}

Во время десериализации по такой табличке легко пробежаться и инициализировать объект.

+ Показать

Но меня беспокоит, что пробегаясь по такой табличке, мы сначала дёргаем дефолтовый конструктор (который наверняка проинициализирует поля уже чем-то), а потом присваиваем полям значения по одному (каждый раз вызывая из lua забинденный сеттер в c++). Насколько это дикий оверхед?

Просто меня подкупает, что на стороне lua легче объекты сериализовать, ведь благодаря биндингу, мы можем узнать все поля и методы объекта (в отличие от С++).
Можно было бы ещё как-то подпилить toLua++, чтобы сохранять дополнительную информацию о том, что именно сохранять, а что нет, а также некий механизм для сохранения std::vector'ов.
То есть хочется одним механизмом управлять и биндингом в lua и сериализацией.

slatazanПостоялецwww10 сен. 20140:28#17
Насколько я понял, это проблема в моменты Save-Load,
значит можно плюнуть на лишнии операции.
Главное - надёжность.
AlprogМодераторwww10 сен. 20140:52#18
slatazan
Я размышляю над тем, чтобы полностью формировать lua-таблицу на стороне C++ (C API) и там же по ней пробегаться при обратной загрузке.
Это, по идее, должно быть быстрее, чем дёргать туда-сюда функции из lua, но механизм сериализации тогда должен быть в С++.
Это наводит на мысли о том, что нужен какой-то рефлекшен. Собственно, сейчас над ним думаю. Не хочется дублировать код, хочется кодогенерацию.
belK@Постоялецwww10 сен. 20149:46#19
Alprog
Я у себя храню метаданные класса в виде статического поля, для каждого приходится регистрировать методы и при желании поля.
Далее по этому всему можно бегать хоть в цикле, если класс сериализатора знает тип зарегистрированного поля, то может его сохранить.
Таким образом при экспорте в XML достаточно отдать объект класса с метаданными, оно само всё сделает, в крайнем случае в XML попадёт просто
<ClassName></ClassName> - пустой объект. Но при десериализации это не помешает вызвать дефолтный конструктор и создать объект, как-то так.
AlprogМодераторwww10 сен. 201412:49#20
belK@
> Я у себя храню метаданные класса в виде статического поля
Можешь показать какой-нибудь класс с метой?
belK@Постоялецwww10 сен. 201417:34#21
Alprog
Приведу то, как я регистрирую, так тебе будет понятнее:
+ Немного_дефайнов

Думаю, ничего сложного, отмечу только, что: MakeVector - это некоторый класс, у которого перегружен оператор <<, позволяющий во внутренний вектор добавлять элементы.
Объявление ясно, а реализация выглядит так:
+ Еще_немного_кода

В классе с метаданными можешь хранить всё, что душе угодно, инициализация производится в конструкторе статического объекта.
Я храню там же и конструктор, т.е. имея метаданные всегда могу получить и сам объект. Это немного урезанная версия того о чём я говорил,
в текущем проекте больше не надо, но суть ясна.
Не претендую на абсолютную крутость и правильность кода :)
AlprogМодераторwww10 сен. 201417:58#22
belK@
Если развернуть макросы, а оператор << заменить на Fluent Interface, то получится очень похоже на то, как мета объявляется в cpgf или LuaBind.
Мне непонятно другое (копаюсь в исходниках, но пока идею так и не уловил): как вызывать методы и делать get/set полям?

> Не претендую на абсолютную крутость и правильность кода :)
У тебя опечатка: ClassElenment

belK@Постоялецwww10 сен. 201418:11#23
Alprog
> У тебя опечатка: ClassElenment
Это конец... :)

Допустим класс-оболочка метода хранит указатель на вот такой метод: wstring (Class::*mMethod)(const wstring&);
Тогда для его вызова тебе понадобится указатель на объект, а сам вызов: return (((Class*)pObject)->*mMethod)(pParams);

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

AlprogМодераторwww11 сен. 20142:17#24
belK@
А, идею понял. Крутизна.
Кажется, я только что левелапнулся в крестошаблонах и указателях на мемберы (до этого не приходилось).
+ Показать

Спасибо!

belK@Постоялецwww11 сен. 201411:25#25
Alprog
Да я и сам не так давно левелапнулся :) Не за что.
AlprogМодераторwww19 окт. 20140:47#26
На месяц практически полностью выпал из рабочего процесса в связи с переездом на новую квартиру, но теперь вот снова выдалась возможность покодить.

И так, что мы имеем?

  • Зачатки рефлекшена, метаинформация к которому пока забивается в ручную:
    + Показать
  • На основе этой же меты зачатки сериализации С++ классов в Lua-таблицу и обратно.
    Конвертация lua-таблицы в строку происходит уже на стороне Lua.
  • + Показать
  • Зачатки биндинга в Lua на основе всё той же меты, благодаря чему можно отказаться от toLua++ и обновиться до lua 5.2.3

Сейчас вот над чем задумался. Каждому типу в С++ соответствует userdata в lua со своей метатаблицей.
Эта метатаблица хранит гетеры/сетеры для всех полей типа (сишные функции), а также функции, которые помогают найти эти гетеры/сетеры при индексации.
Так вот непонятно, как лучше (с точки зрения производительности) сделать эти самые функции индексации: в lua

+ Показать

или же завести эквивалентный код в сях (просто неизвестно, какой оверхед даёт вызов сишной функции из луа)?

quyseПостоялецwww19 окт. 20145:09#27
Alprog
> просто неизвестно, какой оверхед даёт вызов сишной функции из луа
Так как ты всё равно вызываешь тут сишную функцию (сам метод из метатаблицы), то какая разница? Всё равно один переход из луа в си уже есть. Я бы оставил в луа, так как удобно использовать луа-таблицы для хранения методов, и индексация по строке в них очень быстрая.
Только, насчёт производительности, конкатенация ключа с 'get_' / 'set_' тут лишняя. Лучше завести отдельные таблицы, одну для get-методов, другую для set, индексированные просто именами свойств, и пусть __index и __newindex через замыкание из них достают методы по имени поля, без всякой конкатенации.
AlprogМодераторwww19 окт. 20146:11#28
quyse
> Лучше завести отдельные таблицы, одну для get-методов, другую для set
Да, я собирался. toLua++ также делает, вроде.

> Так как ты всё равно вызываешь тут сишную функцию (сам метод из метатаблицы), то какая разница?
Ну, индексация не всегда заканчивается вызовом функции. Мы могли обратиться не к функции, а к обычному полю таблицы, например.
Но это опять же аргумент в пользу того, чтобы на стороне lua это осталось.

AlprogМодераторwww5 ноя. 201416:04#29
Мало времени уделяю движку, мало. Впрочем, это было известно заранее.

Из новостей: подумываю над тем, чтобы контрибьютить в hlslparser и научить его в современный стиль hlsl.

Страницы: 1 2 3 4 5 6 7 Следующая »

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

2001—2018 © GameDev.ru — Разработка игр