Advanced: Тема повышенной сложности или важная.
Продолжаю работу над GUI. Уже сделал тупое окно. Его можно перемещать, давать заголовок и.т.д.
Работая с менеджерами текстур и шрифтов, решил что получать все по id как-то не красиво...
Например окно имеет шрифт. Что-бы что то "нарисовать" этим шрифтом или получить его параметры нужно их получить через менеджер... Например:
Dim font_index as Long Dim Charset as String font_index = Window.FontID FontManager.GetFont(font_index).DrawText("blablabla") Charset = FontManager.GetCharset(font_index)
Что если вместо id сделать класс обертку для шрифта. Менеджер шрифтов будет хранить эти обертки. При создании шрифта, менеджер создаст обертку, сохранит себе, а пользователю отдаст не id, а указатель на обертку:
Set Font = i_fonts(index)
Set Font = Nothing
Тогда для хранения шрифта будет нужен объект, а не id. И использование шрифта становится на много проще:
Dim Charset as String Charset = Window.Font.Charset Window.Font.DrawText("blablabla")
max255
> Не правда ли намного красивее...
Да.
Все еще работаю над GUI... Пытаюсь интегрировать в класс GUI контролов текстуру...
Получается как-то не красиво... (в движке текстура - это Long индекс для менеджера, по которому он выдает инфо о ней) В процессе рендеринга постоянно дергается менеджер текстур... К примеру:
Size = Manager.GetSize(id) .... Draw(Manager.SrcSize(id).X, Managet.SrcSize(id).Y)
Подскажите как лучше выйти из положения...
Пока что вижу 2 варианта:
1)Менеджер текстур будет возвращать параметры не по одиночке, а сразу все типом. К примеру:
Data = Manager.GetTextureInfo(id) size = Data.Size mips = Data.MipLevels
2)Переделать менеджер так что-бы вместо индексов он возвращал интерфейсы виртуальных текстур. ТЕ ячейка менеджера текстур будет содержать:
- D3D текстуру
- Интерфейс виртуальной текстуры(содержащий всю информацию о ней и свой индекс в менеджере)
- Счетчик ссылок
После создания текстуры менеджер создаст виртуальной интерфейс текстуры, заполнит его данными и сохранит себе в ячейку, а юзеру отдаст указатель на этот интерфейс...
ТЕ мы получаем уже не голый индекс а указатель на класс. И можем получить все что нам нужно так:
Dim tex as MXTexture Set tex = Manager.LoadTexture() size = tex.Size mips = tex.MipLevels
Почему бы просто не сделать так:
Dim Tex As Direct3DTexture9 Set Tex = Manager.GetTexture(id)
Mikle
> Или я не до конца понял твою организацию.
Да...
Все что я писал выше относится к менеджеру текстур. А за гуи я говорил в том смысле, что гуи контролы хранят индексы текстур. И ими неудобно пользоваться...
К примеру: хочу я получить размеры текстуры той что использует какой-то контрол. Тогда я прошу у него индекс его текстуры, потом бегу к менеджеру текстур, что бы получить размер текстуры.
Dim index as Long Dim size as D3DVECTOR2 index = GUIControl.TextureID size = TextureManager.GetSize(index)
Mikle
> Почему бы просто не сделать так:
Эта фишка уже давно работает... Ее минус в том что интерфейс Direct3DTexture9 нужно "убивать" при каждом ресете...
Представь что менеджер раздал сотни этих интерфейсов... При ресете их все нужно найти и высвободить...
Тем более Direct3DTexture9 не хранит всей нужной информации... К примеру исходный размер текстуры, была ли она растянута до POW2, путь файла загрузки...
Вот накидал блок схему менеджера текстур который я предлагал в п.317 пункт 2)
max255
> Эта фишка уже давно работает... Ее минус в том что интерфейс Direct3DTexture9
> нужно "убивать" при каждом ресете...
Я о том, чтобы ссылка Tex в функциях была локальной, то есть функция, работающая с текстурой, получает в начале ссылку на нужную текстуру через id, один раз, дальше работает через ссылку. Когда функция завершится - ссылка уничтожится, Reset до этого произойти не может, если только ты внутри функции не выполнишь, прямо или косвенно, DoEvents.
Так что с Reset-ом проблем не должно быть, а если нужна какая-то дополнительная информация, которую не может дать текстура - тогда твой вариан №1, то есть делаешь свой дескриптор, но это не класс, а структура.
Как относится к публичным интерфейсам в двидке?
С разростанием архитектуры их становится все больше... К примеру g_dev(D3DDevice), g_tex(текстурный менеджер), g_shader(буфер констант).
Рассматриваю вариант наследования интерфейсов:
Т.Е. дочерний интерфейс наследует родителя и работает ТОЛЬКО с ним(что бы не создавать путаницы), работать с нижним слоем он НЕ МОЖЕТ.
Render->Render2D->Sprite
Насколько понимаю, речь не про наследование, а про контейнеры?
Примерно так... Т.Е. класс потомок включает в себя указатель на класс родитель. Таким образом можно получить доступ ко всем нужным интерфейсам...
Что если GUI надстроить над движком, а не создавать в движке. И инициализировать его (или не делать этого) сразу после инициализации движка. Тогда ему будут доступны все возможности движка, как и игровой логике. Или я чего-то недопонимаю?
Morhoom
У меня так и делается... После старта всех подсистем двига(директ, менеджер текстур, менеджер шрифтов) запускается гуи и юзает эти надстройки...
Ааа, а я подумал, что работа с менеджером это какие-то внутринние операции.
А куда разместить обьект LOG и таймер? Он часто используется всеми классами двига, и самим пользователем...
Его засунуть в ядро движка и потом наследовать или сделать его глобальным?
А то:
'код вывода лога в спрайте me.render2d.render.core.log.print()
Конечно, лог нужно делать глобальным.
Разбираюсь с менеджером шейдеров... Этот интерфейс будет загружать шейдеры(2 отдельных менеджера - пиксельный и вертексный или общий с контейнером object и указанием на тип шейдера?) с диска и проверять на факт повторной зарузки. Так же хранить буферы констант для шейдеров(нужно ли буферизировать bool и integer константы? Сейчас есть специальный тип для них, который заполняется и устанавливается полбзователем).
Mikle
> Так что с Reset-ом проблем не должно быть
А если ресет по прерыванию... Скажем Alt-Tab...
Тема в архиве.