В краткости: я потерял исходники из-за поломки жёсткого диска. На этом жд хранилась информация об аккаунтах - которая была также успешно потеряна. Однако аккаунт я восстановил, возможно, что и восстановлю проект в ближайшем будущем. Поэтому тему не удаляйте, пожалуйста.
AlloDraw 2D engine
Платформа: Windows NT 32bit (2000, XP, Vista, 7) Пространство: базовое 2D. Система позволяет реализовать 3D. Используется API: WinAPI, VCL, DirectX Используются библиотеки: LUA, PNG, FMI, Squall Описание: модульный движок для создания экономических симуляторов, игр, похожих на SimSity, SitiesXL. Лицензия: Бесплатная. Предоставление исходного кода: на усмотрение автора.
И так, сегодня я продолжаю развитие проекта AlloDraw engine, который уже строиться более двух лет. Наверное, самый долгострой, который есть на gcup.ru. Но не об этом. В развитии этого проекта я вложил много сил. Камнем преткновения в развитии стал сценарный движок. В результате я решил перестроить систему, используя LUA, что, соответственно, дало свой результат.
ADE через два года. ADE прошёл жестокую «мутацию», которая привела проект от GOS, до AlloDraw. Вначале, это должна была быть простая игра, которая походила бы на простой компьютерный симулятор. Но, решение пришло о развитии полноценного движка, чем я и занялся. Далее, движок приобрёл некоторые способности, и в конце концов, основное направление движка стало: экономические симуляторы.
На этом, развитие данной идеи не завершено. Последнее обновление идеи ADE привело к пересмотру всей структуры движка, где и потребовался мощный сценарный движок. А я, как «мега-пупер-программер», решил написать свой сценарный движок, но оказалось, что для меня это не подъёмная задача. То есть как, я создаю свой сценарный движок, но он не имеет нужных характеристик, которые нужны именно для ADE. По этой причине, признав свои ошибки, я решил перейти на LUA, что, повторяюсь, дало свой результат.
И вот, теперь можно представить структуру ADE. Это модульный движок, где сам головной файл представлен в виде менеджера, запускающего необходимые модули. Вся основная функциональность движка распределена в модулях. Таким образом, движок способен работать в расширенном режиме, позволяя создавать игры разного направления, и в разном пространстве.
Конечно, я не гений, что бы сразу создавать 3D модули к ADE, поэтому останавливаюсь на простенькой 2D графики с анимацией.
Проведённая работа: 1. Наконец был сформирован формат FMI, создан редактор FMI для ADE. 2. Разработана концепция карт. 3. Так же, реализованы некоторые системные вещи.
Будущие работы: 1. По динамичному плану и работам двух лет создаётся единый план-проект ADE. (публикация плана – конец января, начало февраля 2012 года). 2. Разрабатывается API и интерфейс модулей. Это вообще, сложный вопрос, но решаемый.
Что обдумывается: Возможно, что ADE обзаведётся и конструктором игр. Но, без программирования – не назвать, так как он будет требовать знания LUA.
Высказывайте своё мнение, и предлагайте свои идеи по поводу ADE... ______________________________ Я вернулся, и это чудо. ______________________________
Сообщение отредактировал BOOM - Суббота, 30 Сентября 2017, 06:10
SlavyanOOs, не знаю, это моя первая конкретная и долгостройная работа.
Кстати, сегодня я завершил тесты первого варианта игрового мира (то есть суть строения карт), но мне кажется, что он неудачен. Я выкладываю скрины, мне нужно ваше мнение...
______________________________ Я вернулся, и это чудо. ______________________________
SlavyanOOs, знаю, это же набросок. Тут речь не идёт об дизайне приложения... Сейчас на фолдер залью, а вы поюзайте... ______________________________ Я вернулся, и это чудо. ______________________________
Это ладно, я думаю над тем: что система построения этих типов карт - блочная, и вполне не пригодная. Так как я гляжу на этот движок ещё и с другой стороны. То есть возможность создавать РПГ и военные стратегии (ведь двиг пока что пишу для экономических стратежек). Я думаю, что необходимо полностью пересмотреть концепцию карты.
Ну, во-первых, сделать многослойность карты; во-вторых использовать смешанную систему: блоки+статичные объекты+динамичные объекты ( = фон карты)... Но тогда необходимо будет предусмотреть систему твёрдости объектов...
Зациклился на этом моменте...
______________________________ Я вернулся, и это чудо. ______________________________
Опять я возвращаюсь к проблемам сценарного движка. При сборке платформы, оказалось, что LPS 2 не справляется с массивом функций, и из-за чего сильно тормозит. И вторая ошибка - это в системе разборки строк. В LPS 2 используется система Analisys, где строка разбивается на части с помощью определённого делителя. Сам принцип работает довольно шустро, но проблема в том, что я результат разбора записываю в TAnalisysResultat. Этот класс в функциях используется как статичный объект, и из-за чего скорость уменьшается.
Допустимое решение проблем.
Первую проблему, думаю решить с помощью индексации и компиляции скрипта перед запуском. Соответственно, что бы получить хороший результат, необходимо включить в компилятор хорошую систему отладки. Вот тут, я думаю, я помучаюсь долго.
А вот вторая проблема решается довольно просто. Ну, для начала необходимо пересмотреть концепцию формирования функции. Как я упоминал, в функции разбора для вывода результата используется статичный объект, образующийся из класса TAnalisysResultat.
Просто необходимо этот объект перевести в динамичное состояние и в функцию вводить указатель на объект, а не выводить объект в целом. При такой модернизации, две функции, приведённые выше, приобретут такой вид.
На счет разбора кода, правильней делать так, так будет и быстрее работать:
1. Разбиваешь код на инструкции (обычно инструкции в языках отделяются ";") 2. Разбиваешь каждую инструкцию на лексемы Лексема - это структура, которая имеет тип (например число, переменная, строка, оператор плюс и т.п.), имеет например свойство номер строки (как раз тебе для отладки) 3. Если ты делаешь интерпретатор, то просто интерпретируешь эти лексемы по своему. А если делаешь компилятор в байт-код, компилируешь в байт-код инструкции (они еще более разжеванные и интерпретируются раз в 10-100 быстрее).
Отладка делается просто, в функцию интерпретации ставишь заглушку для дебага, и если ты имеешь информацию о номере строки каждой лексемы, достать строку на которой остановился скрипт не проблема.
И все структуры нужно делать динамическими, а не статическими.
И все структуры нужно делать динамическими, а не статическими.
Вот это моя самая большая ошибка. Но теперь мне понятно, почему скрипт работает медленно, в основном, из-за статичности и в некотором смысле неправильной интерпретации.
На счёт разбора, да, это точно сказано. Devel, Ты забыл про зоны именного ограничения, обычно они берутся в фигурные скобочки (C++ Style), или открываются оператором begin и закрываются оператором end (Pascal style). Кстати, использование таких блоков увеличивает скорость разбора и не засоряет память. Это удобно.
Да, старые идеи LPS - не удачны. Для полной реализации моей идеи ( ведь я её не выкладываю полностью , и из-за этого проект немного затянулся ) необходим объектно-ориентированный сценарный движок. Брать сторонний я не хочу. Поэтому, пособирав документацию по разным проектам, я сейчас разрабатываю более новый язык. Думаю, что на это уйдёт приличное время.
Посмотрим, что в общем получится...
______________________________ Я вернулся, и это чудо. ______________________________
Devel, Ты забыл про зоны именного ограничения, обычно они берутся в фигурные скобочки (C++ Style), или открываются оператором begin и закрываются оператором end (Pascal style). Кстати, использование таких блоков увеличивает скорость разбора и не засоряет память. Это удобно.
Такое именное ограничение это редкость на самом деле. А если вообще об этом, то тебе нужно реализовать класс стека для разных вещей - для обычных значений, для объектов отвечающих за переменные. Нужно реализовать класс, который и будет хранить переменные. При вызове пользовательской функции например, создается объект класса "Переменные". Также можно создать объект "Глобальные переменные" того же класса. Еще тебе понадобиться хороший класс для хеш таблиц, который ты будешь использовать везде - для массивов в языке, для самих переменных, для именованных функций и т.п. Без хеш таблиц поиск по названию будет происходит раз в 100-200 медленней, а может и еще медленней и я не преувеличиваю (бинарный алгоритма поиска не поможет, поверь).
А в статичности по сути нет ничего такого уж неправильного, просто если делать не динамические структуры, у тебя будет происходить копирование этих структур при передаче в функции и другие места, а когда ты передаешь указатель на структуру, ты по сути передаешь число, а не сложную структуру.
Сообщение отредактировал Devel - Вторник, 16 Ноября 2010, 13:11
Ну, конечно, без хеша не обойтись. Я на своём опыте это "яблочко" скушал, когда разработал первую версию Glogic. Вторую версию раскидал по инструкциям и группам, так вообще получилось медленно.
Quote (Devel)
А в статичности по сути нет ничего такого уж неправильного, просто если делать не динамические структуры, у тебя будет происходить копирование этих структур при передаче в функции и другие места, а когда ты передаешь указатель на структуру, ты по сути передаешь число, а не сложную структуру.
Знаю... Ага, а когда речь идёт о тысячах запросов, лучше передавать указатель, чем копировать объект. Ну, по крайней мере увеличивается скорость в несколько раз, особенно, если идёт речь об классе TAnalisysResultat.
Объявление класса выглядит так (старая версия):
Code
class TAnalisysResultat : public TCustomAnalisys {
//Функции, которые применяются ко всем строкам в буфере //Функции индеетичны функциям из TCustomAnalisys. Приминяются //сразу для всех строк. void Trim(); void LeftTrim(); void RightTrim(); void AllTrim(); void TrimSpace(); void TrimModern(); void TrimClever(); void TrimTypeQuote(int type); void TrimTypeQuoteClever(int type);
Первое, что я хочу передлать - это частично отказаться от AnsiString. Есть идея более быстрого класса для работы со строками. Первые реализации показали, что он может быть быстрым, но необходимо произвести более продуманный подход. Скорее всего, прототипом этого класса станет std::string.
Кратко об этом классе: Система, которая выделяет память в виде ячеек размером по 32-64 байта для строки. При проведении операций над строками, операторы new и delete будут вызываться только по надобности. Этот подход увеличивает скорость очень заметно. Кстати, я не помню, кто это даже придумал, где то это описание в сети нашёл.
______________________________ Я вернулся, и это чудо. ______________________________
Для строк есть еще один вариант, это сделать строковой пул, т.е. все строки хранить в одной строке, надо лишь самому следить за смещением в главной строке и за длинной строки. Но я тебе скажу, прирост скорости более быстрый string тебе не даст особо ничего, потому что, как показывает практика, больше времени тратится на другие вещи. Но я такого еще не пробовал. Думаю будет быстро, потому что выделять постоянно ничего не надо.
А AnsiString это тот же PAnsiChar если не знал, только компилятор сам следит за длинной и выделением памяти, для анси стринг есть сборщик мусора и поэтому он более надежен, хоть может быть и медленней.
Если ты грамотно напишешь движок, то при выполнении, строки будут участвовать только для строковых встроенных строковых функций в движок. Т.е. строки не должны в конечном счете интерпретироваться при выполнении.
Сообщение отредактировал Devel - Вторник, 16 Ноября 2010, 16:08
Как это, ничего, быстрый стринг может увеличить скорость анализа синтаксиса, особенно, если идёт речь о более сложных структурах для анализа. Ну, так, да, более нигде не понадобится.
Quote (Devel)
А AnsiString это тот же PAnsiChar если не знал
Нет, честно скажу, не знал.
Quote (Devel)
компилятор сам следит за длинной и выделением памяти, для анси стринг есть сборщик мусора и поэтому он более надежен, хоть может быть и медленней.
Это я знаю, только там не для него, а для всей системы VCL, на сколько мне известно, так как тело Anis и Wide уже в байт коде, только идут вызовы функций, впрочем как и все компоненты на BCB.
Quote (Devel)
Если ты грамотно напишешь движок, то при выполнении, строки будут участвовать только для строковых встроенных строковых функций в движок. Т.е. строки не должны в конечном счете интерпретироваться при выполнении.
Спасибо за совет. ______________________________ Я вернулся, и это чудо. ______________________________
Сегодня я завершил тесты системы выделения памяти для нового сценарного движка. Тесты вполне меня удовлетворили, ну, можно и быстрее. В общем, я начну с самого начала...
И так, я стал собирать сборку AlloDraw (Уже пора...). Но без подводного камня не обошлось. Модификация LPS2 M7 оказалась очень медленной, и я решил воссоздать новый сценарный движок. Но теперь речь идёт не об текстовом интерпретаторе, который, по коду, очень слабоват, а о серьёзной фундаментальной машине - интерпретаторе байт-кода.
Ну, для начала я ввёл восемь новых системных типов данных. Когда старый ЛПС имел всего два системных типа данных. Помимо этого, система выделения памяти, из обычной таблицы, превратилась в очень сложный механизм, который фундаментально позволяет создавать объекты (структуры, объекты из классов, в общем, элементы ООП).
Тест механизма показал вполне хорошие результаты:
Результаты записи:
Количество обращений к менеджеру памяти: 10 000 440; Время, затраченное на работу с памятью: 8.091 сек.
Согласитесь, на десять миллионов обращений к памяти это неплохой результат.
Тест чтения заключался в том, что бы прочитать данные из заполненной памяти. Память была заполнена тестом первым. Запись данных осуществлялась в простую переменную памяти.
Результаты чтения:
Количество обращений к менеджеру памяти: 10 000 442; Время, затраченное на работу с памятью: 7.998 сек.
Но отмечу, что под "обращением к памяти" я имею в виду и создание объектов. Помимо этого, 440 обращений были произведены к, так называемой, быстрой памяти. В общем тест меня удовлетворил, но это только альфа, и будет модернизироваться в период разработки LPS.
Подробнее об новом модуле выделения памяти и об тестах можно узнать из статьи на моём сайте. Полная версия.
______________________________ Я вернулся, и это чудо. ______________________________
На мой взгляд ох как зря ты ввел типы Int32,Int64 и подобные. Посмотри как сделано в lua, там есть 2 типа int и float, но собирать движок можно под разными типами, int = int32 или int64 и т.п. Тот кто пишет скрипты не будет разбираться в разрядности. Byte еще более менее оправдан. Думаю еще не хватает типов: массив, объект и если есть анонимные функции - анонимная функция, все это все ссылки на самом деле, но тип нужен для движка.
С регистрами тебе тоже будет довольно сложно, та сказка про регистры в lua на самом деле ничего общего с регистрами не имеет. Нужно использовать стек с кешированием, т.е. когда в стеке выделяется память, выделять, когда он уменьшается на один, то верхушку не удалять, а лишь уменьшать длину стека - переменную, и тогда если будет повторное обращение к стеку, новый элемент не будет создаваться, если в стеке уже есть мусор. Вот и получаются псевдо регистры. Регистры можно хранить еще в инстуркциях байт-код, например 2 регистра, по сути это не регистры, но тебе придется генерировать трех адресный код, я генерирую трех адресный код из стекового и это не сложно, количество инструкций байт кода уменьшается вдвое, что влияет на скорость.
Ну, во-первых, я не смотрю на движки, как на шаблоны. Во-вторых, LUA имеет уникальную систему, но я не собираюсь писать по подобию этого движка.
Quote (Devel)
та сказка про регистры в lua на самом деле ничего общего с регистрами не имеет
Я знаю. В движке регистр - это целая ячейка памяти, которая не поделена, как регистры процессора (по сути, псевдорегистр). Регистры относятся к модулю моментальной памяти. Я знаю, что это усложняет задачу, но игра стоит "свеч". В использовании такой системы я выигрываю в скорости, но только при условиях, если я правильно напишу компилятор и правильно организую системные команды. К тому же, я гляжу немного вперёд. По моему замыслу, система, может быть, будет подключать плагины. Передача данных в плагинное устройство будет осуществляться по двум основным видам данных: регистры и стек. (Но я ещё не знаю, буду ли делать возможность подключения плагинов, или нет...)
Вообще, Ты меня натолкнул на очень сильную мысль, вот этой строчкой:
Quote (Devel)
реализовать класс стека для разных вещей - для обычных значений, для объектов отвечающих за переменные...
Идея заключается в системе изолированных процессов. То есть по запросу к скрипту, должен создаваться процесс с отдельно выделенной памятью. Причём функция является отдельным процессом. Помимо этого, и память для операций, и память для байт-кода должна выделяться отдельно. Но только Хеш таблицами и стеками просто так, в решении этой задачи, не отделаться.
Результат такой реализации заключается в том, что я получу отдельную машину, работающею с байт-кодом (ассемблером).
Quote (Devel)
На мой взгляд ох как зря ты ввел типы Int32,Int64 и подобные. Посмотри как сделано в lua, там есть 2 типа int и float, но собирать движок можно под разными типами, int = int32 или int64 и т.п. Тот кто пишет скрипты не будет разбираться в разрядности. Byte еще более менее оправдан.
В первой версии LPS я вообще использую только два типа: str - char*; num - double. Но только меня это не устраивает. Я хочу попробовать создать универсальную систему, для которой можно будет создать компилятор под разные языки (в том числе и C++). Поэтому я ввожу поддержку этих типов. И ещё в системе будет возможность использовать операторы направленности чисел (signed).
Quote (Devel)
Думаю еще не хватает типов: массив, объект и если есть анонимные функции - анонимная функция, все это все ссылки на самом деле, но тип нужен для движка.
Это всё я ввёл в ранг объектов. Во-первых, опыты показали, что если использовать древовидную систему данных, где к каждой "ветке" будет закреплена своя таблица, можно получить довольно огромную скорость выполнения скрипта. Но без жертв не обойтись, ведь эти все таблицы надо где то хранить, а они потребуют не мало памяти. Вот тут я немного споткнулся. Нужно, как то уменьшить размер этих таблиц...
Но эту задачу, как и все остальные я решу, если не смогу, поищу в сети, на форумах, решение похожих задач. А если не найду, то спрошу здесь, там (Как говориться, язык до Киева доведёт) .
______________________________ Я вернулся, и это чудо. ______________________________
Devel, ты, прав, самое главное - простота. А на счёт OrionPHP я наблюдаю и думаю, что у этого проекта есть своё будущее. Вообще, PHP мне нравится.
Quote (Devel)
часто когда что-то меняешь, боишься что какая-то мелочь перестанет работать, а то и хуже:
А какого мне. Я пишу в билдере шестом, а он вообще капризный, по сравнению с версией для дельфина (я так Delphi называю).
Вот допустим, у меня не получилась, как хотел, идея с байт-кодом, но получилась идея с разбитой памятью по ячейкам.
Новые эксперименты с памятью, или тест класса TFunTrack.
В статье про тест класса памяти есть упоминания о функциональной дорожке. После того, как я закончил тесты с этим классом, я принялся реализовывать идею базового класса TFunTrack. Изначально я хотел завершить эту идею и выложить информацию о конечной машине. Но результаты теста меня просто удивили, и я решил об этой системе рассказать сейчас.
Изначально, класс TFunTrack должен был работать с массивом символов, так называемой датой байт-кода. Чтение должно было происходить по средствам смещения каретки. Но сложность заключалась в том, что в памяти используется четыре основных типа: байт, число, дробь и строка. При преобразовании информации в эти типы тратится довольно много времени (мне нужны, в конечном результате вывода, именно они). Но результат был всё ровно, довольно быстрым: на создание и запись в 1 000 000 тактов движения потратилось, примерно 1,3 сек. При этом, понадобилось памяти: 23 500 Кбайт. Чтение же, (ведь это главное) на 1 000 000 тактов, потребовало 1 секунда. Казалось бы, быстро, но на 10 000 000 тактов потребуется, примерно, 10 секунд.
Но эксперименты на этом не закончились, наоборот, только начинались. И решил я использовать методику, которую использовал в GLogic. Память разложена по таблице. А таблица выглядит так: номер по порядку — дата. Но в GLogic, ячейка памяти статична, то есть при операции она копируется (поэтому, этот сценарный движок очень медленный). Тогда я изменил принцип передачи данных из полного объекта в передачу только указателя. Далее я модифицировал принцип чтения из памяти. В классе устроено несколько функций, которые двигают каретку и указатель на класс ячейки памяти. Ниже приведены эти функции, указатель, и назначения их:
void Begin() - Устанавливает каретку в начало таблицы. void End() - Устанавливает каретку в конец таблицы. void NextStep() - Продвигает каретку на один вперёд. void BackStep() - Продвигает каретку на один назад. void GoToID(int __id) - Перекидывает каретку на адрес __id. DataComand *CurretPoint - Собственно, указатель на текущий объект, где расположилась каретка.
Как раз результаты этого класса меня удивили. Скорость записи немного ниже, а скорость чтения в несколько раз ниже, чем в предыдущей разработке. Но и без жертв не обошлось. Этот класс потребовал в два с половиной раза больше памяти. В общем, вот результаты:
Тест создания и записи объектов с помощью класса TFunTrack
Количество созданных объектов: 1 000 000 Количество операций с памятью: 6 000 000 Общее количество обращений к классу: 7 000 000
Скорость заполнения: 0.8 сек. Память на одну ячейку: 64 Б. Расчётная память на 1 000 000 объектов: 62 500 кБ. Количество занятой памяти при тесте: 70 476 кБ.
Тест чтения данных из объектов по средствам класса TFunTrack
Количество объектов: 1 000 000 Количество обращений к памяти: 3 000 000 Обращение памяти через каретку. Вывод данных в переменную типа double.
Время выполнения операций: 0.3 сек.
В заключение, скажу, конечно, физическую память требует довольно большую, но скорость высокая. Этот результат тот, который мне нужен. Поэтому, по такому же принципу, я перепишу классы менеджеров памяти.
В общей сложности, я предполагаю, в полном проекте, может использоваться до 3 000 000 ячеек памяти во множествах таблиц. Так как команда будет принимать приличное количество параметров, и служить, в принципе, полноценной функцией. Но об этом позже, я предполагаю, что максимально потребуется около 300 мегабайт оперативной памяти для работы со сценарным движком.
______________________________ Я вернулся, и это чудо. ______________________________
Зачем резервировать 300 мб памяти, это же глупо. Память нужно увеличивать по мере запросов на несколько килобайт например и уменьшать иногда.
Помню я делал тесты своего стекового класса, выходило 10 000 000 итераций, где 1 раз записывается в стек и 1 раз читается из стека (push и pop), выходило где-то 100 млсек на 3.0 Pentium.
И допустим у меня есть класс TPHPEval, при запросе пользовательских функций, нужен такой класс для выполнения байт-кода, а он в себе имеет стековый класс, класс для переменных и еще по мелочи. В этом случае глупо создавать и удалять постоянно объекты класса TPHPEval. Я сделал менеджер объектов для этого класса (и не только), которые помечает используемые в данный момент объекты этого типа и находит из них свободные и возвращает их. А потом я их использую. Получается типа схемы социализма)) нет ничего индивидуального.
Сообщение отредактировал Devel - Суббота, 20 Ноября 2010, 18:49
Зачем резервировать 300 мб памяти, это же глупо. Память нужно увеличивать по мере запросов на несколько килобайт например и уменьшать иногда.
Это расчёт. Вообще, резервировать 300 мб памяти, на самом деле - глупо (тут полностью согласен). Я создаю динамическую систему, поэтому и размер будет расти со временем нагрузки.
Quote (Devel)
Помню я делал тесты своего стекового класса, выходило 10 000 000 итераций, где 1 раз записывается в стек и 1 раз читается из стека (push и pop), выходило где-то 100 млсек на 3.0 Pentium.
На MinGW у меня ещё меньше результат. Но я хочу написать двиг на Builder 6, частично используя VCL классы. Поэтому я и вытягиваю из него всю мощность. А во-вторых, я довольно не опытный программист.
Раньше только БД-шками на билдере занимался...
Здесь замут в том, что я 1 000 000 раз вызываю оператор NEW. Ну, другого варианта я просто не знаю.
Я думаю, переписать функции, которые я привёл выше, используя итератор (двухсторонний, конечно). Так скорость чтения должна возрасти в несколько раз.
______________________________ Я вернулся, и это чудо. ______________________________
Сообщение отредактировал BOOM - Суббота, 20 Ноября 2010, 18:58
, и из-за этого проект немного затянулся ) необходим объектно-ориентированный сценарный движок. Брать сторонний я не хочу. Поэтому, пособирав документацию по разным проектам, я сейчас разрабатываю более новый язык. Думаю, что на это уйдёт приличное время.