Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / C++ Взаимодействие интерфейсов на уровне реализаций. (3 стр)

C++ Взаимодействие интерфейсов на уровне реализаций. (3 стр)

Поделиться

Страницы: 1 2 3 4 5 6 Следующая

loysoПостоялецwww10 ноя. 20176:54#30
Suslik
> про какой-то сакральный смысл, недоступный тем, у кого в 2003 ещё лысины не
> было?
Я не спорю - та статья скомканная и много промежуточных шагов понимания пропускает.
Там полиморфизм - опущенная часть картины как раз.
Ибо тривиально, "если объект поддерживает view1, то вот этот кусок кода; если view2 - то тот кусок кода; а если view1 И view2 (сложные mixins) -  то третий".
Классический "компонентный объект", как "запчасти" в аллодах онлайн (было выступление).

Однако мои предыдущие высказывания - отчасти про другое.
Я постараюсь набросать как-нибудь дубовый код на github потом.
С mixins, "внешним полиморфизмом" и селекторами на if/else.
С кодогеном, но он лишь - средство. Можно и без него.

SuslikМодераторwww10 ноя. 20177:00#31
loyso
> Я постараюсь набросать как-нибудь дубовый код на github потом.
так там набрасывать-то полэкрана кода, чтобы идею передать. я, если честно, не хочу обмазываться разговорами об архитектуре игровых объектов, потому что это никогда до добра не доводит: слишком много теоретических рассуждений и вкусовщины, слишком мало практических критериев. поэтому давай лучше на классическом примере той же физики или рендера. создать текстуру, создать рендертаргет для n-го мипа этой текстуры, забайндить текстуру в шейдер — вот все эти житейские проблемы.
loysoПостоялецwww10 ноя. 20177:05#32
Suslik
> поэтому давай лучше на классическом примере той же физики или рендера
Ай, здаюс здаюс! Я уже кинул ссылки на chromium и command buffer с resources. Там не пол экрана кода :) Позорно убегаю к своим игровым объектам и их столкновениям.
SuslikМодераторwww10 ноя. 20177:32#33
loyso
> Я уже кинул ссылки на chromium и command buffer с resources
ты ж сам сказал, что там ад и содомия. поэтому я и прошу в студию простой пример "как надо".
kasПостоялецwww10 ноя. 20177:35#34
Suslik
> вообще я эту проблему считаю принципиальной. в случае коллижнов ещё более-менее
> ясно, потому что количество типов взаимодействующих геометрий обычно
> ограничено. а как быть со случаями, которые by design подразумевают
> взаимодействие объектов одной системы на уровне интерфейсов? один из
> классических примеров — мультирендер. вызов, например, такой:
помоему в рендере все как раз тривиально. динамический полиморфизм, а следовательно и интерфейсы не нужны, волевым решением. и все проблемы уходят.
SuslikМодераторwww10 ноя. 20177:38#35
kas
> динамический полиморфизм, а следовательно и интерфейсы не нужны
звучит невероятно интригующе. давай код.
loysoПостоялецwww10 ноя. 20177:39#36
Suslik
> ты ж сам сказал, что там ад и содомия. поэтому я и прошу в студию простой
> пример "как надо".
Там очень много деталей, о которых ты печешься и где весь дьявол.
И легко за деревьями леса не увидеть.

Chromium - отличный жизненный пример с миллионами строк кода, кроссплатформенностью, vulkan (в процессе) и блекджеком.
Если просто: renderer - это такой pipes and filters паттерн (pipeline). HTML DOM дерево передается от подсистемы к подсистеме и "трансформационно преображается" во всякие display lists 100500 видов и заканчивается в виде command буфера с ресурсами (тоже многа видов).

Правка: 10 ноя. 2017 7:46

SuslikМодераторwww10 ноя. 20177:46#37
loyso
> HTML DOM дерево передается от подсистемы к подсистеме и "трансформационно
> преображается" во всякие display lists 100500 видов и заканчивается в виде
> command буфера с ресурсами.
и снова ты слишком далеко вглубь уходишь. вопрос-то в названии треда — гораздо более узкий и поверхностный, однако, даже на него нормальный ответ найти трудно. а именно, как в этом самом display list'е (или любом другом механизме, посредством которого бизнес-код общается с рендером), реализуется ссылка на ресурс? узкая проблема заключается в том, что ресурс в общем случае оказывается очень трудно полностью отделить от рендера, для которого его предполагается использовать, что вызывает проблему при взаимодействии абстрактного ресурса и абстрактного рендера, которые могут друг другу не принадлежать, вот и всё.

Правка: 10 ноя. 2017 7:47

kasПостоялецwww10 ноя. 20177:51#38
Suslik
> звучит невероятно интригующе. давай код.

https://gist.github.com/fatkas/79e401d2a44507235cee4f3ae5f0cf9a продолжать?

loysoПостоялецwww10 ноя. 20177:54#39
Suslik
> вопрос-то в названии треда
Я запутался совсем - тред вообще про 2d dispatch.

Ресурсы напоминают те хендлы GAPI, что ты писал.
https://cs.chromium.org/chromium/src/cc/resources/resource_provider.h и миллион xref далее.
Вон, Казик все правильно обьясняет (только у него все в compile time. и pipeline-представлений не видно, ибо в его подоходе не нужны)

Правка: 10 ноя. 2017 8:07

SuslikМодераторwww10 ноя. 20178:07#40
kas
> https://gist.github.com/fatkas/79e401d2a44507235cee4f3ae5f0cf9a продолжать?
конечно! а внутри у SetTexture() ты предлагаешь ещё одну простыню #define'ов?

loyso
> https://cs.chromium.org/chromium/src/cc/resources/resource_provider.h и миллион xref далее.
скопирую оттуда релевантную треду строчку:

 // Creates a resource of the default resource type.
  viz::ResourceId CreateResource(const gfx::Size& size,
                                 viz::ResourceTextureHint hint,
                                 viz::ResourceFormat format,
                                 const gfx::ColorSpace& color_space);
то есть хромовский ответ на вопрос в названии треда — не использовать интерфейсы вообще, использовать вместо них интовые айдишники. такой подход а-ля opengl, конечно, можно считать решением и, признаться я и сам его использую. но от идеала он далёк по ряду причин:
- неудобно отлаживать. по одному лишь айдишнику ничего о ресурсе не узнаешь.
- небезопасно. ничего не стоит обратиться к несуществующему ресурсу или к ресурсу, созданному для другого рендера.
- каждый ресурс перестаёт быть независимой сущностью и полностью зависит от системы, которой принадлежит. это значит, что весь код собирается в кучу, его трудно разделять.
- теряется вся идея ооп, где объект объединяет в себе данные и методы работы с ними. все данные всех ресурсов становятся данными рендера, а все методы ресурсов — его методами.

Правка: 10 ноя. 2017 8:08

loysoПостоялецwww10 ноя. 20178:12#41
Suslik
> использовать вместо них интовые айдишники
Все так. Это не C++ class-based OOP конечно.
Я кидал ссылку на https://en.wikipedia.org/wiki/Algebraic_data_type и он же https://en.wikipedia.org/wiki/Tagged_union
ResourceType - и есть полиморфизм.
Полезно думать про вопрос: "что является селектором при runtime диспатче?"
Селектором может быть int resourceType. А может быть наличие или отсутствие определенного набора mixin с данными
(запчасти аллодов онлайн)
и т.д.

Но я помню что решения "вне C++" ты не приемлешь.

kasПостоялецwww10 ноя. 20178:14#42
Suslik
> конечно! а внутри у SetTexture() ты предлагаешь ещё одну простыню #define'ов?
очевидно нет. https://gist.github.com/fatkas/79e401d2a44507235cee4f3ae5f0cf9a продолжать?
loysoПостоялецwww10 ноя. 20178:19#43
Suslik
> теряется вся идея ооп, где объект объединяет в себе данные и методы работы с
> ними. все данные всех ресурсов становятся данными рендера, а все методы
> ресурсов — его методами.
Все так.
Далее оффтопик про ООП в широком смысле (как отцы computer science учили): Можно лишь отнестись философски - объект и его поведения уходят на метауровень.
И ты можешь в "отображении объекта в C++" транспонировать данные объекта SoA vs AoS. Или менять methods на extension methods (v.begin() vs begin(v) - uniform C++ syntax, UFCS прости господи)

Это похоже на стек языков. Где есть DSL язык игры поверх C++.
И как в C++ ты понимаешь разницу между inline template constexpr функцией и ее выхлопом в асм коде (она просто растворяется в контекстах и тебе пофиг почти, лишь бы работало быстро),
так и в случае с "C++ представлением игрового объекта" - оно размазывается.

Правка: 10 ноя. 2017 8:29

innuendoПостоялецwww10 ноя. 20178:24#44
loyso
> Я не спорю - та статья скомканная и много промежуточных шагов понимания
> пропускает.

Это всё лирика, основная претензия, что это работает только на жёстком ТЗ. Что там было - конзольный авиасим? Ты попробуй такое сделать для стратежки типа Civ5 с кучей аддонов и тд. Или там MMO всякие

Страницы: 1 2 3 4 5 6 Следующая

/ Форум / Программирование игр / Общее

2001—2017 © GameDev.ru — Разработка игр