Войти
WarZesФорум

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

Страницы: 1 2 3 4 Следующая »
#15
20:46, 11 июня 2013

Мух
ну это ж для тестов.


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

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

DX\GL - нет, а DX9/11 было

#17
6:04, 12 июня 2013

IROV..
> код чистый, оптимизаторы довольны!
Нет, так же как и Feo, это не чистый код.... В твоем случае из-за того что придется глобальные переменные юзать. Тогда уж

typedef DX11Render Render;
Будет намного чище. Для чего у нас общий класс Render? Для уменьшения копипаста, чтобы общий между двумя классами функционал не писать в классах рендера.

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

#18
10:49, 12 июня 2013

Вместо того, чтобы писать код и логику, мы сидим ночью и думаем, как сэкономить 4 байта.

#19
12:52, 12 июня 2013

Ockonal
> Вместо того, чтобы писать код и логику, мы сидим ночью и думаем, как сэкономить
> 4 байта.
Нет, то что я написал я еще даже не делал в самом движке - у меня сейчас нет на это времени.

#20
14:41, 12 июня 2013

Мне подход Feo больше нравится, чем эти #ifdef-ы. В CryEngine по похожему пути сделано. Только без currentRenderer.

#21
20:57, 12 июня 2013

Сделал небольшой тест на виртуальные функции. В целом у меня виртуальные работают в 5-6 раз медленнее невиртуальных функций.
Тестил функцию a+b.
Но в абсолютных значениях это невероятно малые числа.
Для получения следующего количества тиков я вызвал функцию 100000000 раз:

virtual 713358
non virtual 102195
universal 102880

Вариант с универсалом:

class B
{
public:
  inline int dosmth(int a,int b)
  {
    return a+b;
  }
};

class C
{
public:
  inline int dosmth(int a,int b)
  {
    return a-b;
  }
};

class Universal
{
  B obj;
  C obj2;
  int current;
  
public:

  Universal()
  {
    current=1;change();
  }

  void change()
  {
    current=1-current;
  }

  inline int dosmth(int a,int b)
  {
    if(current)
      return obj.dosmth(a,b);
    else
      return obj2.dosmth(a,b);
  }
};

Одна проверка на текущий класс как получилось практически не влияет на производительность, но зато дает возможность динамически менять рендерер.

ПС Я в тестировании производительности еще новичок, вот полный код теста:

+ Показать

#22
21:59, 12 июня 2013

wat
> В CryEngine по похожему пути сделано.

Нельзя ли узнать - на какой рендер ориентировались отцы CE ? UE ?

#23
22:01, 12 июня 2013

Che@ter
> Сделал небольшой тест на виртуальные функции. В целом у меня виртуальные
> работают в 5-6 раз медленнее невиртуальных функций.

Этот вопрос ( про рендер с виртуальными ) обмусоливался N раз - если хорошо подумать и свести виртуальные вызовы к минимуму очень даже можно жить.

#24
23:43, 12 июня 2013

innuendo
>Нельзя ли узнать - на какой рендер ориентировались отцы CE ? UE ?

обычно крупные компании любят все разделять, потому что есть ресурсы для обработки всех платформ по отдельности.
но с анрилом немного сложнее.
есть версии двигла для каждой платформы отдельно, но вот UDK поставляется одним exe'шником, и поддерживает как DX9/11 так и OGL под iOS, причем переключение на мобильные фичи редактор эмулирует в рантайме.

прямого перехода между рендерами в двигле нет, так что возможно там все таки какие то ifdef'ы, но динамические...
чушь какую то говорю.

#25
1:55, 13 июня 2013

Che@ter
> Сделал небольшой тест на виртуальные функции. В целом у меня виртуальные
> работают в 5-6 раз медленнее невиртуальных функций.
> Тестил функцию a+b.

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

#26
5:07, 13 июня 2013

war_zes
> + Показать
Лучше бы продолжил патерны изучать. Дело полезнее, чем думать о взаимодействии двух рендеров, которое тебе не понадобится.

#27
5:43, 13 июня 2013

продолжу:) сессию только закрою

#28
7:13, 13 июня 2013

redbox
> но с анрилом немного сложнее.

Когда делали CE - был ещё старый добрый UE с выбором рендера ( вынесен в отдельную DLL ). В FarCry\Crysis можно динамический менять

#29
12:09, 13 июня 2013

Che@ter
Никогда не меряй производительность виртуальных функций с а+б!

Вызов виртуальной функции сам по себе подразумевает вычисление адреса и call из памяти по этому самому адресу.
Грубо говоря, сам вызов вирт. функции - это как раз твоё а+б, приправленное call`ом из памяти. Ессно если так считать, то она будет как минимум в 2 раза медленнее.

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

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