Появилась идея создать свой текстовый формат, да да знаю что это очередной велосипед который никому ненужен, но всё таки. Вот примерная концепция.
+ атрибут
// комментарий// атрибуты грузятся построчно, и могут быть загружены до загрузки всего файла/*
многострочный
комментарий
*/
NodName = "Some Text"// Узел может иметь значение и вложенные узлы
{
Nod = 1; // Целочисленная запись
Nod = 2.5; // Дробная
Nod = "Text"; // Текст по определению является многострочным, сохраняет все переносы
Nod = 0xFABC89D2F3 ;// Бинарные данные
Nod = !SomeRaw; // Псевдоним для бинарных данных// Массив с смешанными значениями
Nod = ["Text", 1, 2.5, 0xFABC89D2F3 , !SomeRaw, ArrNode = "text" { nod = 1;} ]
{
SubNod = "Text";
}
}
// В документе может быть сколько угодно начальных узлов, нет ограничения как в XML
NodName = !SomeRaw;
// Псевдоним для бинарных данных всегда начинается с !, не может находится внутри узла
!SomeRaw = 0xFABC89D2F3;
Не знаю может я такой криворукий, или может не умею искать информацию в интернете, но у меня так и не получилось с экспортировать классы генерируемые GPB в dll, постоянное падение линковки на двух функциях. Это печали сразу по нескольким причинам:
1- На GPB основывалась сериализация моего DataCloud.
2- GPB планировалось использовать для написания формата моделей.
3- GPB мог сохранятся сразу в двух видах, в текстовом и в бинарном, а значит придётся придумывать сразу два формата.
На данный момент решил для бинарного хранения использовать свой формат, а для текстового XML (слава компилятору PugiXML спокойно экспортируется в dll). Казалось бы зачем два формата бери один, но у того и у того есть свои минусы и плюсы. Минусы XML к примеру: он очень долго грузится, он текстовый а значит легко вскрывается, и весит очень много, но для дебага и SVN он подходит идеально, то есть он хорошо подходит на стадии разработки. Бинарный же формат лишён всех минусов XML: он быстро грузится, тяжело вскрывается, и весит много меньше XML, но для этапа разработки он совсем не подходит, с SVN по любому будут проблемы, для отладки данные не посмотришь. Именно поэтому я решил взять оба формата.
up
И так так парой днями раньше я всё таки запилил сериализацию в два этих формата. и само собой формат XML оказался крайне медленным, но зато с свном проблем не будет. Бинарный формат ко всему прочему также поддерживает проверку на целостность блока данных ^_^.
Решил начать вести блог, никогда до этого его не вёл и ничем подобным вообще не занимался, начал по причине того, что думаю это поможет моей мотивации. Не раз замечал у себя, что зачастую желание поделится информацией или похвастаться своими наработками побуждает к действиям, есть конечно и другой, проверенный и обкатанный метод занятие спортом, но в связи с работой свободного времени становится мало, появляется желание потратить его на нечто более весёлое, приятное и легко доступное. Так что ищу более доступные и менее затратные по времени методы.
И так первая цель, за месяц привести движок и редактор к более или менее пригодному для использования виду. Коротко о двиге. Изначально архитектура двига была рассчитана на удобный и открытый доступ к данным, но реализация не понравилась: слишком много ограничений, плохая расширяемость, сильная связность, неустойчивость, слишком много параметров. На данном этапе отвечающий за данные DataManager был сильно изменён и переделан в DataCloude название было выбрано так из-за похожести на облачные сервисы. Менеджер стал лёгок в использовании, лёгок в расширяемости, менее связан, устойчив, и количество параметров сильно уменьшилось, в общем новая система мне так понравилась, что я практически избавился от менеджера ресурсов, всё что он теперь делает так отслеживает сброс девайса и уникальность ресурса. Также новый менеджер стал обладать лёгким механизмом сериализации построенным на GoogleProtocolBuffer. Теперь можно лишь раз настроить ресурсы, данные, связи и сохранив их использовать в любом другом приложении и делается это всего двумя строчками. c_DataCloud::GetInstance()->SaveToFile("SomeData.dpt"); и c_DataCloud::GetInstance()->LoadFromFile("SomeData.dpt");
И так на данный момент мы имеем редактор который выглядит так Но к сожаления, он пока не несёт никакой функциональности и построен на предыдущей версии движка, задача на этот месяц, добавится к движку функциональны ObjectManager и реализовать в редакторе функционал по управлению объектами, то есть Gizmo, Property page, project page, resource page. Хотя бы для базовых объектов: Static mesh, Animated mesh. Сюда соответственно собираюсь выкладывать информацию по продвижению. Надеюсь мне это поможет.
