Войти
WarZesФорум

Виртуальные функции в системе рендера (комментарии)

Страницы: 1 2 3 4 Следующая »
#0
8:06, 10 июня 2013

Виртуальные функции в системе рендера (комментарии)

Это сообщение сгенерировано автоматически.

#1
8:06, 10 июня 2013

и как обычно - нигде такого не видел:)

#2
10:24, 10 июня 2013

http://flohofwoe.blogspot.com/2007/02/getting-rid-of-virtual-method-calls.html

#3
11:13, 10 июня 2013

redbox
Это не совсем то (у меня примерно так и было).
Проблема в том что иногда надо чтобы движок мог переключаться между OGL и DX11 без  его пересборки (то есть во время запуска). И даже если для игрока это не нужно, это нужно мне - для проверки шейдеров и прочего в разных GAPI (а там еще и физика, я до сих пор не решил что лучше bullet или physX). Но и делать полностью мультирендерным (как например Ogre) я не хотел, из-за виртуальных функций, а подключать dll либы при запуске я еще не умею у меня все либы статичные.
И сегодня мне пришла такая вот идея. Теперь я могу собрать мультирендер для написания общих шейдеров и прочих эффектов движка. А уже под игру собирать определенный GAPI (без виртуальных функций)

#4
11:16, 10 июня 2013

ну это просто на тему.

#5
19:24, 10 июня 2013

А чем не угодили виртуальные функции?

#6
19:35, 10 июня 2013

Barabus
> А чем не угодили виртуальные функции?
ну хоть на сколько-то они медленней обычных (вот и проверю - насколько), так что еще базово в архитектуре стараюсь без них

#7
20:27, 10 июня 2013

а как же полиморфизм, инкапсуляция...

хотя теперь рендер должен знать о своим потомках

это не плохо, если у рендерера есть поле вроде Renderer *currentRenderer, которое ты в каком нибудь месте проинициализируешь нужным рендерером (dx/ogl) (вот именно тут и можно сделать перключение без пересборки). ну и, соответственно, родитель рендерер должен вызывать методы current renderer'а в своих, а в рендерере–потомке, как обычно логика.
псевдокод:
// Renderer.h
class Renderer {
public:
  Renderer *currentRenderer;
  virtual void setTexture(Texture *texture);
};

// Renderer.cpp
void Renderer::setTexture(Texture *texture) {
  currentRenderer->setTexture(texture);
}

// OGLRenderer.h
class OGLRenderer : public Renderer {
public:
  void setTexture(Texture *texture);
};

// OGLRenderer.cpp
void OGLRenderer::setTexture(Texture *texture) {
  texture->setEnabled(true);
}

// Something else
Renderer *renderer = new Renderer();
renderer->currentRenderer = new OGLRenderer();
паттерн немного противоречивый, но в некоторых случаях показывает себя с хорошей стороны.

во всех остальных случаяъ это плохо.
к тому же, виртуальные функции только для программистов, в машинный код они не транслируются. следовательно, при использовании виртуальных функций, замедлиться может только сборка.

#8
4:12, 11 июня 2013

Feo
> к тому же, виртуальные функции только для программистов, в машинный код они не
> транслируются. следовательно, при использовании виртуальных функций,
> замедлиться может только сборка.
вообще-то нет, виртуальная таблица идет в код, и вызов виртуальной функции медленней из-за поиска в этой самой таблице.
http://www.parashift.com/c++-faq-lite/dyn-binding.html

Non-virtual member functions are resolved statically. That is, the member function is selected statically (at compile-time) based on the type of the pointer (or reference) to the object.

In contrast, virtual member functions are resolved dynamically (at run-time).

#9
9:05, 11 июня 2013

war_zes
> > А чем не угодили виртуальные функции?
> ну хоть на сколько-то они медленней обычных (вот и проверю - насколько), так
> что еще базово в архитектуре стараюсь без них

Уважаемый, в вашем положении об скорости думать пока ещё очень рано :) Не насилуйте мозг - юзайте виртуальные

#10
9:11, 11 июня 2013

innuendo
> Уважаемый, в вашем положении об скорости думать пока ещё очень рано :) Не
> насилуйте мозг - юзайте виртуальные
Не насилую мозг:) решение простое, архитектуре не вредит

#11
9:47, 11 июня 2013

Feo
> к тому же, виртуальные функции только для программистов, в машинный код они не
> транслируются. следовательно, при использовании виртуальных функций,
> замедлиться может только сборка.

???

#12
13:21, 11 июня 2013

Feo
Это изврат, не надо так делать.

#13
16:22, 11 июня 2013

war_zes
если уж сильно хочешь сделать ВОТ_ТАК без виртуальных функций(хотя это самый правильный вариант)
то делаешь просто

Render.h
RenderGL.cpp
Render
{
void draw()
{
DXDraw();
}
}

Render.h
RenderGL.cpp
Render
{
void draw()
{
GLDraw();
}
}

А в проекте выбираешь нужный тебе cpp + include dir
GL/Render.h
DX/Render.h

и ВСЕ!

код чистый, оптимизаторы довольны!

#14
19:09, 11 июня 2013

Ну вот зачем и кому в 21 веке может потребоваться переключать рендер у движка? Ну зачем? В каком из современных крупных тайлов (а ведь движок именно под такие проекты делает ага) вы видели возможность выбора рендера GL/DX? Да и зачем это сейчас нужно в принципе? На выходе все равно картинка одинаковая, а все остальное уже зависит исключительно от опыта разработчика

Страницы: 1 2 3 4 Следующая »
WarZesФорум

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