GameDev.ru
/ GameDev.ru / Пользователи / Andrey / Сообщения на форуме пользователя Andrey (48 стр.)

Сообщения на форуме пользователя Andrey (48 стр.)

glBindTexture28 июня 201011:14#20
Larik
> glBegin ( GL_QUADS );
> glEnd();
Вынеси вынеси это за цикл  и сравни FPS
GameDev.ru 9 лет! (комментарии)26 июня 201019:18#7
Поздравляю! А чего одни участники поздравляют? Надеюсь постояльцем тоже разрешено?
получение углов поворота с матрицы21 июня 201015:15#2
Bashka
> незнаю в правельный ли раздел запостился ?
лучше в раздел графики.
Вот попробуй. Но я не проверял правильность.
Матрица хранится у меня так
0 4 8  12
1 5 9  13
2 6 10 14
3 7 11 15
где позиция к примеру это последний столбец (x = 12, y = 13, z = 14)
INLINE void GetRollPitchYaw(float& pitch, float& yaw, float& roll) const
    {

      float D = asinf(Matrix[8]);  // Calculate Y-axis angle
      float C = cosf(D);

      yaw = D;

      if (fabs(C) > EPS) {
        float invC = 1.0f / C;

        float x = Matrix[10] * invC;  
        float y = -Matrix[9] * invC;  
        pitch = atan2f(y, x);      // atan2f(y, x) = atanf(y / x)

        x = Matrix[0] * invC;
        y = -Matrix[4] * invC;
        roll = atan2f(y, x);
      }
      else {
        pitch = 0.0f;        // Set X-axis angle to zero
        float x = Matrix[0];      // And calculate Z-axis angle
        float y = -Matrix[4];
        roll = atan2f(y, x);
      }
    }
Новая демка (комментарии)21 июня 201010:22#4
scorch
Про дерево не понял. Дрова новые карта 8600 GT. А что тут непонятно? 4 танка 60 FPS 1 танк 150 FPS.
причем частицы там не сложные. Итого вывод - убивает CPU кодом Delphi либо память часто выделяет/удаляет для живых/мертвых. Я же не знаю ка оно там реализовано. Или ты думаешь той графикой, сложностью, полигонажем сцены можно убить FPS ? Тут CPU bound однозначно.
Новая демка (комментарии)20 июня 201021:55#2
Неплохо. поставил разрешение 1280x1024 полноэкранный. FPS - очень маловат.
6 танков в кадре. Полигонов мало, сцена не загруженная. Тормозят дико у тебя частицы и игровая логика + убогий компилятор на Delphi. Когда отъезжаешь и виден 1 танк FPS растет. И вообще зачем на Delphi то?
Почему я никогда не буду использовать STL.18 июня 201015:34#829
innuendo
> так ты за или против refCounters ? :)
я еще исследую данный вопрос.
Почему я никогда не буду использовать STL.18 июня 201014:53#827
Drampir
> > есть же std::auto_ptr
> он разрабатывался только для обработки исключений в случае утечек памяти,
> поэтому следует из boost использовать другие умные указатели. Кроме того
> auto_ptr и STL вещи абсолютно не совместимые друг с другом, т.к. внутри
> контейнеров идет присваивание, поэтому auto_ptr передают права владения,
> поэтому про auto_ptr можно забыть.
ни в коем случае никто не говорит про присвоение и связь с STL. Речь от том что-бы не было delete в коде следует использовать std::auto_ptr,  boost зачастую избыточен, можно вполне избежать при проектировании/разработке таких конструкций как std::vector<boost::shared_ptr<T> >
Почему я никогда не буду использовать STL.18 июня 201012:26#820
innuendo
> > new/delete запрещены вообще
> совсем-совсем ?
delete точно не нужен, есть же std::auto_ptr. без new можно в большинстве случаев обойтись.
Почему я никогда не буду использовать STL.17 июня 201016:55#755
Executor
>а то что статический массив в 10-100-1000 раз больше сцены
Речь в частности идет про массив для сбора RenderQueue его то и можно(и нужно!) ограничить. Да число объектов ну уровне тоже можно ограничить при желании, но тут уже сложнее.
по остальному тебе развернутый ответ дал Xunter
Я со всем согласен.
Почему я никогда не буду использовать STL.17 июня 201014:09#749
Outlaw
> ты же по мухам из пушки не стреляешь, зачем эти все reserve? чтобы сделать
> push_back только?, ну так и в обычный массив добавить элемент в конец
> так же просто, одна строчка кода. я не против vector'а нет, тут он избыточен
> просто.
+1
Executor
> Пока ты, к примеру, с диска не загрузишь информацию о том, сколько объектов
> может быть, откуда тебе знать сколько их?
> Вот ты от сцены к сцене меняешь размер массива...
Ничего не меняется. Обычно в двоичном файле сцены известно число объектов. Да и сцена проектируется под определенное число объектов в кадре. Ну не нужно действительно более 5000 к примеру видимых объектов иметь.
> Можно конечно сделать статику в виде стопицот элементов, но зачем? Если на
> половине сцен даже до трети этого размера не дойдёт, память девать некуда
> чтоли?
Какая память? на 20 кб зарезервированного массива в сегменте данных? а сколько аллоков уйдет? а кешь промахов?
Почему я никогда не буду использовать STL.11 июня 201014:51#528
Я думаю идеальный по быстродействию push_back должен выглядеть так:
T& push_back()
{
  assert(num < max_size() && "Out Of Range");
  return data[num++];
}
Почему я никогда не буду использовать STL.10 июня 201019:33#486
IROV..
> пока человек не научиться правильно хранить и грузить ресурсы, обьяснять ему о
> том что std::vector жрет реально больше чем нужно, и что нужно использовать
> свои алокаторы, а лучше вообще не алоцировать память кроме как на стеке во
> время работы.
>
> тоесть нужно сначало вбить в мозг - архитектуру, а уж потом оптимизацию этого
> чуда, я думаю он же сам завтра прибежит с пару тройкой идей по поводу того
> почему всетаки STL уже не канает, и что нужно взамен.
Эх... золотые слова... а сколько кода нужно переписать где естьо что-то похожее std::map<T, std::map<T2, T3> > > есть
Почему я никогда не буду использовать STL.10 июня 201017:18#475
tav
> Чтобы все внешние библиотеки не использовали стандартный malloc.
dlmalloc ?
Почему я никогда не буду использовать STL.8 июня 201012:35#353
innuendo
>а какая именно часть цитаты приводить тебя в недоумение ? :)
"Сортированный массив с ключиком - мап по определению."
Массив есть массив. Ключ к нему не имеет отношения и вместе они не могут составлять нелинейную структуру данных словарь(map).
Почему я никогда не буду использовать STL.8 июня 201012:09#350
Sbtrn. Devil
> Сортированный массив с ключиком - мап по определению. То, что он реализован не
> через дерево, а через массив, не играет особенной роли.
ты в перлы не хочешь попасть?

Следующие темы >>

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