Сообщения на форуме пользователя Andrey (48 стр.)
glBindTexture | 28 июня 2010 | 11:14 | #20 |
---|
Larik
> glBegin ( GL_QUADS );
> glEnd();
Вынеси вынеси это за цикл и сравни FPS
> glBegin ( GL_QUADS );
> glEnd();
Вынеси вынеси это за цикл и сравни FPS
GameDev.ru 9 лет! (комментарии) | 26 июня 2010 | 19:18 | #7 |
---|
Поздравляю! А чего одни участники поздравляют? Надеюсь постояльцем тоже разрешено?
получение углов поворота с матрицы | 21 июня 2010 | 15: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)
> незнаю в правельный ли раздел запостился ?
лучше в раздел графики.
Вот попробуй. Но я не проверял правильность.
Матрица хранится у меня так
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 июня 2010 | 10:22 | #4 |
---|
scorch
Про дерево не понял. Дрова новые карта 8600 GT. А что тут непонятно? 4 танка 60 FPS 1 танк 150 FPS.
причем частицы там не сложные. Итого вывод - убивает CPU кодом Delphi либо память часто выделяет/удаляет для живых/мертвых. Я же не знаю ка оно там реализовано. Или ты думаешь той графикой, сложностью, полигонажем сцены можно убить FPS ? Тут CPU bound однозначно.
Про дерево не понял. Дрова новые карта 8600 GT. А что тут непонятно? 4 танка 60 FPS 1 танк 150 FPS.
причем частицы там не сложные. Итого вывод - убивает CPU кодом Delphi либо память часто выделяет/удаляет для живых/мертвых. Я же не знаю ка оно там реализовано. Или ты думаешь той графикой, сложностью, полигонажем сцены можно убить FPS ? Тут CPU bound однозначно.
Новая демка (комментарии) | 20 июня 2010 | 21:55 | #2 |
---|
Неплохо. поставил разрешение 1280x1024 полноэкранный. FPS - очень маловат.
6 танков в кадре. Полигонов мало, сцена не загруженная. Тормозят дико у тебя частицы и игровая логика + убогий компилятор на Delphi. Когда отъезжаешь и виден 1 танк FPS растет. И вообще зачем на Delphi то?
6 танков в кадре. Полигонов мало, сцена не загруженная. Тормозят дико у тебя частицы и игровая логика + убогий компилятор на Delphi. Когда отъезжаешь и виден 1 танк FPS растет. И вообще зачем на Delphi то?
Почему я никогда не буду использовать STL. | 18 июня 2010 | 15:34 | #829 |
---|
innuendo
> так ты за или против refCounters ? :)
я еще исследую данный вопрос.
> так ты за или против refCounters ? :)
я еще исследую данный вопрос.
Почему я никогда не буду использовать STL. | 18 июня 2010 | 14: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> >
> > есть же 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 июня 2010 | 12:26 | #820 |
---|
innuendo
> > new/delete запрещены вообще
> совсем-совсем ?
delete точно не нужен, есть же std::auto_ptr. без new можно в большинстве случаев обойтись.
> > new/delete запрещены вообще
> совсем-совсем ?
delete точно не нужен, есть же std::auto_ptr. без new можно в большинстве случаев обойтись.
Почему я никогда не буду использовать STL. | 17 июня 2010 | 16:55 | #755 |
---|
Executor
>а то что статический массив в 10-100-1000 раз больше сцены
Речь в частности идет про массив для сбора RenderQueue его то и можно(и нужно!) ограничить. Да число объектов ну уровне тоже можно ограничить при желании, но тут уже сложнее.
по остальному тебе развернутый ответ дал Xunter
Я со всем согласен.
>а то что статический массив в 10-100-1000 раз больше сцены
Речь в частности идет про массив для сбора RenderQueue его то и можно(и нужно!) ограничить. Да число объектов ну уровне тоже можно ограничить при желании, но тут уже сложнее.
по остальному тебе развернутый ответ дал Xunter
Я со всем согласен.
Почему я никогда не буду использовать STL. | 17 июня 2010 | 14:09 | #749 |
---|
Outlaw
> ты же по мухам из пушки не стреляешь, зачем эти все reserve? чтобы сделать
> push_back только?, ну так и в обычный массив добавить элемент в конец
> так же просто, одна строчка кода. я не против vector'а нет, тут он избыточен
> просто.
+1
Executor
> Пока ты, к примеру, с диска не загрузишь информацию о том, сколько объектов
> может быть, откуда тебе знать сколько их?
> Вот ты от сцены к сцене меняешь размер массива...
Ничего не меняется. Обычно в двоичном файле сцены известно число объектов. Да и сцена проектируется под определенное число объектов в кадре. Ну не нужно действительно более 5000 к примеру видимых объектов иметь.
> Можно конечно сделать статику в виде стопицот элементов, но зачем? Если на
> половине сцен даже до трети этого размера не дойдёт, память девать некуда
> чтоли?
Какая память? на 20 кб зарезервированного массива в сегменте данных? а сколько аллоков уйдет? а кешь промахов?
> ты же по мухам из пушки не стреляешь, зачем эти все reserve? чтобы сделать
> push_back только?, ну так и в обычный массив добавить элемент в конец
> так же просто, одна строчка кода. я не против vector'а нет, тут он избыточен
> просто.
+1
Executor
> Пока ты, к примеру, с диска не загрузишь информацию о том, сколько объектов
> может быть, откуда тебе знать сколько их?
> Вот ты от сцены к сцене меняешь размер массива...
Ничего не меняется. Обычно в двоичном файле сцены известно число объектов. Да и сцена проектируется под определенное число объектов в кадре. Ну не нужно действительно более 5000 к примеру видимых объектов иметь.
> Можно конечно сделать статику в виде стопицот элементов, но зачем? Если на
> половине сцен даже до трети этого размера не дойдёт, память девать некуда
> чтоли?
Какая память? на 20 кб зарезервированного массива в сегменте данных? а сколько аллоков уйдет? а кешь промахов?
Почему я никогда не буду использовать STL. | 11 июня 2010 | 14:51 | #528 |
---|
Я думаю идеальный по быстродействию push_back должен выглядеть так:
T& push_back() { assert(num < max_size() && "Out Of Range"); return data[num++]; }
Почему я никогда не буду использовать STL. | 10 июня 2010 | 19:33 | #486 |
---|
IROV..
> пока человек не научиться правильно хранить и грузить ресурсы, обьяснять ему о
> том что std::vector жрет реально больше чем нужно, и что нужно использовать
> свои алокаторы, а лучше вообще не алоцировать память кроме как на стеке во
> время работы.
>
> тоесть нужно сначало вбить в мозг - архитектуру, а уж потом оптимизацию этого
> чуда, я думаю он же сам завтра прибежит с пару тройкой идей по поводу того
> почему всетаки STL уже не канает, и что нужно взамен.
Эх... золотые слова... а сколько кода нужно переписать где естьо что-то похожее std::map<T, std::map<T2, T3> > > есть
> пока человек не научиться правильно хранить и грузить ресурсы, обьяснять ему о
> том что std::vector жрет реально больше чем нужно, и что нужно использовать
> свои алокаторы, а лучше вообще не алоцировать память кроме как на стеке во
> время работы.
>
> тоесть нужно сначало вбить в мозг - архитектуру, а уж потом оптимизацию этого
> чуда, я думаю он же сам завтра прибежит с пару тройкой идей по поводу того
> почему всетаки STL уже не канает, и что нужно взамен.
Эх... золотые слова... а сколько кода нужно переписать где естьо что-то похожее std::map<T, std::map<T2, T3> > > есть
Почему я никогда не буду использовать STL. | 10 июня 2010 | 17:18 | #475 |
---|
tav
> Чтобы все внешние библиотеки не использовали стандартный malloc.
dlmalloc ?
> Чтобы все внешние библиотеки не использовали стандартный malloc.
dlmalloc ?
Почему я никогда не буду использовать STL. | 8 июня 2010 | 12:35 | #353 |
---|
innuendo
>а какая именно часть цитаты приводить тебя в недоумение ? :)
"Сортированный массив с ключиком - мап по определению."
Массив есть массив. Ключ к нему не имеет отношения и вместе они не могут составлять нелинейную структуру данных словарь(map).
>а какая именно часть цитаты приводить тебя в недоумение ? :)
"Сортированный массив с ключиком - мап по определению."
Массив есть массив. Ключ к нему не имеет отношения и вместе они не могут составлять нелинейную структуру данных словарь(map).
Почему я никогда не буду использовать STL. | 8 июня 2010 | 12:09 | #350 |
---|
Sbtrn. Devil
> Сортированный массив с ключиком - мап по определению. То, что он реализован не
> через дерево, а через массив, не играет особенной роли.
ты в перлы не хочешь попасть?
> Сортированный массив с ключиком - мап по определению. То, что он реализован не
> через дерево, а через массив, не играет особенной роли.
ты в перлы не хочешь попасть?