Шаг "один с половиной" ... :)
Автор: Oldman
Катострофически не хватает времени доделать второй шаг по-нормальному, а сообщество понизилось, дальше некуда ... Поэтому выкладываю шаг "первый с половиной". Окончательно к готовности второго шага некоторые части будут переделаны, так как мне самому не нравятся ... :) Итак, кратко о новом ...
На этот раз существует первая реализация интерфейса AEngine, будущий движок, наконец, обзавелся окном. Несколько дополнений и исправлений в библиотечке ae_lib.
Начата реализация интерфейса рендера. Еще пока думаю, стоит ли делать поддержку стандартного блока T&L, или делать полностью программируемый конвеер. Скорее всего, остановлюсь на 2-ом варианте. Таким образом, минимальным требованием станет поддержка vs/ps 1.0.
Пришлось сделать новую DLL для менеджера памяти … Дело в том, что компоненты(модули) движка разделяют между собой различные объекты, которыми оперируют, при этом производя перераспределение памяти в этих объектах. Соответственно возникают ситуации, когда компонент из одного модуля пытается освободить память выделенную в другом модуле. Одним из решений этой проблемы является создание собственного менеджера пямяти. Сначала менеджер памяти предполагалось реализовать в system.dll, но при этом не перегружались операторы управления памятью, находящиеся в ae_lib. Таким образом, возникла необходимость, чтобы компонента менеджера памяти собиралась первой.
Движок обзавелся классом AEValue – классом для хранения и передачи переменной произвольного (почти произвольного) типа. Подозреваю, что его реализация станет предметом для нарицаний. Действительно, работа данного класса порождает множество операций по выделению-освобождению памяти, при чем, достаточно малыми порциями. На геймдев не так давно поднималась тема по этому поводу, и насколько я помню там пришли к мнению, что значение надо хранить статически, объединяя разные типы посредством union. Но если я хочу хранить в переменной значения от одного байта до матрицы 4х4, то минимальный размер элемента класса AEValue будет sizeof(mat44) + sizeof(TypeId) + еще какое-то количество байтов для выравнивания, даже если я храню в нем переменную размером в байт. А при большом количество переменных это не есть хорошо … С другой стороны частое выделение-освобождение маленьких блоков памяти тоже плохо. Я выбрал нечто среднее … :)
Сама структура организации движка подразумевает что интерфейс AEngine будет знать о своих компонентах все, но в тоже время компоненты не будут знать об интерфейсе AEngine ничего. В этом случае необходимо определить, как компоненты будут влиять на работу AEngine. Самый очевидный выход: система сообщений. Компоненты помещают сообщения в очередь, а AEngine их обрабатывает. Таким же образом движок будет общаться с отдельным потоком подзагрузки. (В разработке)
Класс AEWindow я реализовал в system.dll и экспортировал функцию для создания экземпляра этого класса. С одной стороны, логично было бы его сделать частью engine.dll, но с другой стороны, мне хотелось всю OS-specific информацию реализовать в одном месте. Поэтому та же участь постигла и класс для работы с устройствами отображения (кАроче, дисплеями) AEDisplay.
В настройках проектов было отключено детектирование 64-битного процессора, то есть проект настроен под 32-битную адресацию. Это сделано чтобы избежать предупреждений при приведении типа int к типу указателя и наоборот. Не очень хорошее решение, учитывая ближайшее будущее за 64-битными технологиями. В ближайшее время нужно будет что-то делать с этим …
Проект собран буквально вчера, только избавился от ошибок. На компах кроме своего не тестировал, поэтому могу только сказать, что на моем отрабатывает. Качать здесь.
11 мая 2006
Комментарии [3]