MXEngine & dx_vb (22 стр)

Продолжаю работу над 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...