125. Blackwinged - 02 Ноября, 2005 - 15:22:10

Цитата: Ох... Ну тогда тебе убер вопрос - а как же врубить в Doom3 Ultra Shadow ? Я его включал тем методом, что описан в FAQ Мира nVIDIA: "Владельцы видеокарт с поддержкой технологии UltraShadow 2.0 (GeForce 6800, 6600) могут включить режим проверки видимости теней для ускорения прорисовки. Для этого в папке base в каталоге игры или в папке мода надо создать файл autoexec.cfg и добавить в него строку: r_useDepthBoundsTest "1"."

126. jm - 02 Ноября, 2005 - 15:49:02

О как... Видмо все же дурак я. Проверим Хотя далекоидущие выводы пока не буду делать. (Добавление) Поизучал интернет. Это конечно не сам ultra shadow, ultra shadow все же это архитектурное название, но ассоциации конечно есть одного с другим конечно есть. В любом случае спасибо за полезный совет (Добавление) Цитата: Цитата: Cvar: r_useDepthBoundsTest Type: bool Description: Use depth bounds test to reduce shadow fill (Добавление) А вот забавная дискуссия в которой народ говорит, что прироста нет http://www.elitebastards.com/forum/viewtopic.php?t=6330&sid=a744ee3170c83bf5168ac2a8ea67ff8b

127. aressto - 16 Ноября, 2005 - 09:51:17

может быть немного оффтоп, но заметил что лежит сорс Blood2 - http://www.the-chosen.com/mods/ или это всего лишь SDK

128. jm - 22 Ноября, 2005 - 08:14:05

Это game src на сколько я помню. То есть не исходники самого движка, а только логика игры. По типу как в Quake2/3 game src давно были открыты. Хотя могу и ошибаться - исходники NOLF то они давно открыли. (Отредактировано автором: 22 Ноября, 2005 - 08:14:56)

129. Гость - 22 Ноября, 2005 - 16:14:17

Цитата: Это game src на сколько я помню. То есть не исходники самого движка, а только логика игры. Вроде там же есть исходники движка, но из-за неудачности второго Blood'а ими мало кто интересуется. Цитата: Хотя могу и ошибаться - исходники NOLF то они давно открыли. Нет, не ошибаешься, они точно открыли исходный код NOLF 1 и Contract JACK.

130. jm - 23 Ноября, 2005 - 04:58:56

Я не о том. Я вкурсе что NOLF открыт. Я имел ввиду, что могу ошибаться на счет сурсов блад2, и что они тоже открыты. Кстати утверждение о неудачности блад 2 не имеет отношения к теме в данном контексте - речь то идет о движке lithtech1/2. А на нем достаточно много всего было написанно.

131. Гость - 23 Ноября, 2005 - 15:42:06

Цитата: Кстати утверждение о неудачности блад 2 не имеет отношения к теме в данном контексте - речь то идет о движке lithtech1/2. А на нем достаточно много всего было написанно. По-моему мне удалось скомпилить исполняемый файл NOLF 1 в Visual C 6, но его работоспособность не проверял, т.к. у меня нет самих ресурсов игры. Видимо, исходники движка они тоже открыли.

132. jm - 23 Ноября, 2005 - 16:32:54

Чего там компилить то ? Открыл *.dsw или *.dsp файл и нажал build в ide. Или в случае make-файла под рукой Nmake. Никакого напряга.

133. Гость - 23 Ноября, 2005 - 16:37:18

Цитата: Чего там компилить то ? Открыл *.dsw или *.dsp файл и нажал build в ide. Или в случае make-файла под рукой Nmake. Никакого напряга. Ну конечно, это я к тому, что исходники lithtech тоже открыты. (Отредактировано автором: 23 Ноября, 2005 - 16:38:18)

134. jm - 25 Ноября, 2005 - 04:00:52

Меня вот на данном этапе очень интересуют исходники FEAR Причем совсем даже не графическая часть. Я даже не хотел бы ими обладать, мне просто хочется узнать, насколько AI там зависит от дизайнеров. Поясню. AI в FEAR производит очень достойное впечатление (кстати не без греха тоже ). Вот только скорее всего во многом это заслуга не только программистов. Скорее всего очень сильно поработали дизайнеры добавляя назовём их образно AI-маркеры. Это может быть что угодно - например отметка удачного для засады места. Кто рисовал вейпоинты для ботов в CS тот поймет о чем я. Вобщем мне просто любопытно - насколько AI будет от этих "маркеров" зависесть. Я думаю, когда они зарелизят SDK это сразу всплывёт наружу. Кстати совершенно не согласен с утверждением Blackwingedа на счет скриптовости АИ в FarCry. Там как раз все наоборот - никаких скриптов, но есть те самые маршруты и маркеры Наличие скриптов проверить очень легко - загрузиться и проверить как себя поведет АИ в изменившихся условиях. Если надо, можно уточнить у разработчика напрямую - есть знакомые в крайтек Вот Hl2 это типичный пример садистской заскриптованности (Добавление) ps кстати, посмотрите игрушку NERO (урл не помню, но ссылки на неё выкладывали на www.nnm.ru, около 30-40 мб) - первая из мною виденных игр использует нейронные сети и самообучающийся AI Войны роботов, причем роботов надо сначала обучить методом кнута и пряника.

135. Blackwinged - 26 Ноября, 2005 - 02:54:44

Цитата: Вот Hl2 это типичный пример садистской заскриптованности Я в Халву вторую не играл. А в Far Cry AI оппонентов для меня слишком лёгок как для человека, закалённого "боталиями" в UT2004 и в сетевых разборках с реальными живыми людьми. Особенно меня бинокль убил - ну это ж вообще почти читерство. Уберите его нафиг - так и хочется сказать разрабам. А вот в F.E.A.R. AI оппонентов на уровне. За что Монолиту поклон. Вообще, jm , я просто был не в курсе, что в Far Cry интеллект оппонентов не скриптованный. Просто при игре у меня сложилось именно такое впечатление.

136. jm - 26 Ноября, 2005 - 12:28:02

Вообще говоря если быть до конца честным скрипты наверняка есть везде и всегда - организация уникальных событий. Например сценки и диалоги в FarCry. Другое дело на сколько активно их используют и используют ли их в собственно спонтанных действиях - ну там вышибание дверей etc На счет легкости FarCry... Ммм... Ты в него на какой сложности играл ? Поставь реалистик и твой опыт UT2004 можно спокойно слить Точно так же "обламываются" CS-ники когда приходят играть с нашей небольшой коммандой по SWAT4. Играем то кооперативом, но этих ребят ложат одними из первых либо они просто подрывают рейтинг комманды

137. Blackwinged - 26 Ноября, 2005 - 23:19:29

Цитата: Поставь реалистик и твой опыт UT2004 можно спокойно слить Может и так. Но! Far Cry я прошёл, и не раз, сейчас он мне уже неинтересен, да и F.E.A.R. я по чайной ложке в день прохожу. Чего-то меня автогонки увлекли, хотя клава уже пострадала - некоторые кнопки западать начали, блин. Руль брать, что ли? Всё же в Need For Speed с клавы играть не очень.

138. jm - 27 Ноября, 2005 - 08:32:18

Ну не знаю. У меня FarCry вызывал бОльшие проблемы в некоторых местах чем FEAR. В FEAR slowmo решает ps Вот сейчас докачаю книжечку 2005 года о нейронных сетях и буду просвящаться

139. Slava - 22 Декабря, 2005 - 21:48:58

jm и люди сведущие, можешь дать ссылки и/или написать небольшой ликбез на тему того, как в играх (не только 3D) осуществляется равномерное течение игрового времени в игровом мире не зависимо от скорости процессора? Должны же быть некоторые стандартные решения и общие схемы, на которые стоит опираться. Циклы типа for i=1 to 100 do; мы писали в школе А как это делают продвинутые дяди?

140. LifeKILLED - 23 Декабря, 2005 - 21:57:20

Мое мнение: есть такая вещь, используется компьютерный таймер. Monstermove=1meter*time - т.е. передвижения по карте и остальные процессы рассчитываются по отношению к пройденному времени (либо умножаясь, либо как-то еще). Поэтому 120 fps или всего 5, а замочат одинаково быстро (в 5 fps даже быстрее )

141. Denister - 15 Апреля, 2006 - 18:43:59

Про игровое время: Могу рассказать свой опыт (Писал когда то давно римейк танка с праставки). Цитата: Monstermove=1meter*time это не совсем правильно. Потому что получать значения таймера мы можем только с определенными интервалами - где то в 1 мс, а это очень много, ведь за это время процессор тактуется несколько тысяч раз. могу ошибиться - поправьте, но принцип верен: 1мс = 0.001с, а 1МГц = 1000000раз/1с. Значит, если использовать принцип Monstermove=1meter*time мы увидим что то похожее на сетевую игру с лагами... Другое дело, если эти прерывания от таймера используются для анализа игрового состояния - Ingame Time и внесения в него определенных корректив. Я например, использовал задержки циклов (delay). То есть внутри таких временных прерываний мы проводим анализ: ага выполнилось слишком много циклов -> увеличить задержку пропорционально. То есть так можно универсально корректировать Ingame Time в зависимости от загрузки процессора как нашей игрой так и сторонними процессами. В условиях Windows, кроме вышесказанного, мы можем отвоевывать процессорное время путем 1 - повышения приоритета своего процесса 2 - путем использования потоков (threads) потому что вроде как Win32 распределяет процессорное время пропорционально количеству потоков, используемых приложением.[q]

142. jm - 24 Апреля, 2006 - 02:31:20

oi Вот Слава письмецо прислал, дал ссылочки... Щас начну придераться/высказывать свое мнение Можно ? LifeKilled что ты подразумеваешь под компьютерным таймером ? Не согласен с Denisterом - циклы задержки ? Некрасиво. Если не сказать грубее. На разных по мощностям процессорах циклы задержки будут задерживать по разному Подстраивать их под каждую машину не реально потому, что реальную производительность системы ты не получишь. Есть алгоритмы детектирования чистоты используя счетчики (таймеры) высокого разрешения (High resolution timers, о которых я еще упомяну позже), но правильность работы этих алгоритмов будет зависеть от загруженности системы. Резюме - циклы задержки не для настоящих пацанов По поводу интервала в одну миллисекунду справедливо только при использовании мультимедия функций timeGetTime() и иже с ними. Серьезные игры никогда не используют их для замеров (или могут использовать просто как fallback если железо не держит/эмулирует уже упомянутые HRT). Для замеров высокой точности игры используют QueryPerformanceCounter/QueryPerformanceFrequency(). Заинтересованные грызем доки по этим функциям. А еще можно почитать intel доки по поводу инструкции rdtsc Вариант того, как должна работать игра, которая не будет зависить от мощности системы. Задумайтесь, по сути, игрок живет в игре только в те моменты, когда отрисовывается очередной кадр. То есть появление игрока в мире дискретно. Скажем при fps в 80 мы 80 раз появляемся в мире игры. А теперь задумайтесь, что у любой сущности есть такие характеристики как например скорость. То есть всё, что нам нужно сделать при, например, движении игрока это расчитать время между кадрами и перемножить это на его скорость. Все. Независимо от того, как быстро работает компьютер (дает он 100 или 30 кадров) за равные промежутки времени мы всегда будем проходить равное расстояние. Ньюансы вроде контроля столкновений конечно же тоже надо расчитывать, чтобы не оказаться в ситуации когда пуля пролетит стену например Кстати этот метод легко объясняет дерганость в тормозящей игре. Обратите внимание - если у вас в игре 5-7 кадров любое казавшеся ранее плавным движение мыши превращается в ступенчатые скачки. Еще относительно таймеров высокого разрешения. С выходом dual core процессоров (двуядерников) там есть какие то ньюансы. Не вникал. Кому интересно читаем рекомендации intel/amd. В pain killer используется какая то иная система тайминга. Если дойдут руки когда нибудь загляну в неё дизассемблером Уж очень она любопытна. На словах сложно объяснить. Просто Painkiller "тормозит" (если тормозит, ну вы поняли о чем я) совсем не так, как обычно Я бы сказал даже красиво Когда я был еще маленький я написал следующую статью: http://gamedev.chat.ru/articles/a0009.html Вполне уместна я думаю

143. LifeKILLED - 24 Апреля, 2006 - 13:46:42

Да я почти то же самое имел ввиду... В БладЛайнз, если усердно прыгать внутри движущейся машины, можно выпрыгнуть за невидимые стены. Меня это бесит, т.к. когда мне скучно, я все время прыгаю (дурная привычка проверять глюки поэтому в СектВар я не сделал выезд на улицу со двора, как намечал ) Кстати, а ведь есть такой термин, как "серверный кадр". Он то ли в сетевухах, то ли он и вообще везде используется... То есть, например, ведется рассчет поведения, шевеления извилин ботов, раз в этот кадр и вычисление перемещения в НЕзависимости от fps рендера. Насколько правильно я понял? Или же эти кадры - просто блоки информации координат пуль, игроков и т.п. при игре по модему?

144. jm - 26 Апреля, 2006 - 00:20:36

Мишка гамми На счет "серверного кадра" ничего не слышал. Возможно имеется ввиду просто ответные пакеты сервера ? В любом случае в моем понимании идеальная модель клиент-сервер это когда клиент выступает только в роли терминала (то есть только и делает, что шлет клавиатурный ввод) а сервер отправляет ему состояние мира. А вот на практике идеала не будет по вполне понятным причинам. Если интересно можно их обсудить. Если коротко - все равно многое выносится на сторону клиента просто потому, что иначе обеспечить приемлемой игры просто не возможно (при этом потенциально открывается дорога читерам ) Вцелом fps никак не связан с сетевым обменом. Хотя, кто знает что взбредет очередному девелоперу в голову. Я лично не вижу связи. Другое дело, что если мы говорим о сетевой игре в игровом мире игрок появляется реже. Например в q2 если не ошибаюсь частота обмена с сервером для диалап соединении составляла 10 раз в секунду. Это и есть количество появлений игрока в игре в секунду времени. Вобщем сетевой обмен это несколько другая опера Есть очень неплохая статья (глава из книжки Майка Абраша rambling in realtime inside quake). В книге описанно как id того времени делало quake. А в этой конкретной главе рассказывается о сетевом объмене в quake. Кроме того, что quake первым в таком масштабе использовал честное 3д и полигональную графику они одни из первых тогда использовали модель клиент-сервер в 3д шутере. Вобщем не смотря на возраст читать всё равно интересно. (Отредактировано автором: 26 Апреля, 2006 - 00:23:02)

145. Denister - 26 Апреля, 2006 - 16:20:40

Когда у меня блад на четверке (486ДХ2) тормозил, то часто бывало что только и слышно, как зомбари топорами машут - а кадр - не прорисовывается. В результате - очнулся - гипс! То есть когда тормоза прошли - уже не совсем живой лежишь Это-то и натолктуло меня на мысль, что игра старается выжать максимум, а рефреш не поспевает за ним. Код не изучал, но там стопудово есть какой то фреймскип в угоду работы "внутриигрового времени" - течения событий. Что я всем этим сказать-то хотел, а, короче внутриигровое время не всегда привязывают жестко к фреймам, как раз наоборот, появится-ли фрейм на экране, зависит от анализа "стоитне стоит" - ударение на "o" А в предидущем посте я имел ввиду не "циклы задержки", а задержки в основном цикле. Ну в силу практики программерства под реальный режим процессора вся игра делалась как: repeat PlayerMove(); EnemyMove(); DisplayVideoBuffer(); delay := CalcDelay(); (->*считает частоту своего появления и пытается свести его к константе. вот и все.*) Pause(delay); until (end_flag = true); ясен пень - устарело это все для современных игр,- но и на моем АМД 3700+ работает как на той 486ДХ2

146. jm - 27 Апреля, 2006 - 00:05:18

Идею понял (или скорее всего не совсем), только реальной выгоды не вижу. Добавлять в код лишнюю логику только для того, чтобы получить те же самые тормоза но в профиль ? Тогда уж делать фреймскип без задержки. Да и вообще зачем fps сводить к константе ? Какая от этого выгода ? Не понимаю. Что значит фреймскип в угоду событий в игре ? Смотри. У любого объекта есть его скорость перемещения, скорость разворота. Между кадрами замеряем дельту. При перемещении или повороте умножаем эту дельту на скорость. Всё. Зачем тут нужен фреймскип ? У меня ни на одной игре билдовской не было описанной тобой ситуации. А вот банальные "тормоза" были. Может у тебя были какие то сбои с vesa ? А почему идут такие акценты на счет реального режима ? Чем принципиально защищенный режим в непривелигированном кольце отличается от реального режима ? Ну да, адресация (которую программист на языках высокого уровня скорее всего и "не увидит"), ну да привелегированные инструкции (тут (в прот моде) всё через api да драйвера системы делается) и... И все. Код тот же самый в сущности То есть описанный тобой выше код вполне можно принимать как современный. Да и вообще доказуху в студию Исходники билда то есть.

147. Denister - 29 Апреля, 2006 - 08:07:02

Ладна, уболтал А акценты в сторону прот моде - в основном из за потоков (threads). Приведенный код для одного потока. Современные игропрограммеры наверно как то используют многопоточность - я не знаю...

148. jm - 29 Апреля, 2006 - 14:18:19

Да нет, я не настаиваю Мне правда интересно. Понятие фреймскипа я где-то встречал, но вот в упор не помню его применения. Что до многопоточности... В играх я не уверен что его используют достаточно активно - синхронизация потоков серьезная штука. Максимум мышу в отдельный поток вынесут И то частенько встречается обработка мыши в текущем потоке, что порождает те самые тормоза еще и при снятии ввода при низких фреймрейтах. Возьмём последние игры, например oblivion который использует openmp (на сколько я знаю это некая библиотека облегчающая разарботку многопоточных приложений, сам не сталкивался - только по описаниям) по умолчанию распаралеливание отключено в ini файле или используется по минимуму. В quake4 отлаженная поддержка многопроцессорных систем появилась только с патча 1.2 (или какой он там ? вобщем последний на текущий момент). Причем обещают не кислый прирост - до 70%. Вобщем то я думаю, что эра многопоточных игр только-только наступает. Dual core процессоры для обывателя появились только в прошлом году. А там глядишь появятся и quad core Технологический предел уже близок Из интенсивого переходим на экстенсивный путь развития

149. Denister - 29 Апреля, 2006 - 17:50:51

Да и раньше путь интенсивным не назовешь...- частота*частота*частота. С фреймскипом я познакомился когда подсел на эмуляцию. Приятно иметь на винте сотню другую игр детства Во многих эмулях есть фреймскип. Если его отключать - то на слабых тачках возникают банальные тормоза... зато без пропусков "квантов игрового действа". И наоборот - включаешь - и тормоза сразу исчезают - подумаешь стал видеть 43 реальных кадра вместо 64 - эмуль "в уме" просчитывает игру полностью а на экран - промежуточные состояния (определенные кадры опускаются). Кстати там есть и опция снятия ограничений времени выполнения. Как мне кажется - это и есть отключение моих банальные задержек циклов. Снимаем галочку и на мощьном компе игра начинает лететь как ракета... ЗЫ: че то небольшой офтоп получился.... ну да ладно - все равно про механику движков...

Powered by ExBB 1.9.1 Original Style v1.5a2 created by Daemon.XP