>>чем ты засылаешь 128 юниформ-матриц в шейдер?
glUniformMatrix4fv(pXAL->GetNamedParam("Bones"), 128, GL_FALSE, &m_pBoneTransform[0][0][0]);
__________________
Трагическая новость: Пятеро инженеров Casio умерли от смеха, узнав что Samsung анонсировали часы с заявленным временем работы в 25 часов
CrazyRussian ты вспомни, что самый большой прирост получился (раз в 20), когда ты рисовал модель без сглаживания и без освещения.
А как только ты его добавил - тут-то всё и сдохло, опустившись до результатов с глбегин. Тут, правильно Ксерокс говорит скорее проблема в самом формате моделей. И не забывай, что до какой-то версии GLSL передать можно max 64 параметра, т.е. 64 кости. То есть софтварный скиннинг всё равно придется оставить. Эх, да если бы всё так просто было - перевёл на GPU - получил прирост в 100500 fps
CrazyRussian
Точно, я и забыл уже.
Ну, попробуйте. Мне-то бессмысленно, мне транформации на цпу необходимы для расчёта стенсильных объёмов. А переносить их на гпу, требуя, таким образом, минимум четвёртые шейдеры, я пока морально не готов. Может быть, лет через десять...
Дядя Миша писал: ты вспомни, что самый большой прирост получился (раз в 20), когда ты рисовал модель без сглаживания и без освещения.
Нет, тогда речь шла о том, что без текстур и освещения сцена еще быстрей рисуется (55 фпс против 35, притом что в халфе было 7)
__________________
Трагическая новость: Пятеро инженеров Casio умерли от смеха, узнав что Samsung анонсировали часы с заявленным временем работы в 25 часов
CrazyRussian ты сглаживание-то прикрутил? А то у тебя 35 фпс без сглаживания было. И владельцы старых карточек пролетали. Сомнительная апчхимизация вообщем.
Я вообще не понимаю, что это за оптимизация такая - делать быстрее на новых карточках, а на старых - в результате вообще не работает. Я рассуждаю так - новые карточки и так мощные, как-нибудь справятся сами, а вот под старые надо подточить.
Вон волатила с каждым годом всё быстрее и быстрее у народа бегает, причём совершенно без моего участия.
Дядя Миша писал: Баг был с эвентами. Есть функция StudioFrameAdvanced, которая проигрывает анимацию. Анимации проигрываются не по кадрам, а по некоему диапазону, который всегда равен 0 - 256. Видимо для удобства.
Ну и вот, значит, когда секвенция достигает значения 256, переменная m_fSequnceFinished становится TRUE. Но ту же самую проверку влепили и в функцию GetAnimationEvent. StudioFrameAdvance в начале Think монстра, а GetAnimationEvent в конце. Таким образом у нас получается идиотская ситуация, когда анимация попросту не может завершиться - в конце её ловит GetAnimationEvent и ставит TRUE. StudioFrameAdvance видит, что анимация закончилась и запускает её заново. Но всё что между этими двумя функциями попросту не может прочитать состояние переменной m_fSequenceFinished, т.к. она опять сброшена в ноль.
И секвенция вместо одного раза играется 3-5 раз, пока не повезет.
Вы замечали, как монстры иногда тупят при выполнении scripted_sequence? Вот это именно оно. И хрен что сделаешь.
К тому же вся эта конструкция плотно привязана к fps. Отсюда кстати и растёт тот знаменитый спиритовский баг на карте gruntbattledemo, когда карта при одном фпс работает правильно, а при более высоком - уже ни в какую.
Так а в Ксаше-то почему нельзя это исправить, а пришлось имитировать? У тебя же больше свободы, чем в Half-Life SDK.
Crystallize писал: Так а в Ксаше-то почему нельзя это исправить, а пришлось имитировать?
Потому что все игры построены с учётом этого бага. Монстры вообще перестанут двигаться, если его исправить. Точнее скриптовые_секвенции работать перестанут.
Цитата:
XaeroX писал: Почему-то у меня ощущение, что ты врёшь.
Не вру а сознательно дезинформирую с целью введения в заблуждение наиболее вероятного противника.
19-09-2013 13:56
