Сообщения на форуме пользователя Andrey (139 стр.)
Из OpenGL в DirectX крик души! | 11 мая 2007 | 20:31 | #35 |
---|
про glBegin()/glEnd()
"..
Многие наверное слышали/использовали glBegin/glEnd. Если ваша цель - самый эффективный рендеринг, то забудьте про них!
.." tav (C)
http://www.gamedev.ru/articles/?id=20124
я думаю про эти функции надо забыть. В современных OpenGL рендерах их нет вообще.
"..
Многие наверное слышали/использовали glBegin/glEnd. Если ваша цель - самый эффективный рендеринг, то забудьте про них!
.." tav (C)
http://www.gamedev.ru/articles/?id=20124
я думаю про эти функции надо забыть. В современных OpenGL рендерах их нет вообще.
Cg vs GLSL | 11 мая 2007 | 10:50 | #1 |
---|
The Andreyp
>скачал недавно СГ 1ю4!
какой пещерный век!!! это уже устаревшая версия.
ты за обновлением смотришь? уже за февраль 2007 есть 1.5 версия.
http://developer.nvidia.com/object/cg_toolkit.html
>К тому же СГ тормозен!
ну смотря как делать. Cg вызывает API OpenGL/Direct3D для создания шейдеров является оберткой вокруг него. Хотя иногда он может сформировать не очень оптимальный код.
>1) в какой асм профиль компилятся проги ГЛСЛ (arb_program ?)
я что-то не понял разве Cg понимает GLSL ? вот скомпилить Cg код в GLSL можно с помощью профиля glslv/glslf.
>2) держат ли глсл 3-4 ГФ (видимо зависит от версии гл 2 в дровах ?)тоесть держат - только это драйвен драйверами-райт ?
если я не ошибаюсь GLSL поддерживается начиная от OpenGL 1.5, вроде даже GeForce2 MX400 держит.
>скачал недавно СГ 1ю4!
какой пещерный век!!! это уже устаревшая версия.
ты за обновлением смотришь? уже за февраль 2007 есть 1.5 версия.
http://developer.nvidia.com/object/cg_toolkit.html
>К тому же СГ тормозен!
ну смотря как делать. Cg вызывает API OpenGL/Direct3D для создания шейдеров является оберткой вокруг него. Хотя иногда он может сформировать не очень оптимальный код.
>1) в какой асм профиль компилятся проги ГЛСЛ (arb_program ?)
я что-то не понял разве Cg понимает GLSL ? вот скомпилить Cg код в GLSL можно с помощью профиля glslv/glslf.
>2) держат ли глсл 3-4 ГФ (видимо зависит от версии гл 2 в дровах ?)тоесть держат - только это драйвен драйверами-райт ?
если я не ошибаюсь GLSL поддерживается начиная от OpenGL 1.5, вроде даже GeForce2 MX400 держит.
Как правильно преобразовать LPSTR в LPWSTR? | 8 мая 2007 | 20:04 | #1 |
---|
_free
mbstowcs/MultiByteToWideChar
mbstowcs/MultiByteToWideChar
статические переменные - зло? | 8 мая 2007 | 19:40 | #15 |
---|
>И вообще, советую почитать вот эту дискуссию http://users.livejournal.com/_winnie/18677.html
>С тех пор я немного изменил своё мнение и всё больше понимаю, что Руслан был всё же прав. Синглетоны - отстой.
eHomo
>И теперь все должны потянуться за чужим мнением?
ну знаешь к мнению товарища aruslan'а я думаю можно прислушаться
>С тех пор я немного изменил своё мнение и всё больше понимаю, что Руслан был всё же прав. Синглетоны - отстой.
eHomo
>И теперь все должны потянуться за чужим мнением?
ну знаешь к мнению товарища aruslan'а я думаю можно прислушаться
Мат.библиотека для 3D движка (нужны советы) | 8 мая 2007 | 18:22 | #10 |
---|
KpeHDeJIb
ну в некоторых местах можно поставить assert к примеру:
По культуре программирования, неплохо бы пользовать const указателями там где значения по ним не меняются, в этом случае лучше так:
Я так думаю нужно принудительно все вызовы мат либы делать inline, а лучше __forceinline/always_inline
тут конечно можно возразить.
ну в некоторых местах можно поставить assert к примеру:
mat4(float *v) { assert(v && "NULL Pointer"); c[ 0] = v[ 0]; c[ 1] = v[ 1]; c[ 2] = v[ 2]; c[ 3] = v[ 3]; c[ 4] = v[ 4]; c[ 5] = v[ 5]; c[ 6] = v[ 6]; c[ 7] = v[ 7]; c[ 8] = v[ 8]; c[ 9] = v[ 9]; c[10] = v[10]; c[11] = v[11]; c[12] = v[12]; c[13] = v[13]; c[14] = v[14]; c[15] = v[15]; }
mat4(const float *v) ...
тут конечно можно возразить.
ilut.dll + directX | 2 мая 2007 | 10:41 | #4 |
---|
Sloth
>Это значит, что при попытке слинковаться с с этой библиотекой c использованием каких либо функций работы с DirectX9 выходят >ошибки типа:
>"... error LNK2019: unresolved external symbol __imp__ilutD3D9TexFromFile@12 referenced in function ..."
?
>Это значит, что при попытке слинковаться с с этой библиотекой c использованием каких либо функций работы с DirectX9 выходят >ошибки типа:
>"... error LNK2019: unresolved external symbol __imp__ilutD3D9TexFromFile@12 referenced in function ..."
pragma comment(lib, "ilut.lib");
Сортировка сцены по текстурам и шейдерам | 28 апр. 2007 | 19:48 | #1 |
---|
Ravager
>Можно ли это сделать за один проход используя qsort?
можно но лучше std::sort функция сортировки можно сделать inline/__forceinline для большого числа объектов может дать прирост.
>Можно ли это сделать за один проход используя qsort?
можно но лучше std::sort функция сортировки можно сделать inline/__forceinline для большого числа объектов может дать прирост.
ARB_texture_compression | 27 апр. 2007 | 19:14 | #1 |
---|
Разумно ли кешировать матрицу Model->World? | 27 апр. 2007 | 14:16 | #3 |
---|
chiaroscuro
>Не задумывайся о таких мелочах.
>Думаешь, те, кто пишут реализации OpenGL, свой хлеб даром едят? :
угу они же и писали что делайте 1 раз glLoadMatrixf финальной матрицы вместо вызовов glTranslatef/glRotatef/glScalef.
интеренос такая же ситуация с Direct3D, SetTransform луше вызывать для финальной матрицы.
>Не задумывайся о таких мелочах.
>Думаешь, те, кто пишут реализации OpenGL, свой хлеб даром едят? :
угу они же и писали что делайте 1 раз glLoadMatrixf финальной матрицы вместо вызовов glTranslatef/glRotatef/glScalef.
интеренос такая же ситуация с Direct3D, SetTransform луше вызывать для финальной матрицы.
frustum culling - не влияет на фпс? | 27 апр. 2007 | 11:42 | #20 |
---|
Noorma_yeah!
>Если кому интересно:
>фпс со 127 номинальных до 25 фактических снижала всего лишь одна строчка в коллижн алгоритме:
>Если кому интересно:
>фпс со 127 номинальных до 25 фактических снижала всего лишь одна строчка в коллижн алгоритме:
>cMesh->m_pMesh->m_pVB->Lock( 0,0,(void**)&pVertices, 0 );
>Эта строчка вызывалась каждый кадр и в силу рекурсивности алгоритма вызывалась не по одному разу.
>Если вы видите что то подобное у себя в коде знайте - оно вам портит фпс )))
>Решение простое - залочить этот буффер (так как он не используется больше ни для чего) на старте
>программы - и разлочить (обязательно) на финише.
есть пути решения:
1) хранить полигоны в RAM - но тут конечно памяти много надо.
2) делать Collision Mesh который будет притмерно повторять форму объекта но там будет в разы меньше полигонов и их можно вполне хранить в RAM
Размер батча | 26 апр. 2007 | 19:06 | #1 |
---|
Executor
Ну для Direct3D есть D3DCAPS9::MaxPrimitiveCount
для OpenGL я так понял нет ограничения на размер.
я выводил на OpenGL за 1 вызов ландшафт 512x512 на довольно старой карте Radeon 9200 SE
для Direct3D этот номер не прошел, макcимум для это карты за 1 вызов вроде 128x128.
Ну для Direct3D есть D3DCAPS9::MaxPrimitiveCount
для OpenGL я так понял нет ограничения на размер.
я выводил на OpenGL за 1 вызов ландшафт 512x512 на довольно старой карте Radeon 9200 SE
для Direct3D этот номер не прошел, макcимум для это карты за 1 вызов вроде 128x128.
Статья: "Краткий обзор архитектуры и возможностей нескольких игровых движков." | 25 апр. 2007 | 19:40 | #12 |
---|
IROV..
+1
полностью поддерживаю... самое главное что-бы на стратегиях где сотни игровых объектов не падала производительность,
если речь зашла про скрипты.
Есть подобные игровые движки подходящие для любого жанра и не залазив в C/C++ код можно обойтись редактором и написанием скриптов?
+1
полностью поддерживаю... самое главное что-бы на стратегиях где сотни игровых объектов не падала производительность,
если речь зашла про скрипты.
Есть подобные игровые движки подходящие для любого жанра и не залазив в C/C++ код можно обойтись редактором и написанием скриптов?
Мировые координаты по экранным | 25 апр. 2007 | 11:06 | #1 |
---|
ztranger
D3DXVec3Unproject
Projects a vector from screen space into object space.
D3DXVec3Unproject
Projects a vector from screen space into object space.
Менеджер шейдеров - что и как | 19 апр. 2007 | 19:28 | #2 |
---|
AllSeeingI
Ну у меня сделано так. Менеджер шейдеров может грузить шейдер вместе с его параметрами т.е. простой формат описания
шейдера:
имя шейдера;
тип шейдера(вершинный пиксельный);
точка входа в шейдер;
файл с шейдером.
Далее менеджер шейдеров может грузить параметры шейдера с проверкой этих параметров.
Выполнять прекомпиляцию шейдеров т.е. готовый asm код + параметры шейдера. Т.е. при запросе он может найти уже ранее загруженный.
Далее у меня 3 менеджера шейдеров для HLSL/Cg/GLSL
первые 2 написаны с третьим еще только начало. возможно будет для GL_ARB_fragment_program/GL_ARB_vertex_program.
Сам класс Shader (у меня SahderProgram) служит только для хранения самой программы для конкретного API. С Direct3D точно так с OpenGL еще не решил...
установку параметров делает тоже рендер.
>3) Каким образом реализовать (1) и (2) так, чтобы установка шейдерных переменных/привязка >шейдеров/bla-blah-blah-что-там-ещё-от-шейдеров-надо осуществлялась наиболее простым и естественным способом?
вот тут можно сделать просто например в OGRE, Nebula, Render Monkey(кстати в OGRE основано на RenderMonkey), есть предопределяемые перменные.
Идея взята у меня оттуда реализация была написана своя. Все достаточно гибко и просто.
Передавать параметры можно как по имени, так и по номеру регистра. В любо случае менеджер шейдеров определяет через какой регистр это нужно передать.
к пример
ParamName WordMatrix wordMat 1 1 2 3 4 4 5 5 5 6 6 8
вот так у меня будет понятно что идет именованный параметр с типом Матрица мира. В это случае менеджер шейдеров
находит регистр по переменной wordMat и записывает в некую структуру ShaderParameters что через такой-то регистр нужно передавать Матрицу мира. Я сделал через регистры т.к. будет быстрей.
В случае регистра пользователь должен знать через какой именно регистр что передается. Тут ситуация сложней.
Предопределяемых параметров можно ввести очень много, они стандартны и часто встречающиеся.
Специфические параметры пользователь будет менять сам, напрямую используя доступ к хранению констант шейдера.
кстати G-man пошел намного глубже, я остановился пока на этом.
Ну я доволен качающееся дерево у меня совсем не зпавивист от кода C++ все параметры прописаны и загружены через менджер шейдеров
Ну у меня сделано так. Менеджер шейдеров может грузить шейдер вместе с его параметрами т.е. простой формат описания
шейдера:
имя шейдера;
тип шейдера(вершинный пиксельный);
точка входа в шейдер;
файл с шейдером.
Далее менеджер шейдеров может грузить параметры шейдера с проверкой этих параметров.
Выполнять прекомпиляцию шейдеров т.е. готовый asm код + параметры шейдера. Т.е. при запросе он может найти уже ранее загруженный.
Далее у меня 3 менеджера шейдеров для HLSL/Cg/GLSL
первые 2 написаны с третьим еще только начало. возможно будет для GL_ARB_fragment_program/GL_ARB_vertex_program.
Сам класс Shader (у меня SahderProgram) служит только для хранения самой программы для конкретного API. С Direct3D точно так с OpenGL еще не решил...
установку параметров делает тоже рендер.
>3) Каким образом реализовать (1) и (2) так, чтобы установка шейдерных переменных/привязка >шейдеров/bla-blah-blah-что-там-ещё-от-шейдеров-надо осуществлялась наиболее простым и естественным способом?
вот тут можно сделать просто например в OGRE, Nebula, Render Monkey(кстати в OGRE основано на RenderMonkey), есть предопределяемые перменные.
Идея взята у меня оттуда реализация была написана своя. Все достаточно гибко и просто.
Передавать параметры можно как по имени, так и по номеру регистра. В любо случае менеджер шейдеров определяет через какой регистр это нужно передать.
к пример
ParamName WordMatrix wordMat 1 1 2 3 4 4 5 5 5 6 6 8
вот так у меня будет понятно что идет именованный параметр с типом Матрица мира. В это случае менеджер шейдеров
находит регистр по переменной wordMat и записывает в некую структуру ShaderParameters что через такой-то регистр нужно передавать Матрицу мира. Я сделал через регистры т.к. будет быстрей.
В случае регистра пользователь должен знать через какой именно регистр что передается. Тут ситуация сложней.
Предопределяемых параметров можно ввести очень много, они стандартны и часто встречающиеся.
Специфические параметры пользователь будет менять сам, напрямую используя доступ к хранению констант шейдера.
кстати G-man пошел намного глубже, я остановился пока на этом.
Ну я доволен качающееся дерево у меня совсем не зпавивист от кода C++ все параметры прописаны и загружены через менджер шейдеров
Движок Almighty | 18 апр. 2007 | 19:43 | #7 |
---|
Zack
>Это ты к чему?
>Или "абы ляпнуть"?
Я просто знаю опыт Flay'я, но не знаю твой, возможно ты написал лучше, так что без обид если что, а кричать что кто-то написал движок
как-бы там ни было (передрав чужой код или написав свой и т.д.) могут все кому не лень.
>Это ты к чему?
>Или "абы ляпнуть"?
Я просто знаю опыт Flay'я, но не знаю твой, возможно ты написал лучше, так что без обид если что, а кричать что кто-то написал движок
как-бы там ни было (передрав чужой код или написав свой и т.д.) могут все кому не лень.