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

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

AMD CodeXL Новое средство отладки и профилирования CPU/GPU/APU от AMD (комментарии)4 окт. 201210:36#6
Suslik
> я так и не понял, оно на intel/nvidia будет работать?
Пока что на nVidia он запустился. Не успел еще пощупать подробнее.
GLSL и мультитекстурирование3 окт. 201211:10#13
Metal_heaD
> GL_ARB_multitexture
Этому устаревшему хламу уже больше 20 лет. Результат пиксельного шейдера перетрет его работу.
>Но вот как быть с кодом, который отвечает за мультитекстурирование? Оставить его неизменным?
Лучше делать на шейдерах поэтому забудь понятие мультитекстурирования начиная с железа nVidia 5200 и ATI 9550. В пиксельном шейдере делаешь "арифметику" цветов как тебе нужно. Складываешь, смешиваешь с чем хочешь и как хочешь.
>Можно ли в шейдере работать уже с конечным пикселем( результат смешения пикселей каждой текстуры)?
Ну а если ты хочешь извращений и мешанины FFP + шейдеры тогда изучай всякие комбинации вызовов glTexEnv* + передача пикселя по результатам смешивания текстур в пиксельный шейдер, а там пиши в gl_FragColor уже финальный результат, если конечно у тебя GLSL, только я не знаю как это сделать да и тут люди уже давно забыли про FFP и врядли что посоветуют.
Вот извращайся http://www.opengl.org/wiki/Texture_Combiners.

Ваши движки2 окт. 201213:05#40
innuendo
>так пачками или за 1 вызов только ?
Там у него Android и нету UBO, так что все сложнее. На PC за 1 вызов, На Android пачками.
Минимальный код mp3 декодера2 окт. 201213:03#18
XProger
libmad смотрел? Может что оттуда подчеркнешь.
Ваши движки2 окт. 201211:47#38
bazhenovc
Посмотрел движок. Код аккуратный. Небольшие замечания.
vsprintf(buf, fmt, arg);// - небезопасно. Лучше vsnprintf
...
  for (size_t i = 0; i < _particleCount; ++i) {
    _vertices[i].pos[0] = _particles[i].pos.x;
    _vertices[i].pos[1] = _particles[i].pos.y;
    _vertices[i].pos[2] = _particles[i].pos.z;
    _vertices[i].life[0] = _particles[i].life;
    _indices[i] = (unsigned int)i;
  }
может лучше memcpy тут ?
  _indices = (unsigned int*)malloc(_particleCount * sizeof(unsigned int));
16 битных индексов для частиц хватит. Вообще данный под частицы можно и в статическом массиве хранить. Проще код.
    bool operator()(Light* l1, Light* l2)
    {
      float len1 = glm::length(l1->position - (cam->position + cam->up));
      float len2 = glm::length(l2->position - (cam->position + cam->up));
      return len1 > len2;
    }
Небольшая оптимизация, сравнивать можно и квадраты
  _rootNode = new SceneNode;
я бы узлы сцены линейно в памяти хранил бы. Их вообще можно ограничить (до 1000) и опять таки хранить в статическом массиве. Ну нету смысла дробить так подробно сцену.
    _program->setUniformVector("bakedCameraData", cam->bakedData);
    _program->setUniformVector("screen", cam->viewport);
    _program->setUniformVector("light.pos", position);
    _program->setUniformVector("light.ambient", ambient);
    _program->setUniformVector("light.diffuse", diffuse);
    _program->setUniformVector("light.specular", specular);
    _program->setUniformFloat("light.radius", radius);
    _program->setUniformFloat("range", radius);
    _program->setUniformMatrix("mvp", cam->projection * matrix * glm::translate(position));
    _program->setUniformMatrix("invModelView", glm::inverse(matrix));

Лучше пачками константы слать, да и сразу uniform location узнать. Строки в Real Time это зло.
    Vertex* vertices = (Vertex*)malloc(numVertices * sizeof(Vertex));
    unused = fread(vertices, sizeof(Vertex), numVertices, file);
...
    sm->getVertexBuffer()->bind();
    sm->getVertexBuffer()->copyData(vertices, numVertices, sizeof(Vertex),
                    BU_STATIC);
....
    for (size_t j = 1; j < numVertices; ++j)
      sm->box.addPoint(vertices[j].pos[0],
                 vertices[j].pos[1],
                 vertices[j].pos[2]);
1) Зачем выделять память потом копировать в VBO ? можно читать в залоченный буфер сразу. Не увидел у тебя free для 2 указателей.
2) Лучше Box хранить в файле а не считать.
3) Не очень оптимально написан загрузчик и разработан формат файла меша. Лучше читнуть Header(вместе с box числов вершин индексов типом формата и т.д.)  потом сразу в видюху загружать. Либо вообще inplace loading
Ваши движки1 окт. 201215:54#33
namot
Отличный проект. Текстурирование я так понимаю аффинное?
Кто пил из моего стакана ? :) (К вопросу о том как определить трогал ли кто матрицу ОГЛа)28 сен. 201220:00#4
Gladiator
Все просто. После каждой строчки запрашивай glGetFloatv и сравнивай со матрицей. В виде функции сделай и найдешь.
Проблема при линковке шейдера GLSL27 сен. 201219:19#14
RockFate
> А вообще много видео карт так криво работают с огл?
много. Ищи по форуму. ATi, Intel, реже nVidia
Проблема при линковке шейдера GLSL27 сен. 201218:59#12
RockFate
> Я потестил на разных видюхах. Пришел к выводу что у меня самая "лучшая" видеокарта...
Ну что. Линковать и компилить можно в других потоках, и ты наверняка делаешь корректно это. Шли баг репорт Intel :))). Проверил бы второй случай, интересно.
как всегда убогая поддержка OpenGL.
DirectX9, 32-bit Index Buffer, Intel Video.27 сен. 201217:28#11
Mikle
Я думаю что не стоит верить D3DCAPS9 для Intel Карт. К примеру Intel GMA 3150 вообще не выдает версию вершинных шейдеров хотя держит ps_2_0. Какие там вершинные не понятно, но vs_2_0 держит.
Проблема при линковке шейдера GLSL27 сен. 201217:02#10
RockFate

С кодом все нормально.

> Shader program link...
> Shader linking start:
> Vertex Shader ID:1
> Fragment Shader ID:2
> ShaderProgram ID:3
> Shader program linking - fail!
> Number of Vertex Attributes exceeds HW limits.
> Number of Fragment Outputs exceeds HW limits.
Ну судя по логу, ты корректно получаешь шейдера для линковки из потока компиляции.
тут две мысли:
1) Вижу что Intel карта да еще OpenGL 3.0, возможно дрова бажные еще. с GLSL у них наверняка не все хорошо. Проверь на других картах. Ждем проекта минимального.
2) Не запускай поток линковки пока не скомпилятся шейдера в потоке компиляции. Компиль шейдера, расшарь контексты. Запусти поток линковки.
Если будет работать баг драйвера, если на других картах так значит что-то не так еще где-то или вообще компилятор шейдеров и линковщик вообще одно поточный. Что пишет стандарт по этому поводу я не знаю.

Что говорит GetLastError() после wgl функций?

Проблема при линковке шейдера GLSL27 сен. 201210:23#7
RockFate
>При компиляции все нормально. Но при линковке пишет:
Везде ставил glGetError() ?
>Работают разные контексты, но они разшарены.
какая ОС ?
Уверен что корректно расшарены? для Windows после wglMakeCurrent/wglShareLists проверь что возвращают функции, вызови glGetLastError() может что будет понятно.
Вообще сделай минимальный проект и залей я гляну(если Windows конечно). Интересно очень.
[A][R][T]
> Как ты это дело синхронизируешь? Когда начинается линковка, шейдер уже успел скомпилиться?
Вопрос хороший, но он же получает id двух программ.
OpenGL ES 3.0: поехали...25 сен. 201213:23#46
.::jimon::.
У меня нету ios и всех средств для этого, были бы не писал исследовал бы сам. Поэтому и попросил. Интересная тема очень для меня.
OpenGL ES 3.0: поехали...25 сен. 201212:26#44
.::jimon::.
> информация основывается на профилировщике xcode (в дебаг символах всё же видно что он отчасти делает)
Пару строчек можешь выложить? и свои выводы по этому поводу. В частности про malloc к примеру, про преобразования данных, про то что внутри не O(1) и т.д.

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

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