Сообщения на форуме пользователя Andrey (16 стр.)
Убогость OpenGL API | 4 июля 2012 | 19:07 | #302 |
---|
innuendo
>Никто не заставляет делать заливку за 1 кадр.
Не было времени и не за эти деньги усложнять так реализацию и пробовать разбивать заливку. Идея хорошая но сложно реализуемая за недолгое время. Объем работы был большой и не только 3D.
> Кстати, как это работало на разных карточках ? Сомнительно, что везде одинаково - тут многое от драйвера зависит, а не от апи.
Ну работало номано на Intel GMA и на многих nVidia картах, себе специально оставил убогую 6600 GT и выжимал на ней. ATI карт было мало, на ATI 2400 тоже работало.
>Никто не заставляет делать заливку за 1 кадр.
Не было времени и не за эти деньги усложнять так реализацию и пробовать разбивать заливку. Идея хорошая но сложно реализуемая за недолгое время. Объем работы был большой и не только 3D.
> Кстати, как это работало на разных карточках ? Сомнительно, что везде одинаково - тут многое от драйвера зависит, а не от апи.
Ну работало номано на Intel GMA и на многих nVidia картах, себе специально оставил убогую 6600 GT и выжимал на ней. ATI карт было мало, на ATI 2400 тоже работало.
Убогость OpenGL API | 4 июля 2012 | 18:52 | #299 |
---|
kas
> смарите как получается. на д3д было все оке, а в огл глюки, не работает.
> http://itunes.apple.com/us/app/kings-bounty-legend-multi6/id503838512?mt=12 а
> может просто криворукие портировали, как думаете?
А подробнее про глюки можно?
> смарите как получается. на д3д было все оке, а в огл глюки, не работает.
> http://itunes.apple.com/us/app/kings-bounty-legend-multi6/id503838512?mt=12 а
> может просто криворукие портировали, как думаете?
А подробнее про глюки можно?
Убогость OpenGL API | 4 июля 2012 | 18:51 | #298 |
---|
innuendo
> Это в худшем варианте по 1ГБ видеопамяти получается ? :)
Точно не помню но размеры дикие. Некоторые модели не грузились, грузились мелкие, после суток полетов лог был весь в E_OUTOFMEMORY. Иногда через пару часов падало, вычистил все потом.
>А как же там PBO и всё такое ? а там оно ничего возможно не дало бы особо. И там Direct3D9(у заказчика дохлые ноуты с Intel GMA и XP) грузить ради текстур без Lock/Unlock нету смысла.
>Вот если заказчик ставит условие - только чтобы под *nix было... И всё, приплыли, суши вёсла - нема тут супер продуманого апи с dxdebug и perhud :)
Ну в общем ты со мной согласен, такое можно не писать уже, а то начинается приплыли и т.д.
Был бы *nix писал бы на OpenGL и без dxdebug и perhud.
SNVampyre
>Естественно, никто никого не ждёт. Данные есть - заливаются сразу.
>Скорость загрузки текстур вообще колоссальная получилась, было что-то около 2000 загрузок 2048x2048 DXT3 в секунду. Возможно они лежали уже в кеше жёсткого диска, но тем не >менее. То есть если тут и будут какие-то замедления, то только в постороннем потоке (не в рендере), который работает с диском.
Ну значит грузи текстуры для сцены с кубиком в потоке рендера какие проблемы?
> Вообще, ты примерно хоть представляешь как работает синхронизация двух
> контекстов в драйвере?
Представляю конечно, только к чему ты этот вопрос задал?
>В случае с двумя контекстами ты заставляешь драйвер следить за готовностью данных, синхронизируя контексты и проверяя состояния. В случае если ресурс ещё не готов, он будет >вынужден подсунуть какой-нибудь бракованный буфер.
Ну базовую теорию мне не рассказывай, это я все знаю.
>Откуда такая вера, что загрузка данных в другом потоке будет быстрее, чем загрузка готового указателя в PBO и дальнейшее пользование его как источника для текстуры в потоке >рендера?
Вера из опыта. Я вижу ты постов не читаешь вообще. Тебе пример реального проекта мало? Еще раз, при больших объемах данных рендер будет делать загрузку останавливая рендеринг,
тебе же твой некий список рендер команд нужно обработать. Ну никак он не может это сделать не останавливая кусок кода.
>Кстати, а что если ты буфер индексов заполнишь в параллельном потоке, пока этот буфер используется дли рисования в основном потоке? Не пробовал так стрелять себе в ногу?
Конечно пробовал такие классные вылеты были...Конечно были и таки ошибки по началу.
Я пока не загружу ресурсы для объекта он не попадет в список отрисовки, а туда он попадет с готовыми загруженными буферами и текстурами. Под объектом я понимаю некую структуру назовем ее модель, там VB/IB + набор батчей с материалами(текстура + Raster OPS и другие вспомогательные данные). Т.е. графические ресурсы использовались в составе объекта. За загрузкой следил менеджер сцены. Он не давал рендеру ресурсы залоченные и заполняемые в другом потоке.(т.е. не готовые для использования рендером)
> Это в худшем варианте по 1ГБ видеопамяти получается ? :)
Точно не помню но размеры дикие. Некоторые модели не грузились, грузились мелкие, после суток полетов лог был весь в E_OUTOFMEMORY. Иногда через пару часов падало, вычистил все потом.
>А как же там PBO и всё такое ? а там оно ничего возможно не дало бы особо. И там Direct3D9(у заказчика дохлые ноуты с Intel GMA и XP) грузить ради текстур без Lock/Unlock нету смысла.
>Вот если заказчик ставит условие - только чтобы под *nix было... И всё, приплыли, суши вёсла - нема тут супер продуманого апи с dxdebug и perhud :)
Ну в общем ты со мной согласен, такое можно не писать уже, а то начинается приплыли и т.д.
Был бы *nix писал бы на OpenGL и без dxdebug и perhud.
SNVampyre
>Естественно, никто никого не ждёт. Данные есть - заливаются сразу.
>Скорость загрузки текстур вообще колоссальная получилась, было что-то около 2000 загрузок 2048x2048 DXT3 в секунду. Возможно они лежали уже в кеше жёсткого диска, но тем не >менее. То есть если тут и будут какие-то замедления, то только в постороннем потоке (не в рендере), который работает с диском.
Ну значит грузи текстуры для сцены с кубиком в потоке рендера какие проблемы?
> Вообще, ты примерно хоть представляешь как работает синхронизация двух
> контекстов в драйвере?
Представляю конечно, только к чему ты этот вопрос задал?
>В случае с двумя контекстами ты заставляешь драйвер следить за готовностью данных, синхронизируя контексты и проверяя состояния. В случае если ресурс ещё не готов, он будет >вынужден подсунуть какой-нибудь бракованный буфер.
Ну базовую теорию мне не рассказывай, это я все знаю.
>Откуда такая вера, что загрузка данных в другом потоке будет быстрее, чем загрузка готового указателя в PBO и дальнейшее пользование его как источника для текстуры в потоке >рендера?
Вера из опыта. Я вижу ты постов не читаешь вообще. Тебе пример реального проекта мало? Еще раз, при больших объемах данных рендер будет делать загрузку останавливая рендеринг,
тебе же твой некий список рендер команд нужно обработать. Ну никак он не может это сделать не останавливая кусок кода.
>Кстати, а что если ты буфер индексов заполнишь в параллельном потоке, пока этот буфер используется дли рисования в основном потоке? Не пробовал так стрелять себе в ногу?
Конечно пробовал такие классные вылеты были...Конечно были и таки ошибки по началу.
Я пока не загружу ресурсы для объекта он не попадет в список отрисовки, а туда он попадет с готовыми загруженными буферами и текстурами. Под объектом я понимаю некую структуру назовем ее модель, там VB/IB + набор батчей с материалами(текстура + Raster OPS и другие вспомогательные данные). Т.е. графические ресурсы использовались в составе объекта. За загрузкой следил менеджер сцены. Он не давал рендеру ресурсы залоченные и заполняемые в другом потоке.(т.е. не готовые для использования рендером)
Убогость OpenGL API | 4 июля 2012 | 16:52 | #291 |
---|
SNVampyre
> А там разве можно было из любого потока списки команд делать?
Нет там не то я имел ввиду. Ты из потока рендера создал текстуру или буфер, лочишь и отдаешь указатель (можно некую очередь загрузки ресурсов создать) заливки данных в другой(в других) поток(ах ).В потоке рендера асинхронно проверяешь готовность ресурсов разлачиваешь и используешь, т.е. в таком случаем так называемые команды отрисовки будут проще в разы чем у тебя. Ну это все бы ничего просто проще реализация огромный минус в том что поток рендера стоит и ждет пока ты все не сделаешь. В случае Direct3D9 или расширивания контекста OpenGL ты не ждешь, просто асинхронно обновляешь список подгружаемых ресурсов по мере готовности.
innuendo
>Во-первых, идея заливать текстурки в другом потоке не очень хороша. Бывали даже случая уменьшения fps.
Бывали такие случаи. Но вот реальный случай. Был проект, летишь по сцене, у тебя десятки моделей в кадре, причем густо расставленных на большой карте, речь про десятки километров. Размер файлов моделей по 50-100 метров(не нужно спрашивать почему такие размеры по другому никак, не моя вина).
Был бы подход как описал ты, то камера застопорилась пока мы будем лить текстуры и буферы в потоке рендера(проверено). Сделал как описал выше. Работает без лагов, плавная подгрузка, плавное движение камеры. Не успел я конечно сделать это асинхронно было бы вообще шикарно. Размеры данных и геометрическая сложность сцена просто запредельная. Размер контента был десятки гигабайт.
> А там разве можно было из любого потока списки команд делать?
Нет там не то я имел ввиду. Ты из потока рендера создал текстуру или буфер, лочишь и отдаешь указатель (можно некую очередь загрузки ресурсов создать) заливки данных в другой(в других) поток(ах ).В потоке рендера асинхронно проверяешь готовность ресурсов разлачиваешь и используешь, т.е. в таком случаем так называемые команды отрисовки будут проще в разы чем у тебя. Ну это все бы ничего просто проще реализация огромный минус в том что поток рендера стоит и ждет пока ты все не сделаешь. В случае Direct3D9 или расширивания контекста OpenGL ты не ждешь, просто асинхронно обновляешь список подгружаемых ресурсов по мере готовности.
innuendo
>Во-первых, идея заливать текстурки в другом потоке не очень хороша. Бывали даже случая уменьшения fps.
Бывали такие случаи. Но вот реальный случай. Был проект, летишь по сцене, у тебя десятки моделей в кадре, причем густо расставленных на большой карте, речь про десятки километров. Размер файлов моделей по 50-100 метров(не нужно спрашивать почему такие размеры по другому никак, не моя вина).
Был бы подход как описал ты, то камера застопорилась пока мы будем лить текстуры и буферы в потоке рендера(проверено). Сделал как описал выше. Работает без лагов, плавная подгрузка, плавное движение камеры. Не успел я конечно сделать это асинхронно было бы вообще шикарно. Размеры данных и геометрическая сложность сцена просто запредельная. Размер контента был десятки гигабайт.
Убогость OpenGL API | 4 июля 2012 | 16:28 | #288 |
---|
SNVampyre
>В новом движке у меня как раз на это упор.
>Можешь почитать тут про рендер: http://www.gamedev.ru/pages/snvampyre/articles/sh2_render_commands
Почитал идея понятна она правильная и больше то вариантов нету.
Это не возможности OpenGL, это твои реализации, не позволяющие эффективно использовать загрузку данных в разных потоках, твоя реализация сливает по простоте кода против даже Direct3D9. Не будем тут это обсуждать.
>Ну начнём с того, что в OpenGL это всё можно было делать, и уже давно.
>Любые ресурсы можно грузить из любого потока, и из любого потока можно давать команды на отрисовку. А рендер крутится в своём потоке и только выполняет команды.
Итого, в OpenGL без расшаривания контекстов получаем дикую синхронизацию ожидания загрузки данных с кучей тормознутого C++ кода, с STL, кэшь промахами, аллокациями памяти копированию всяких промежуточных вспомогательных абстрактных данных и т.д. Ну разве что для кубика пойдет там объектов в кадре мало, данных для стриминга мало, для проектов Rage нет.
>В новом движке у меня как раз на это упор.
>Можешь почитать тут про рендер: http://www.gamedev.ru/pages/snvampyre/articles/sh2_render_commands
Почитал идея понятна она правильная и больше то вариантов нету.
Это не возможности OpenGL, это твои реализации, не позволяющие эффективно использовать загрузку данных в разных потоках, твоя реализация сливает по простоте кода против даже Direct3D9. Не будем тут это обсуждать.
>Ну начнём с того, что в OpenGL это всё можно было делать, и уже давно.
>Любые ресурсы можно грузить из любого потока, и из любого потока можно давать команды на отрисовку. А рендер крутится в своём потоке и только выполняет команды.
Итого, в OpenGL без расшаривания контекстов получаем дикую синхронизацию ожидания загрузки данных с кучей тормознутого C++ кода, с STL, кэшь промахами, аллокациями памяти копированию всяких промежуточных вспомогательных абстрактных данных и т.д. Ну разве что для кубика пойдет там объектов в кадре мало, данных для стриминга мало, для проектов Rage нет.
Убогость OpenGL API | 4 июля 2012 | 14:21 | #274 |
---|
innuendo
> > Не забыл, она 1 против десятка штук в OpenGL, у которых еще 5 параметров в
> > среднем + вычисления я смещений, так что затраты на виртуальность ничтожны.
> > Не
>
> каждый вызов - а не только SetVertexDeclaration
Не понял. Еще раз
для установки буфера для openGL десятки вызовов с 5 параметрами в среднем против 2 SetVertexDeclaration + SetStreamSource но часто достаточно SetStreamSource, если формат неизменен на протяжении нескольких групп объектов. вот и сравним пару виртуальных с пару параметров и десяток с 5 параметрами. Разница существенна.
>PBO где ? а закачка буфера без Lock\Unlock ?
ID3D10DEvice::UpdateSubresource, ID3D11DeviceContext::UpdateSubresource
IDirect3DDevice9::UpdateSurface хотя последнее конечно не так может удобно.
SNVampyre
> Нельзя делать аллокацию данных, которые используются в другом потоке. Может
> быть драйвер разруливает это и подсовывает всякие белые текстуры и нулевые
> буферы, но это подход убогий.
А зачем в другом? в потоке рендера сделал и дал в очередь в другой поток. Самое интересно ты же наверное не делал не разу стриминга данный и динамическую загрузку. То что есть новые расширения улучшающие работу с этим почему-то не отменяют расшаривание контекстов, вспомним Rage, а это приводит уже к усложнению реализации
> > Не забыл, она 1 против десятка штук в OpenGL, у которых еще 5 параметров в
> > среднем + вычисления я смещений, так что затраты на виртуальность ничтожны.
> > Не
>
> каждый вызов - а не только SetVertexDeclaration
Не понял. Еще раз
для установки буфера для openGL десятки вызовов с 5 параметрами в среднем против 2 SetVertexDeclaration + SetStreamSource но часто достаточно SetStreamSource, если формат неизменен на протяжении нескольких групп объектов. вот и сравним пару виртуальных с пару параметров и десяток с 5 параметрами. Разница существенна.
>PBO где ? а закачка буфера без Lock\Unlock ?
ID3D10DEvice::UpdateSubresource, ID3D11DeviceContext::UpdateSubresource
IDirect3DDevice9::UpdateSurface хотя последнее конечно не так может удобно.
SNVampyre
> Нельзя делать аллокацию данных, которые используются в другом потоке. Может
> быть драйвер разруливает это и подсовывает всякие белые текстуры и нулевые
> буферы, но это подход убогий.
А зачем в другом? в потоке рендера сделал и дал в очередь в другой поток. Самое интересно ты же наверное не делал не разу стриминга данный и динамическую загрузку. То что есть новые расширения улучшающие работу с этим почему-то не отменяют расшаривание контекстов, вспомним Rage, а это приводит уже к усложнению реализации
Убогость OpenGL API | 4 июля 2012 | 13:49 | #266 |
---|
innuendo
> кто такой графический объект ? кто заставляет тебя шарить контексты ?
К примеру Буферы, текстуры. Если не шарить, то нужно лить в потоке рендера, пока не зальешь будет простой. В Direct3D можно делать очередь и лить в разных потоках, залочил - пусть льет в другом потоке, асинхронность лучше. Как видно разница существенна, как по построению кода так и по быстродействию.
>ты не забыл что каждый вызов D3D это виртуальная функция ? :) хотя конечно SetVertexDeclation по проще будет да, кстати,
Не забыл, она 1 против десятка штук в OpenGL, у которых еще 5 параметров в среднем + вычисления я смещений, так что затраты на виртуальность ничтожны. Не забываем что в COM вызов виртуальной функции может быть не совсем такой как в не COM классах C++. т.е. Direct3D Runtime может иметь такую реализацию
http://www.rsdn.ru/article/com/qihook.xml
>а FVF думаешь идёт напрямую в GPU ?
Не использую FVF, это уже старье.
Кстати поддерживаю State Blocks. Причем даже в старом Direct3D9 это не D3DX.
> кто такой графический объект ? кто заставляет тебя шарить контексты ?
К примеру Буферы, текстуры. Если не шарить, то нужно лить в потоке рендера, пока не зальешь будет простой. В Direct3D можно делать очередь и лить в разных потоках, залочил - пусть льет в другом потоке, асинхронность лучше. Как видно разница существенна, как по построению кода так и по быстродействию.
>ты не забыл что каждый вызов D3D это виртуальная функция ? :) хотя конечно SetVertexDeclation по проще будет да, кстати,
Не забыл, она 1 против десятка штук в OpenGL, у которых еще 5 параметров в среднем + вычисления я смещений, так что затраты на виртуальность ничтожны. Не забываем что в COM вызов виртуальной функции может быть не совсем такой как в не COM классах C++. т.е. Direct3D Runtime может иметь такую реализацию
http://www.rsdn.ru/article/com/qihook.xml
>а FVF думаешь идёт напрямую в GPU ?
Не использую FVF, это уже старье.
Кстати поддерживаю State Blocks. Причем даже в старом Direct3D9 это не D3DX.
Убогость OpenGL API | 4 июля 2012 | 13:16 | #255 |
---|
innuendo
> Ты можешь сказать - что именно лучше сделано ?
1) для загрузки данных текстуры/буферов ее нужно ставить текущей, бред какой-то. В Direct3D это разделено. Залочил, залил данные. D OpenGL начинается всякие понятия текущего графического объекта. Нужно шарить контексты и т.д. Возможно Rage баговал из-за этого. В Direct3D можно залить данные в другом потоке c создавать Device для работы в 1 потоке.
Просто удобно и прозрачно.
> Ты можешь сказать - что именно лучше сделано ?
1) для загрузки данных текстуры/буферов ее нужно ставить текущей, бред какой-то. В Direct3D это разделено. Залочил, залил данные. D OpenGL начинается всякие понятия текущего графического объекта. Нужно шарить контексты и т.д. Возможно Rage баговал из-за этого. В Direct3D можно залить данные в другом потоке c создавать Device для работы в 1 потоке.
Просто удобно и прозрачно.
2) Про шейдеры уже говорил оставим эту тему, не буду писать про это и не буду обсуждать.
3) Установка буфера в OpenGL это несколько вызовов функций glVertexAttrribPointer, gl*Pointer + glEnable*Pointer,glEnableClientState/glDisableClientState, Нужно городить кучу смещений с указателями и т.д. Все это усложнение кода, Оверхед на вызовах CPU/GPU. Да, сделали VAO но это поздно очень.
4) Почему Direct3D позволял еще в лохматые времена рисовать со смещением в вершинном буфере ? я про IDirect3DDevice9::DrawIndexedPrimitive второй параметр BaseVertexIndex, а расширение GL_ARB_draw_base_vertex_index появилось позже, не надо говорить что это все фигня, к примеру в Rage это используется.
Убогость OpenGL API | 4 июля 2012 | 12:49 | #247 |
---|
innuendo
> В третий раз спрашиваю - ты сказал о АПИ, АПИ, АПИ !!!!
Короче про API для меня все более менее терпимо стало. Не знаю может все ошибки поправил или набрался опыта. Про API тут теперь господа многое скажут в этой теме и ближайших.
В любом случае в Direct3D со всеми плюсами и минусами API сделано лучше чем в OpenGL. Подробно спорить об этом можно бесконечно бесполезно.
> В третий раз спрашиваю - ты сказал о АПИ, АПИ, АПИ !!!!
Короче про API для меня все более менее терпимо стало. Не знаю может все ошибки поправил или набрался опыта. Про API тут теперь господа многое скажут в этой теме и ближайших.
В любом случае в Direct3D со всеми плюсами и минусами API сделано лучше чем в OpenGL. Подробно спорить об этом можно бесконечно бесполезно.
Убогость OpenGL API | 4 июля 2012 | 12:40 | #244 |
---|
innuendo
> > Microsoft никак не хуже подошла к разработке графического API в сравнении с
> > кучей народа
> > ARB и Khronos. И в результате у них получилось в разы лучше.
>
> Что именно в API у них в разы лучше получилось ? Ни в runtime поддержке, ни в
> отладочных тулзах
Ну тот-же DX Debug, NV PerfHUD, NVIDIA Nsight проще/стабильнее в использовании чем gDEBugger, glIntercept и т.д.
innuendo
> > Не спроста убогий GLSL nVidia компилит Cg компилятором находящимся в дровах в
> > код для расширений
> > GL_NV_fragment_program4/GL_NV_vertex_program4/GL_NV_gpu_program5.
>
> а в glsl профиль он не компилит ? :)
Нет в дровах по ходу дела нет. Я так думаю этот asm код полученный из GLSL через Cg дается далее другому коду в драйвере.
> > Microsoft никак не хуже подошла к разработке графического API в сравнении с
> > кучей народа
> > ARB и Khronos. И в результате у них получилось в разы лучше.
>
> Что именно в API у них в разы лучше получилось ? Ни в runtime поддержке, ни в
> отладочных тулзах
Ну тот-же DX Debug, NV PerfHUD, NVIDIA Nsight проще/стабильнее в использовании чем gDEBugger, glIntercept и т.д.
innuendo
> > Не спроста убогий GLSL nVidia компилит Cg компилятором находящимся в дровах в
> > код для расширений
> > GL_NV_fragment_program4/GL_NV_vertex_program4/GL_NV_gpu_program5.
>
> а в glsl профиль он не компилит ? :)
Нет в дровах по ходу дела нет. Я так думаю этот asm код полученный из GLSL через Cg дается далее другому коду в драйвере.
DOOM 3 for android port | 4 июля 2012 | 11:21 | #27 |
---|
alex_alex_men
> на гл 2 мало функций. на архитектуре ARM другие регистры ...
Причем тут ARM ????? И причем тут гл 2 не привязанный к регистрам??? Я про ASM для шейдеров говорю! это на PC работает. Там на(PC) и тренируйся далее переводи/портируй ASM->GLSL тоже на PC, надеюсь ты не тролишь? еще раз посты 18,20,23 почитай. и разберись наконец про ARM Assembler, x86 assembler, ARB assembler(шейдрный) раз сам запутался.
> на гл 2 мало функций. на архитектуре ARM другие регистры ...
Причем тут ARM ????? И причем тут гл 2 не привязанный к регистрам??? Я про ASM для шейдеров говорю! это на PC работает. Там на(PC) и тренируйся далее переводи/портируй ASM->GLSL тоже на PC, надеюсь ты не тролишь? еще раз посты 18,20,23 почитай. и разберись наконец про ARM Assembler, x86 assembler, ARB assembler(шейдрный) раз сам запутался.
DOOM 3 for android port | 4 июля 2012 | 11:00 | #23 |
---|
alex_alex_men
> asm говорю сразу отпадает . вы что?
На PC попробуй это написать для тренировки в отдельных проектах. Потом на GLSL - там-же! после это портирование шейдеров ARB ASM -> GLSL тоже на PC, как заработает перенесешь на Android.
> гл 1.4 и гл 2 . только это не думаю что возможно. GLESv1_CM','GLESv2 или даже
> еще одну EGL
Сделай на одной. Лучше сразу на GLESv2.
> asm говорю сразу отпадает . вы что?
На PC попробуй это написать для тренировки в отдельных проектах. Потом на GLSL - там-же! после это портирование шейдеров ARB ASM -> GLSL тоже на PC, как заработает перенесешь на Android.
> гл 1.4 и гл 2 . только это не думаю что возможно. GLESv1_CM','GLESv2 или даже
> еще одну EGL
Сделай на одной. Лучше сразу на GLESv2.
DOOM 3 for android port | 4 июля 2012 | 10:26 | #20 |
---|
alex_alex_men
>может это использовать?
а что же еще?
> может это использовать? у кого какие мысли?
Тебе для начала asm изучить разобраться с регистрами, константами и т.д. потом перевести на GLSL. Можно пойти по другому пути. Написать все сразу на GLSL упростив шейдеры ну будет выглядеть хуже, дальше может через документацию о освещении и т.д. в Doom 3 самому расширить/улучшить освещение и другие эффекты дописав шейдеры на GLSL, стараясь приблизится к оригиналу. Второй путь исследовательский, он сложнее и дольше. Первый путь чем-то проще и гарантирован результат, тут нужен большой опыт в программировании отладки и т.д. Ну ты я так понял совсем начинающий в графике поэтому наверное как сказал innuendo начинай с кубиков. Напиши это на ARB ASM, досконально изучи что и как. Потом перепиши на GLSL, заодно правя код рендера для его поддержки, ведь при портировании все равно это нужно будет делать, и вот после этого ты сможешь вместо ARB ASM написать шейдеры на GLSL.
>может это использовать?
а что же еще?
> может это использовать? у кого какие мысли?
Тебе для начала asm изучить разобраться с регистрами, константами и т.д. потом перевести на GLSL. Можно пойти по другому пути. Написать все сразу на GLSL упростив шейдеры ну будет выглядеть хуже, дальше может через документацию о освещении и т.д. в Doom 3 самому расширить/улучшить освещение и другие эффекты дописав шейдеры на GLSL, стараясь приблизится к оригиналу. Второй путь исследовательский, он сложнее и дольше. Первый путь чем-то проще и гарантирован результат, тут нужен большой опыт в программировании отладки и т.д. Ну ты я так понял совсем начинающий в графике поэтому наверное как сказал innuendo начинай с кубиков. Напиши это на ARB ASM, досконально изучи что и как. Потом перепиши на GLSL, заодно правя код рендера для его поддержки, ведь при портировании все равно это нужно будет делать, и вот после этого ты сможешь вместо ARB ASM написать шейдеры на GLSL.
DOOM 3 for android port | 3 июля 2012 | 23:35 | #16 |
---|
alex_alex_men
> я думаю что надо 3 набора функций использовать для поднятия шейдеров в игре.
> так ли?
Как хочешь. Ты можешь перевести GL_ARB_vertex_program на вершинный GLSL и GL_ATI_fragment_shader или GL_ARB_fragment_program на пиксельный GLSL.
> я думаю что надо 3 набора функций использовать для поднятия шейдеров в игре.
> так ли?
Как хочешь. Ты можешь перевести GL_ARB_vertex_program на вершинный GLSL и GL_ATI_fragment_shader или GL_ARB_fragment_program на пиксельный GLSL.
Убогость OpenGL API | 3 июля 2012 | 18:08 | #133 |
---|
innuendo
> А не детский сад рассуждать про регистры ?
Я же уже 100 раз говорил про убогость GLSL не cпроста его не было на PS3, в тем времена как раз и не было продвинутых мобильных игр. Шейдеры на ARB программах выдавали больший FPS чем на GLSL, вон мне Or@nge де даст соврать.
Не спроста убогий GLSL nVidia компилит Cg компилятором находящимся в дровах в код для расширений GL_NV_fragment_program4/GL_NV_vertex_program4/GL_NV_gpu_program5.
Там как раз твои любимые регистры.
Да сейчас GLSL намного лучше, появились платформы где ему нету замены, идеальный вариант это как раз GL_ARB_separate_shader_objects + GL_ARB_uniform_buffer_object на мой взгляд. Совместимость появилась. Microsoft сделал хорошую спецификацию на Direct3D Run Time хорошие средства для поддержки и отладки, разработчикам аппаратуры дрова писать стало проще. Чего не скажешь про OpenGL.
> А не детский сад рассуждать про регистры ?
Я же уже 100 раз говорил про убогость GLSL не cпроста его не было на PS3, в тем времена как раз и не было продвинутых мобильных игр. Шейдеры на ARB программах выдавали больший FPS чем на GLSL, вон мне Or@nge де даст соврать.
Не спроста убогий GLSL nVidia компилит Cg компилятором находящимся в дровах в код для расширений GL_NV_fragment_program4/GL_NV_vertex_program4/GL_NV_gpu_program5.
Там как раз твои любимые регистры.
Да сейчас GLSL намного лучше, появились платформы где ему нету замены, идеальный вариант это как раз GL_ARB_separate_shader_objects + GL_ARB_uniform_buffer_object на мой взгляд. Совместимость появилась. Microsoft сделал хорошую спецификацию на Direct3D Run Time хорошие средства для поддержки и отладки, разработчикам аппаратуры дрова писать стало проще. Чего не скажешь про OpenGL.