Войти
Вело-изобретателиФорумMXEngine - движок для VB6

MXEngine & dx_vb (22 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 121 22 23 2426 Следующая »
#315
12:59, 22 янв. 2012

Продолжаю работу над 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
В этот момент обертка обратится к менеджеру(используя указатель и индекс) и сообщит об удалении. Менеджер уменьшит рефкаунтер, и если он уйдет в 0 удалит шрифт.

Тогда для хранения шрифта будет нужен объект, а не id. И использование шрифта становится на много проще:

Dim Charset     as String
   Charset = Window.Font.Charset
   Window.Font.DrawText("blablabla")
Не правда ли намного красивее...


#316
14:37, 22 янв. 2012

max255
> Не правда ли намного красивее...
Да.

#317
21:22, 3 фев. 2012

Все еще работаю над GUI... Пытаюсь интегрировать в класс GUI контролов текстуру...
Получается как-то не красиво... (в движке текстура - это Long индекс для менеджера, по которому он выдает инфо о ней) В процессе рендеринга постоянно дергается менеджер текстур... К примеру:

 Size = Manager.GetSize(id)
 ....
 Draw(Manager.SrcSize(id).X, Managet.SrcSize(id).Y)
Да и к тому же получаяя текстуру от GUI контрола имею просто id... И опять нужно обращаться к менеджеру и "клянчить" параметры текстуры...

Подскажите как лучше выйти из положения...
Пока что вижу 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


#318
9:53, 4 фев. 2012

Почему бы просто не сделать так:

Dim Tex As Direct3DTexture9
Set Tex = Manager.GetTexture(id)
А дальше всё получать у самой Tex. Зачем тебе счётчик ссылок на текстуру в GUI? Это внутреннее дело менеджера текстур.
Или я не до конца понял твою организацию.

#319
12:43, 4 фев. 2012

Mikle
> Или я не до конца понял твою организацию.
Да...

Все что я писал выше относится к менеджеру текстур. А за гуи я говорил в том смысле, что гуи контролы хранят индексы текстур. И ими неудобно пользоваться...
К примеру: хочу я получить размеры текстуры той что использует какой-то контрол. Тогда я прошу у него индекс его текстуры, потом бегу к менеджеру текстур, что бы получить размер текстуры.

Dim index as Long
Dim size   as D3DVECTOR2

index = GUIControl.TextureID

size = TextureManager.GetSize(index)

Mikle
> Почему бы просто не сделать так:
Эта фишка уже давно работает... Ее минус в том что интерфейс Direct3DTexture9 нужно "убивать" при каждом ресете...
Представь что менеджер раздал сотни этих интерфейсов... При ресете их все нужно найти и высвободить...
Тем более Direct3DTexture9 не хранит всей нужной информации... К примеру исходный размер текстуры, была ли она растянута до POW2, путь файла загрузки...

Вот накидал блок схему менеджера текстур который я предлагал в п.317 пункт 2)
Manager | MXEngine & dx_vb

#320
13:04, 4 фев. 2012

max255
> Эта фишка уже давно работает... Ее минус в том что интерфейс Direct3DTexture9
> нужно "убивать" при каждом ресете...
Я о том, чтобы ссылка Tex в функциях была локальной, то есть функция, работающая с текстурой, получает в начале ссылку на нужную текстуру через id, один раз, дальше работает через ссылку. Когда функция завершится - ссылка уничтожится, Reset до этого произойти не может, если только ты внутри функции не выполнишь, прямо или косвенно, DoEvents.
Так что с Reset-ом проблем не должно быть, а если нужна какая-то дополнительная информация, которую не может дать текстура - тогда твой вариан №1, то есть делаешь свой дескриптор, но это не класс, а структура.

#321
12:40, 11 мар. 2012

Как относится к публичным интерфейсам в двидке?
С разростанием архитектуры их становится все больше... К примеру g_dev(D3DDevice), g_tex(текстурный менеджер), g_shader(буфер констант).
Рассматриваю вариант наследования интерфейсов:
Т.Е. дочерний интерфейс наследует родителя и работает ТОЛЬКО с ним(что бы не создавать путаницы), работать с нижним слоем он НЕ МОЖЕТ.

Render->Render2D->Sprite
Спрайт обращается к рендеру2д с задачей нарисовать квад с определенным цветом. Материал и шейдер спрайт ставит сам(через класс "шейдер").
Рендер2д собирает батчи ставит стейты бленда и рисует все. Класс рендер - класс конструктор(в дальнейшем создающий рендер3д и хранящий в себе менеджер текстур).

#322
19:09, 11 мар. 2012

Насколько понимаю, речь не про наследование, а про контейнеры?

#323
1:26, 12 мар. 2012

Примерно так... Т.Е. класс потомок включает в себя указатель на класс родитель. Таким образом можно получить доступ ко всем нужным интерфейсам...

#324
23:34, 12 мар. 2012

Что если GUI надстроить над движком, а не создавать в движке. И инициализировать его (или не делать этого) сразу после инициализации движка. Тогда ему будут доступны все возможности движка, как и игровой логике. Или я чего-то недопонимаю?

#325
23:45, 12 мар. 2012

Morhoom
У меня так и делается... После старта всех подсистем двига(директ, менеджер текстур, менеджер шрифтов) запускается гуи и юзает эти надстройки...

#326
4:13, 13 мар. 2012

Ааа, а я подумал, что работа с менеджером это какие-то внутринние операции.

#327
11:37, 13 мар. 2012

А куда разместить обьект LOG и таймер? Он часто используется всеми классами двига, и самим пользователем...
Его засунуть в ядро движка и потом наследовать или сделать его глобальным?

А то:

'код вывода лога в спрайте
me.render2d.render.core.log.print()
как то не смотрится...

#328
11:47, 13 мар. 2012

Конечно, лог нужно делать глобальным.

#329
20:07, 16 мар. 2012

Разбираюсь с менеджером шейдеров... Этот интерфейс будет загружать шейдеры(2 отдельных менеджера - пиксельный и вертексный или общий с контейнером object и указанием на тип шейдера?) с диска и проверять на факт повторной зарузки. Так же хранить буферы констант для шейдеров(нужно ли буферизировать bool и integer константы? Сейчас есть специальный тип для них, который заполняется и устанавливается полбзователем).

Mikle
> Так что с Reset-ом проблем не должно быть
А если ресет по прерыванию... Скажем Alt-Tab...

Страницы: 121 22 23 2426 Следующая »
Вело-изобретателиФорумMXEngine - движок для VB6

Тема в архиве.