Сообщения на форуме пользователя Andrey (33 стр.)
Software Occlusion Culling (комментарии) | 4 апр. 2011 | 12:40 | #14 |
---|
Executor
> > профит в том что на гпу раз в Нцать быстрее стало.
> Где?
6600GT 8.11 FPS без OC с OC 15.94 FPS. Я что-то не так делаю?
Если у тебя разница в пару FPS значит твоей видюхе пофигу эта простая сцена с кубиками и с таким овердравом кубиками и с тремя инструкциями в пиксельном шейдере. На основе этой реализации можно сделать хороший куллинг. Да, код местами требует хорошей квалификации программиста, ну что поделаешь, вообще нужно быть благодарным что хоть в каком-то виде появилась статья да еще с реализацией.
> > профит в том что на гпу раз в Нцать быстрее стало.
> Где?
6600GT 8.11 FPS без OC с OC 15.94 FPS. Я что-то не так делаю?
Если у тебя разница в пару FPS значит твоей видюхе пофигу эта простая сцена с кубиками и с таким овердравом кубиками и с тремя инструкциями в пиксельном шейдере. На основе этой реализации можно сделать хороший куллинг. Да, код местами требует хорошей квалификации программиста, ну что поделаешь, вообще нужно быть благодарным что хоть в каком-то виде появилась статья да еще с реализацией.
Software Occlusion Culling (комментарии) | 4 апр. 2011 | 11:12 | #9 |
---|
kas
Спасибо! отличная статья.
Спасибо! отличная статья.
Что быстрее? 1) Рекурсивная функция ИЛИ 2) Использование стека, без рекурсии ? | 1 апр. 2011 | 17:53 | #66 |
---|
Xunter
> нет, оптимизатор такое всегда вычистит, да и еслиб не вычищал - детей всего до
> 4 может быть.
понятно
> нет, оптимизатор такое всегда вычистит, да и еслиб не вычищал - детей всего до
> 4 может быть.
понятно
Что быстрее? 1) Рекурсивная функция ИЛИ 2) Использование стека, без рекурсии ? | 1 апр. 2011 | 13:52 | #63 |
---|
Xunter
Отличный пост про обходы, я кстати тоже дерево сцены без рекурсии обхожу.
ктстати
если это
переписать вот так:
скорость изменится?
Отличный пост про обходы, я кстати тоже дерево сцены без рекурсии обхожу.
ктстати
если это
for(unsigned k=0; k < node->child_count; ++k) *top++ = node->childs[k];
unsigned int child_count = node->child_count; tree_node_t* childs = node->childs; for(unsigned k=0; k < count ; ++k) *top++ = childs[k];
Маленькая проблема с std::vector | 31 мар. 2011 | 10:48 | #11 |
---|
Sergio
> Потому что для std::vector конструктор все же приватный
т.е.
std::vector<T> не будет компилится? не ошибся случайно?
s3dworld
сделай дополнительный публичный метод в классе A
> Потому что для std::vector конструктор все же приватный
т.е.
std::vector<T> не будет компилится? не ошибся случайно?
s3dworld
сделай дополнительный публичный метод в классе A
class A { public: void AddMe(std::vector<A>& list) { list.push_back(A()); } }; .. void B::F(void) { AddMe(list); }
Пришло время для прямого доступа к железу | 29 мар. 2011 | 10:54 | #279 |
---|
FROL
> С моей точки зрения это не совсем апи оверхед. Смена стейтов это смена стейтов.
> При чем тут апи?
Как причем?
вот хотя-бы посмотри http://msdn.microsoft.com/en-us/library/bb172234%28v=vs.85%29.aspx
тот-же ZENABLE, MINFILTER, MAGFILTER; ADDRESSV, ADDRESSU и т.д.
А теперь посчитай число RenderOperation уже отсортированных в кадре. Наберется прилично для сложный сцен, я имею ввиду не демки конечно.
Outlaw
> setPixelConstant
Ну лучше это не делать вообще, передавать через вершинный шейдер
> С моей точки зрения это не совсем апи оверхед. Смена стейтов это смена стейтов.
> При чем тут апи?
Как причем?
вот хотя-бы посмотри http://msdn.microsoft.com/en-us/library/bb172234%28v=vs.85%29.aspx
тот-же ZENABLE, MINFILTER, MAGFILTER; ADDRESSV, ADDRESSU и т.д.
А теперь посчитай число RenderOperation уже отсортированных в кадре. Наберется прилично для сложный сцен, я имею ввиду не демки конечно.
Outlaw
> setPixelConstant
Ну лучше это не делать вообще, передавать через вершинный шейдер
Пришло время для прямого доступа к железу | 27 мар. 2011 | 22:19 | #225 |
---|
SNVampyre
> а с тех пор процессоры стали мощнее только в полтора раза,
а быстродействие доступа к RAM памяти наверное хотя-бы на 50% ускорилось и то хорошо. И это тоже все влияет на CPU-limited
> а с тех пор процессоры стали мощнее только в полтора раза,
а быстродействие доступа к RAM памяти наверное хотя-бы на 50% ускорилось и то хорошо. И это тоже все влияет на CPU-limited
Проблемы с анимацией. | 25 мар. 2011 | 14:29 | #1 |
---|
.Scotina
> модели с 68 костями на рыло, а это 16х68 ~1088 униформов при том, что максимальное количество на ДжиФорс7600, всего, 1024. Попытался избавится от >скелетной анимации и вернутся к истокам: решил перегнать все кадры в живые вершины, но их получилось пять миллионов, и перегонка при за
а разве матрицами нельзя передавать через glUniformMatrix4fvARB ? тогда точно хватит.
> модели с 68 костями на рыло, а это 16х68 ~1088 униформов при том, что максимальное количество на ДжиФорс7600, всего, 1024. Попытался избавится от >скелетной анимации и вернутся к истокам: решил перегнать все кадры в живые вершины, но их получилось пять миллионов, и перегонка при за
а разве матрицами нельзя передавать через glUniformMatrix4fvARB ? тогда точно хватит.
S.T.A.L.K.E.R. Level. Часть 06. Прогрессивные меши и трансформированные объекты. (комментарии) | 22 мар. 2011 | 16:24 | #5 |
---|
Intor
Скачал демку, а где папка "gamedata/levels/pripyat " ?нету ее в архиве still.rar
Скачал демку, а где папка "gamedata/levels/pripyat " ?нету ее в архиве still.rar
uTile vTile формат 3DS вообще использует? | 21 мар. 2011 | 13:28 | #2 |
---|
spaceinvader
>Интересно всё-таки почему нигде нет полного описания загрузки 3DS.
Возьми 3dsftk или lib3ds там есть все по идее.
>Интересно всё-таки почему нигде нет полного описания загрузки 3DS.
Возьми 3dsftk или lib3ds там есть все по идее.
[STLPort] Утечки памяти | 21 мар. 2011 | 13:08 | #18 |
---|
slava_mib
>можно попросить поделиться кодом (а ещё лучше проектом с сорцами) теста?
Конечно Тест std::sort алгоритма
Код скомпилен без исключений с максимальной оптимизацией.
Заодно вывел тип процессора. У меня 26 мс на 200000 числах без STLPort, STLPort нету под рукой. Желательно потетить на других платформах, правда я не написал аналог QPC.
all
Потестите и скажите результаты.
>можно попросить поделиться кодом (а ещё лучше проектом с сорцами) теста?
Конечно Тест std::sort алгоритма
Код скомпилен без исключений с максимальной оптимизацией.
Заодно вывел тип процессора. У меня 26 мс на 200000 числах без STLPort, STLPort нету под рукой. Желательно потетить на других платформах, правда я не написал аналог QPC.
all
Потестите и скажите результаты.
[STLPort] Утечки памяти | 21 мар. 2011 | 11:33 | #13 |
---|
slava_mib
slava_mib
> При правильных опциях компиляции + использовании функторов + грамотном коде,
> большая часть алгоритмов, должна инлайниться, вроде как. Я сильно сомневаюсь,
> что в стлпорт реализованы какие-то кардинально новые методы той же самой
> сортировки, скажем. Но утверждать, что это не так - не буду )
Запусти тест std::sort и сравни скорость, у меня получалось 20%, тестировал на массиве uint32 ну и посмотри как реализован std::sort в STLPort и стандартная реализация от MSVC. Разница существенна в реализациях. В STLPort циклы разворачиваются, сам понимаешь уже прирост будет.
slava_mib
> При правильных опциях компиляции + использовании функторов + грамотном коде,
> большая часть алгоритмов, должна инлайниться, вроде как. Я сильно сомневаюсь,
> что в стлпорт реализованы какие-то кардинально новые методы той же самой
> сортировки, скажем. Но утверждать, что это не так - не буду )
Запусти тест std::sort и сравни скорость, у меня получалось 20%, тестировал на массиве uint32 ну и посмотри как реализован std::sort в STLPort и стандартная реализация от MSVC. Разница существенна в реализациях. В STLPort циклы разворачиваются, сам понимаешь уже прирост будет.
STL на консолях тред тут | 24 фев. 2011 | 18:30 | #137 |
---|
innuendo
> на стеке наверное можно бъло жить и на глобальнъх переменнъх
Ты стебешься? Еще раз, это значит, что можно тупо хранить данные в глобальных и стековых переменных, не использую другие функции выделения памяти, представленные C Run Time Library, либо другими средствами, к примеру драйвер расширенной памяти под MS-DOS(EMM386.EXE).
> на стеке наверное можно бъло жить и на глобальнъх переменнъх
Ты стебешься? Еще раз, это значит, что можно тупо хранить данные в глобальных и стековых переменных, не использую другие функции выделения памяти, представленные C Run Time Library, либо другими средствами, к примеру драйвер расширенной памяти под MS-DOS(EMM386.EXE).
STL на консолях тред тут | 24 фев. 2011 | 18:07 | #135 |
---|
innuendo
> знаю, а что такое "на стеке наверное можно бъло жить и на глобальнъх
> переменнъх" - не знаю, поясни, пожалуйста
> знаю, а что такое "на стеке наверное можно бъло жить и на глобальнъх
> переменнъх" - не знаю, поясни, пожалуйста
Практически большинство данных могли уместиться в глобальных переменных(в сегменте данных тут можно про регистры DS, ES вспомнить), остальное на стеке. Этого хватало в те времена.
Вот в грубом приближении имелось что в ввиду:
// types struct st1 { type1 var1; .... typen varn; }; // Global Variables; char buf[256]; int flag1; int flag2; .... // main function void GameMainLoop() { // stack variables int var1,....var2 float array1[100],... float arrayn[20]; st1 arrayst1[40]; LoadData(....); InitAllVariables(array1, ...array2, st1); while(true) { UpdateGameLogic(array1, arrayst1,....); UpdateInput(...); DrawGame(...); } }; int main() { StartGame(); GameMainLoop(); return 0; }
Список активных участников | 22 фев. 2011 | 12:52 | #21 |
---|
Буду наблюдать за проектом вести обсуждение в форумах. Для разработки к сожалению не хватает времени.