Войти
ФлеймФорумОбщее

Пароль на архиве с исходниками Game7? (3 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#30
2:29, 28 мар. 2005

tav
>>На счет архитектуры, тут я не силен, все вопросы к Флаю.
>Насчёт батчей, это скорее к дизайнерам, а точнее моделлерам уровня. Хотя...
>переделывать всё, конечно, глупо. Я вообще-то имел в виду увеличение числа
>объектов и уменьшение их размеров, т.е. разбивку объектов на несколько
>(особенно больших).

Эээ... Флай... ты где. Тут наших бьют :) на несколько маленьких объектов.

>>А в результате, на порше ездит владелец хостинга gamedev.ru
>Думаешь он этого не заслужил? Не каждый человек и не каждый день создаёт
>подобные ресурсы.

Бр. ВЛАДЕЛЕЦ ХОСТИНГА. Бр. Ват... не владелец.

>>а еще договорился с Сапфиром, чтоб мы обязательно заняли первое место на
>>конкурсе
>А без этого вы бы его не заняли?

Заняли-незаняли. Какая тепрь разница?

>Я не хочу никого оправдывать, но идеальных людей нет, и отдельные поступки не
>отражают полностью характера человека.
>А представить массам можно кого угодно и в каком угодно свете. Это ничего по
>сути не меняет.

О! Мудрец. Можно я тебя расцелую. ;)


#31
3:11, 28 мар. 2005

Zulus
>Ват... не владелец.
???
Хм. А кто тогда владелец?

#32
3:24, 28 мар. 2005

tav
Владелец хостинга и владелец ресурса, как правило, разные люди. Владелец ресурса покупает место на сервере у владельца хостинга, после чего ресурсу прописывается DNS сервера. Если я не ошибаюсь, Ват хостится у Зенона. Так что на порше ездит не Ват. :)

#33
4:37, 28 мар. 2005

tav
http://download.nvidia.com/developer/GPU_Programming_Guide/GPU_Pr… ing_Guide.pdf


3.2.1.
Use Fewer Batches “Batching” refers to grouping geometry together so many triangles can be drawn with one API call, instead of using (in the worse case) one API call per triangle. There is driver overhead whenever you make an API call, and the best way to amortize this overhead is to call the API as little as possible. In other words, reduce the total number of draw calls by drawing several thousand triangles at once. Using a smaller number of larger batches is a great way to improve performance. As GPUs become ever more powerful, effective batching becomes ever more important in order to achieve optimal rendering rates.

так что ты что-то напутал говоря
>ИМХО, число батчей надо увеличить... раза в 2-4.

#34
5:29, 28 мар. 2005

>>Дельфист решил поддержать дельфиста :) понимаю. Вы банда, да?
Пытаешься развести всех на флейм? :)
Лучше бы шум устраивали около коммерческого проекта, а не предназначенного для обучения детей, или это типа тренировки? :)

#35
9:34, 28 мар. 2005

Dusk
Знаешь, ты вроде вменяемый чувак. Хоть и пишешь на дельфи. Я честно говоря удивился, увидев тебя в этом топике. Ну там, Спинер или еще кто. Ладно, им завидно. А тебя то как занесло?

#36
10:37, 28 мар. 2005

Zulus
" и умные люди этим пользуются. А глупые над подобным смеются. "
Ну конечно, не воспользовался - дурак, других причин, типа принципы, мораль - нет, точнее есть, для дураков.
А если кто не согласен с твоим мнением - завидует.
А если кто вежлив - значит трус.
А кто занял деньги и отдал - лох.

Ничего личного, так, общие мысли.

#37
11:17, 28 мар. 2005

Mikle
Мораль есть. Но ты сам себе судья. Общество навязывает ложную мораль, удобную государству. Простой пример, политика. Думаешь они там все ради денег? Я так не думаю. Но это не мешает устраивать революции. Так что мораль уничтожает слабых и воспитывает сильных. На счет вежливости, опять же, ты слишком упрощаешь. Вежливый трус :) тебе не смешно? Так что вежливость лучше оставить в покое, а вот деньги. Если ты украл деньги у государства или алигарха, ты плохой и тебя общество накажет. А если ты обираешь население, забираешь последнее, то хороший. И тебе все апладируют. Никакой логики. Так что если ты сознательно не вернул то, что взял без спроса, это украл. Если сознательно не вернул то, что попросил у другого, то обманул. А если ты вернул или не вернул, не важно, потому что дурак или лох, то это вообще нельзя точно классифицировать. Т.к. ты сам точно не знаешь, почему так поступил. У тебя небыло точного плана: взять и не вернуть. Ты надеялся вернуть, но так как тебя самого обворовали, то ты вроде уже как и не причем, и вернуть не можешь. Оправдываться начинаешь, еще денег просишь. И такому ничего не простительно. А то что в этой ветке происходит, называется управляемый Флейм. Пока он интересен мне и Флаю, он будет жить. Как наскучит, можно будет его медленно свести на нет.

#38
11:34, 28 мар. 2005

tav
>Я вообще-то имел в виду увеличение числа
>объектов и уменьшение их размеров, т.е. разбивку объектов на несколько
>(особенно больших).

А ты можешь точно описать процесс рисования видеокартой объектов и детально объяснить, почему увеличение кол-ва батчей в ДАННОЙ сцене уеличит FPS? Иногда такое применяется, но приемлемо ли это в нашем жуке? Порассуждай, а я послушаю :-)

#39
11:56, 28 мар. 2005

CyberZX
За ссылку конечно спасибо, хотя зачем оно мне... ну да ладно. Вообще-то советы NVIDIA относятся к GF 6/FX series, а мне так кажется, что NVIDIA метит ещё дальше в последующие поколения.
>так что ты что-то напутал говоря
Нет. Я сказал, что и хотел сказать. Правда ничего толком не объяснил, потому меня и не поняли.
Если ещё не видел, посмотри http://www.ixbt.com/editorial/kri2004.shtml , ну ещё можешь http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf.
ATI рекомендует использовать 500K тр-ков в кадре при <500 вызовах DrawIndexedPrimitive/DrawElements. Это, надо полагать для оптимальной загрузки видеокарты, т.е. для достижения потолка обработки геометрии видеокарт. Для реальных игр такие цифры не совсем применимы. Точнее применимы для игр, которым до выхода ещё остался год-два.
Игре "Приключение жука Кузьмича на речке-вонючке" же до финального релиза и издания остались считанные месяцы, надо полагать, имхо однако. Да и целевой игрок соответствующий.
А потому в игре в кадре (как можно видеть) не 500K, а 50K Tris. Разница ведь есть, верно?
И дело всё в том, что на относительно слабых компах батчи не являются такой проблемой, как на high-end: всё упирается в тот же fillrate слабых видюх, потому о батчах заговорили не так уж давно, да и то лишь с оглядкой на будущее.
Совета моего, конечно, слушать никто не будет, да и эффективность весьма спорна, т.к. движок AE II рассчитан скорее на high-end видеокарты, ну в крайнем случае на mainstream.
Просто на GFMX'ах все эти советы NVIDIA и ATI про батчи смысла почти не имеют, во всяком случае цифры и графики, указанные в том же BatchBatchBatch явно преувеличены.
Хотите верьте, а хотите нет, но на довольно экзотической системе AthlonXP 1700+; GF4 MX на 61.77 разницы между VBO (одним вызовом выводятся все ~27000 тр-ков) и выводом геометрии через glBegin/glEnd практически нет (пара процентов, даже меньше). А на Athlon3000+; GF6800GT разница более чем на порядок.

#40
12:55, 28 мар. 2005

tav
>Хотите верьте, а хотите нет, но на довольно экзотической системе AthlonXP 1700+; GF4 MX на 61.77 разницы между VBO (одним вызовом выводятся все ~27000 тр-ков) >и выводом геометрии через glBegin/glEnd

факт остается фактом, каждый DIP-call это выход в cr0. Что само по себе довольно не быстро так.
Вот есть у нас например сцена из 100 000 000 треугольников, выводим мы их через glBegin/glEnd. Пускай каждый вызов glVertex будет занимать 20 тактов, это на сам вызов, а не на исполнение даже. На каждую вершину уходить по три таких вызова получаем 60 тактов. В результате на вывод одного кадра геометрии у нас уходит 60 000 000 тактов. На машине P4 3 GHZ только одни вызовы функции займут 20мс! это огромная цифра! и видеокарточка тут не виновата, так как батчинг  жрет ресурсы процессора, причем не малые совсем.

#41
13:05, 28 мар. 2005

tav
и вообще. либо делать игру красивой, либо делать ее такой, что бы она шустро бегала на GFMX.  нельзя сделать и то и то одновременно
эти карточки стоят порядка 10$
давайте еще под TNT2 оптимизировать.  вот здорово будет. причем та оптимизация которую ты предлагаешь, является пессимизацией на других карточках.

#42
13:09, 28 мар. 2005

Fly
Если меши не содержат стрипов, то можно сделать так. Все статичные объекты при загрузке разбиваются рекурсивно на подобъекты следующим образом: пока число тр-ков в объекте будет выше некоторого значения, а также размер максимальной стороны BBOX-а будет больше некоторого значения подобъект разбивается на 2 подобъекта плоскостью, проходящую через центр плотности тр-ков. Направление нормали плоскости определяется исходя из габаритов BBOX-а -- деление происходит разрезом большей стороны BBOX-а. А положение делящей плоскости определяется как среднее арифметическое соответсвующей координаты (определяется исходя из направления нормали пл-ти) вершин всех тр-ков подобъекта.
Далее тр-ки разбиваются на 2 группы. Тр-ки, вершины которых лежат по обе стороны от делящей плоскости помещаются либо в 1-ую группу (если, напр., порядковый номер этого тр-ка чётный), либо во 2-ую. Параллельно с этим разбиением формируются 2 BBOX-а новых подобъектов (которые в общем случае могут пересекаться).
После всех разбиений каждый объект тем не менее считается единым целым (предполагается, что он будет состоять из 2-4 подобъектов), тр-ки в нём упорядочиваются по отдельным подобъектам, таким образом все треугольники отдельного подобъекта могут быть выведены одним API вызовом.
Рендер объекта также осуществляется невзирая на scene graph отдельно от него и происходит слудующим образом: если объект полностью внутри frustum-а, то он выводится весь одним API вызовом. Иначе в цикле определяются ципочки видимых подобъектов (видимость каждого определается по его BBOX-у) и вся цепочка выводится одним API вызовом с соотвующим диапазоном индексов (т.е. напр., если первые 3 подобъекта выводимого объекта видимы, они выводятся за один батч, если следующие 2 невидимы - они не выводятся, а последний видим - выводится за батч он один).

Т.к. подобные преобразования при загрузке очень ресурсоёмки, то можно при загрузке создать дополнительный поток, обрабатывающий очередь поступающих объектов. В основном потоке ресурсы игры будут загружаться во временные буферы и помещаться в очередь, обрабатываемую доп. потоком. Это ликвидирует пузырьки при загрузке данных. Чтобы не было геморроя с доступом доп. потока к средствам D3D (хотя, как с этим обстоят дела в D3D мне не известно), можно в доп. потоке осуществлять всю загрузку, а в основном - разбивать объекты, заполнять D3D буферы данными и выполнять другую инициализацию по завершении (возврате управления) WaitForSingleObject, напр.

#43
13:13, 28 мар. 2005

tav
Ты даже не понимаешь сути проблемы с батчами. Ты бы поэкспериментировал для начала, а потом советовал бы алгоритмы.

#44
13:34, 28 мар. 2005

Zulus
Откуда в твоих зловах столько яда? Столько злости и презрения к окружающим? Ведь даже, когда ты ни с кем не споришь, то все равно твои фразы наполнены негативом по отношению к окружающим? Я не поверю, что это просто защита от нападок людей, подобных Снайперу.  Таких можно либо игнорировать, либо нормально и вежливо убедить в их неправоте. Такое ощущение, что вы изначально специально своим поведением настроили народ против себя, что бы потом был повод с этим народом погризться. Это такой пиар Флая? Тогда вы пошли по неверному пути, ведь даже может быть Флай и умный мальчик, но таким пиаром вы добъетесь того, что его будут знать не как хорошего и талантливого программиста, а как человека эгоистичного и погрязшего в своей гордыне, который только себя считает самым умным, а всех остальных грязью. Зачем вам это? Надо любить и уважать окружающих людей, тогда и не будет кофнликтов, тогда не будет негатива.
А стеб над маленькими это очень недостойное занятие.

Страницы: 1 2 3 4 5 6 7 Следующая »
ФлеймФорумОбщее

Тема в архиве.