Форум программистов
 
Контакты: о проблемах с регистрацией, почтой и по другим вопросам пишите сюда - alarforum@yandex.ru, проверяйте папку спам! Обязательно пройдите активизацию e-mail.

Вернуться   Форум программистов > разработка игр, графический дизайн и моделирование > Gamedev - cоздание игр: Unity, OpenGL, DirectX
Регистрация

Восстановить пароль
Повторная активизация e-mail

Ответ
 
Опции темы
Старый 10.10.2010, 21:50   #1
ZotaC
Форумчанин
 
Аватар для ZotaC
 
Регистрация: 25.06.2009
Сообщений: 158
Репутация: 20
По умолчанию Скорость рисования и остальная скорость

Здравствуйте. Вот у меня возник такой вопрос по поводу организации рисования и остальных рассчетов в игре. Как можно догадаться, все это дело происходит в таймере, в одном и том же и рисование, и все остальные рассчеты. И происходило так до того момента, пока я не прочитал то сообщение в соседней теме:

Цитата:
Сообщение от Ulex Посмотреть сообщение
Вообще при таком построении программы у вас логика игрового процесса получается завязана на графику.
И тут мне пришла мысль, возможно, и не связанная никак с тем сообщением, а, возможно и связанная. Что, если рисование и остальные рассчеты держать в одном тамере - неправильно? Ведь, насколько я знаю, стандартный таймер ждет выполнения всех операций, и только после этого переходит на следующий шаг. То есть, если у вас установлен интервал в 10 мс, и он не успевает за это время нарисовать всю графику на экране, то он рисует ее за 20, 30, 40... мс, и, тем самым, оттягивает выполнение всех дальнейших действий.

При таком методе на более слабых компьютерах игра будет замедляться, но работать она, как мне кажется, будет безо всяких графических рывков. Но вот замедление очень плохо может сказаться на сетевой игре, где это может вызвать некоторые проблемы с синхронизацией. Впрочем, с сетевой игрой я еще мало знаком.

Другой же метод - раскидать графику и остальные рассчеты по разным таймерам, и тогда на более слабых компьютерах, как мне кажется, будут заметны рывки, но вот скорость игры замедляться не будет. Что же делать и как правильно оформлять это дело?

Другой вопрос состоит и в том, как просчитывать перемещения и остальные характеристики врагов и прочих объектов? Просчитывать ли их в цикле, последовательно, друг за другом или же каким-то образом организовать несколько потоков в игре, которые параллельно просчитывали бы каждый свой массив? Сказывается ли это на оптимизации игры и если да, то сильно ли или же нет?

Последний же вопрос заключается в следующем: какова норма FPS (кадров в секунду) для 2D-игры, написанной на OpenGL? Основные характеристики компьютера: 512 mb видеокарты, 2048 mb оперативной памяти и двухъядерный процессор со скоростью ~1900 Mhz в каждом ядре.
ZotaC вне форума   Ответить с цитированием
Старый 10.10.2010, 23:30   #2
Juffin
Форумчянин
Форумчанин
 
Аватар для Juffin
 
Регистрация: 05.04.2009
Адрес: Ехо
Сообщений: 446
Репутация: 128

icq: 624983587
skype: viktorrulev
По умолчанию

Например, в фреймворке Asphyre, которым я пользуюсь, отрисовка и обработка кадров разделены на две процедуры - ProcessEvent и RenderEvent. Частота повторения первых регулируется, а вторых - нет (только ограничение ФПС), т.е. торможения из-за торможения отрисовки нет. Как это организовать самому - без понятия
__________________
Nobody expects Spanish Inquisition!
Juffin вне форума   Ответить с цитированием
Старый 11.10.2010, 09:39   #3
Alex Cones
Trust no one.
Профессионал
 
Аватар для Alex Cones
 
Регистрация: 07.04.2009
Адрес: In the middle of nowhere.
Сообщений: 6,529
Репутация: 1440
По умолчанию

Цитата:
Другой вопрос состоит и в том, как просчитывать перемещения и остальные характеристики врагов и прочих объектов? Просчитывать ли их в цикле, последовательно, друг за другом или же каким-то образом организовать несколько потоков в игре, которые параллельно просчитывали бы каждый свой массив? Сказывается ли это на оптимизации игры и если да, то сильно ли или же нет?
<1% всего времени такта.

Сможете причаститься к прямому выводу графики (через HDC и пр.) - забудете о тормозах отрисовки. Изучил этот вопрос на практике.

P.S. В журнал отправил статью о работе с графикой на низком уровне с удобной собственной надстройкой. Выйдет - прочтите обязательно.
__________________
SQUARY PROJECT - НАБОР БЕСПЛАТНЫХ ПРОГРАММ ДЛЯ РАБОЧЕГО СТОЛА.
МОЙ БЛОГ
GRAY FUR FRAMEWORK - УДОБНАЯ И БЫСТРАЯ РАЗРАБОТКА WINAPI ПРИЛОЖЕНИЙ
Alex Cones вне форума   Ответить с цитированием
Старый 11.10.2010, 15:56   #4
Selestis
Участник клуба
 
Аватар для Selestis
 
Регистрация: 21.01.2009
Адрес: Самара
Сообщений: 719
Репутация: 268
По умолчанию

Проблема отпадёт при организации высисления промежутка времени между предыдущим и текущим срабатыванием. Получаете коэффициент (в мс, скажем) и умножаете его на ваши перемещения и т.д. Получите равномерное движение, не зависящее от задержки срабатывания таймера.
__________________
Изобретатель велосипедов
Selestis вне форума   Ответить с цитированием
Старый 11.10.2010, 16:34   #5
Beermonza
Инженер ИС
Профессионал
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
Репутация: 746
По умолчанию

В On-Line игре дела обстоят проще. Вся динамическая математическая модель игрового мира расположена на сервере, а в клиентской части, собственно, модель игрового момента и подготовка/отрисовка готового кадра по данным пакета сервера.

Однопользовательская игра содержит в себе обе модели, но так как следить за множеством пользователей и хранить для них динамические параметры не приходится, то, как заметил Alex Cones, это мизерное время, ..."жрет" ресурс именно подготовка и вывод графических данных. Вы смело можете организовать цикл с последовательной обработкой объектов и в самом конце тела таймера вызвать процедуру вывода графических данных на экран - рукописную процедуру, в которой обрабатываются объекты, выполняется сбор графических кадров, определяется расположение на плоскости, подготавливаются слои, и в финале - вывод на экран готового игрового кадра. Достаточно 30 кадров в секунду для отличного восприятия происходящего.

Цитата:
Сообщение от ZotaC
При таком методе на более слабых компьютерах игра будет замедляться, но работать она, как мне кажется, будет безо всяких графических рывков. Но вот замедление очень плохо может сказаться на сетевой игре, где это может вызвать некоторые проблемы с синхронизацией. Впрочем, с сетевой игрой я еще мало знаком.
В сетевой игре организация сервера уже отсекает одну модель от другой, о чем упомянул чуть выше. В однопользовательской, замедление игрового цикла вместе с графикой приветствуется, так вы не сможете ничего пропустить, иначе могут произойти события, которые, скажем, серьезно повлияют на вашего персонажа, а вы и не увидите того, что случилось, пока были временные проблемы с выводом графики.
__________________
Руководитель проекта MMO 2D RPG

Последний раз редактировалось Beermonza; 11.10.2010 в 16:37.
Beermonza вне форума   Ответить с цитированием
Старый 12.10.2010, 00:09   #6
Ulex
Непрофессионал
Профессионал
 
Аватар для Ulex
 
Регистрация: 01.01.2008
Адрес: город Н-ск.
Сообщений: 1,413
Репутация: 1100
По умолчанию

Цитата:
В однопользовательской, замедление игрового цикла вместе с графикой приветствуется, так вы не сможете ничего пропустить, иначе могут произойти события, которые, скажем, серьезно повлияют на вашего персонажа, а вы и не увидите того, что случилось, пока были временные проблемы с выводом графики.
Почему это оно должно приветствоваться, это неправильно. Представьте какой-нибудь шутер (ну например леталка стрелялка). И например у меня слабый компьютер. Т.е. разработчик с таким подходом заранее лишает меня полноценного продукта (вместо игры я получаю какой-то даунский релиз). В таких играх даже бонус обычно есть специальный - замедление. В данной схеме он вообще смысл теряет. Тогда уж более честно будет просто заявить рекомендуемые системные требования, а если графика начала на слабом компьютере тормозить, то как говорится, мы вас предупреждали.

Цитата:
Сообщение от Alex Cones
Сможете причаститься к прямому выводу графики (через HDC и пр.) - забудете о тормозах отрисовки. Изучил этот вопрос на практике.
Это заблуждение, связанное с мощностью современных систем. Я не так давно очень сильно расстроился, попробовав позапускать кое какие свои GDI поделки на третьем целерончике с медленной памятью. Так вот программка с разрешением 800*580 и таймером на 20 мс завесила его на 100% ну и сама конечно стала тупить ужасно. А в этом компьютере стоит видео GeForce 5200 и игры построенные по технологии DX и OGL работают на ура (в пределах разумного, конечно).
__________________
И чем больше я узнавал людей, тем больше мне нравились компьютеры.
------------------------------------
Страничка с моими программками http://ulex-masm.ru
Ulex вне форума   Ответить с цитированием
Старый 12.10.2010, 08:16   #7
Alex Cones
Trust no one.
Профессионал
 
Аватар для Alex Cones
 
Регистрация: 07.04.2009
Адрес: In the middle of nowhere.
Сообщений: 6,529
Репутация: 1440
По умолчанию

Цитата:
Так вот программка с разрешением 800*580 и таймером на 20 мс завесила его на 100% ну и сама конечно стала тупить ужасно.
Интересно, почему моя прожка в полноэкранном режиме 800 * 600 с таким же таймером и кучей геометрии с постоянной новой отрисовкой не тупит?
__________________
SQUARY PROJECT - НАБОР БЕСПЛАТНЫХ ПРОГРАММ ДЛЯ РАБОЧЕГО СТОЛА.
МОЙ БЛОГ
GRAY FUR FRAMEWORK - УДОБНАЯ И БЫСТРАЯ РАЗРАБОТКА WINAPI ПРИЛОЖЕНИЙ
Alex Cones вне форума   Ответить с цитированием
Старый 12.10.2010, 17:08   #8
JTG
я получил эту роль
Профессионал
 
Аватар для JTG
 
Регистрация: 25.05.2007
Адрес: тут темно и с потолка капает
Сообщений: 3,695
Репутация: 2224

icq: III 37373860
По умолчанию

21 век на дворе, какие 800х600. Без аппаратного ускорения никуда, но само по себе оно, кстати, не панацея.

Цитата:
Просчитывать ли их в цикле, последовательно, друг за другом или же каким-то образом организовать несколько потоков в игре, которые параллельно просчитывали бы каждый свой массив? Сказывается ли это на оптимизации игры и если да, то сильно ли или же нет?
Кто-то пишет RTS, где по экрану ползают 50000 юнитов? Не забивайте голову, проблемы нужно решать по мере их поступления. В отдельном потоке имеет смысл грузить большие ресурсы.

Цитата:
Например, в фреймворке Asphyre, которым я пользуюсь, отрисовка и обработка кадров разделены на две процедуры - ProcessEvent и RenderEvent. Частота повторения первых регулируется, а вторых - нет (только ограничение ФПС), т.е. торможения из-за торможения отрисовки нет. Как это организовать самому - без понятия
Таймер в Asphyre вообще выносит мне мозг. Там обработчик onIdle заменяется вот такой штукой, которая дёргает "быстрый" onTimer для вывода графики с максимально возможной скоростью (или ограниченной max FPS) и "медленный" onProcess для расчётов со скоростью постоянной.

Код:

procedure TAsphyreTimer.AppIdle(Sender: TObject; var Done: Boolean);
var
 WaitAmount: Integer;
 SampleMax : Integer;
begin
 Done:= False;
                
 LatencyFP:= RetreiveLatency(); //получить количество попугаев с момента прошлого вызова (через QueryPerformanceCounter или GetTickCount)

 // если таймер отключён, задерживаем выполнение на 5 мс (чтоб не грузить проц слишком быстрым следующим вызовом) и выходим
 if (not FEnabled) then
  begin
   SleepEx(5, True);
   Exit;
  end;

 // если прошло слишком мало времени с момента прошлого вызова - ждём (FPS limit)
 if (LatencyFP < MinLatency) then
  begin
   WaitAmount:= (MinLatency - LatencyFP) div FixedHigh;
   SleepEx(WaitAmount, True);
  end else WaitAmount:= 0;

 // вычисляем дельту для onProcess, на основании этого значения будет решено подождать ли ещё или наоборот уже должно было быть несколько вызовов
 DeltaFP:= (Int64(LatencyFP) * FixedHigh) div SpeedLatcy;
 // учитываем ситуацию, если вывод завис намертво и пропущено слишком много вызовов onProcess
 if (DeltaFP > DeltaLimit) then DeltaFP:= DeltaLimit;

...

 // если вызов onProcess был, то задаём новое значение дельты
 if (Processed) then
  begin
   Inc(FixedDelta, DeltaFP);
   Processed:= False;
  end;

 // дёргаем OnTimer
 if (Assigned(FOnTimer)) then FOnTimer(Self);
end;

...

procedure TAsphyreTimer.Process();
var
 i, Amount: Integer;
begin
 Processed:= True; //отчитываемся перед onTimer

 Amount:= FixedDelta div FixedHigh;  //с момента прошлого вызова прошло мало времени,                                                  
 if (Amount < 1) then Exit;           //пропускаем ход  для поддержания заданной частоты

 if (Assigned(FOnProcess)) then //с момента прошлого вызова прошло нужное количество времени - дёргаем onProcess. 
  for i:= 1 to Amount do //Прошло больше, чем нужно (графика тормознула?) - догоняем пропущенные вызовы
   FOnProcess(Self);

 FixedDelta:= FixedDelta and (FixedHigh - 1);
end;

Обработчики работают последовательно, но за счёт того, что onTimer вызывается гораздо чаще, создаётся иллюзия 2 таймеров, onProcess что-то вроде прерывания. Преимущество перед 2 реальными таймерами в том, что так проще синхронизировать вывод с расчётами - если вывод затормозит, то onProcess ускоренно "догонит" пропущенные вызовы. Подобным способом синхронизируется звук с видео в плеерах: приоритет отдаётся звуку и в случае тормозов видео "ускоренно догоняет его" - лучше дёрганное изображение с нормальным звуком, чем плавное, но с голосом Чипа и Дейла

Ну это всё лирика, короче говоря: утверждение, что "торможения из-за торможения отрисовки нет" не совсем верное - оно есть, но как только графика расчехляется, for i:= 1 to Amount do FOnProcess(Self); тут же скармливает все накопившиеся расчёты процессору.

3К-GET
__________________
пыщь

Последний раз редактировалось JTG; 12.10.2010 в 17:43.
JTG вне форума   Ответить с цитированием
Старый 12.10.2010, 21:07   #9
Beermonza
Инженер ИС
Профессионал
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
Репутация: 746
По умолчанию

Цитата:
Сообщение от Ulex Посмотреть сообщение
Цитата:
Сообщение от Beermonza
В однопользовательской, замедление игрового цикла вместе с графикой приветствуется, так вы не сможете ничего пропустить, иначе могут произойти события, которые, скажем, серьезно повлияют на вашего персонажа, а вы и не увидите того, что случилось, пока были временные проблемы с выводом графики.
Почему это оно должно приветствоваться, это неправильно. Представьте какой-нибудь шутер (ну например леталка стрелялка). И например у меня слабый компьютер. Т.е. разработчик с таким подходом заранее лишает меня полноценного продукта (вместо игры я получаю какой-то даунский релиз). В таких играх даже бонус обычно есть специальный - замедление. В данной схеме он вообще смысл теряет. Тогда уж более честно будет просто заявить рекомендуемые системные требования, а если графика начала на слабом компьютере тормозить, то как говорится, мы вас предупреждали.
Погружать в теорию дискретности событий не буду, просто опишу реальный пример. 1998 год, у меня Pentium 100 и Intel'овская видео-карта, какя уже не помню, но факт тот, что играя в NFS III в однопользовательском режиме получаю 0,5 fps, да да! ...при этом умудряюсь уворачиваться от копов, потому, что все происходит как бы в замедленной съемке, ...нужно становиться ленивцем и подстраиваться под такой заторможенный игровой процесс. Далее, приобретаю новый комп Celeron 450 с видео-картой i740, соединяю самораспаянным проводом COM-порты и запускаю NFS III на обоих компах. Что происходит? ...на целероне все идет гладко, а на пне - слайд-шоу, причем, на пне я вижу только дискретные кадры событий и даже иногда не замечаю как на повороте мимо меня проносится авто, управляемого с целерона, ...кроме того я просто не в состоянии рулить на пне, это сплошные "рехтования" кузова, все заборы и препятствия мои короче ...и напротив, на экране целерона я вижу вполне нормальные витеиватые движения авто, управляемого с пня, ...улавливаете? ...я вынужден рулить на пне, а смотреть в монитор целерона, так адекватнее управление. О чем это говорит? ...видео-карта на пне не справляется с обработкой и выводом данных, а процессор исправно обрабатывает и обменивается данными с сервером игры (целероном), ...таким образом достигается синхронизация, ...на целероне не обязаны ждать пока видео-карта там соизволит выдать кадр, это дискретность изображения конкретного пользователя по отношению к общей модели игрового пространства, которым заведует сервер.

Ответьте на вопрос: вы бы играли в такую игру, если бы действия происходили как бы в "реалтайме", а изображение по отношению к нему было дискретным, при том, что игра на одного пользователя? ...вы рискуете из-за видео-карты потерять всякий интерес к играм из-за временных проблем с отрисовкой. Если модель игрового пространства жестко связана с отображением графики, вы на время получите максимум неудобства, но не потеряете контроль. Именно исходя из этого в однопользовательской, замедление игрового цикла вместе с графикой приветствуется, разумеется этого нужно избегать, но это предпочтительнее потери визуального контроля.

Вспоминаем Morrowind, на том же Celeron 450 и видео-карте i740 получал тормоза, когда видел перед собой множество объектов и большие пространства, но никогда не видел слайд-шоу, из фрагментов быстрых действий по которым ориентироваться невозможно, ...таймер изменения модели пространства замедлялся в зависимости от тормозов видео-карты.

В 2D аналогично. Вспоминаем Age Of Empires (первый), ...осада противника большими силами с применением десятка катапульт. В режиме лимита населения наблюдается замедление игрового процесса, но нет никакого дискретного отображения событий, которые в модели игрового пространства происходят в "реалтайме", ...имеет место снова синхронизация и подстройка под возможности видео-карты.

Для закрепления информации, ...математическая модель игрового пространства просчитывается во много раз быстрее чем позволяет построить и показать готовый кадр видео-карта, по той простой причине, что она считается в системе более мощной, чем располагает видео-карта, т.е. в системе CPU + OЗУ, ...вот если бы видео-карта обладала такой вычислительной мощью )

Вот и делайте выводы, однопользовательская игра это одно, сетевая - другое.
__________________
Руководитель проекта MMO 2D RPG

Последний раз редактировалось Beermonza; 12.10.2010 в 21:11.
Beermonza вне форума   Ответить с цитированием
Старый 12.10.2010, 21:46   #10
Ulex
Непрофессионал
Профессионал
 
Аватар для Ulex
 
Регистрация: 01.01.2008
Адрес: город Н-ск.
Сообщений: 1,413
Репутация: 1100
По умолчанию

Цитата:
Сообщение от Alex Cones
Интересно, почему моя прожка в полноэкранном режиме 800 * 600 с таким же таймером и кучей геометрии с постоянной новой отрисовкой не тупит?
Может поэтому.
Цитата:
Сообщение от Alex Cones
Проц - 1.8 Ггц AMD Athlon
Опер - 512 Мб
ХДД - 70 Гб.
Вывод - "привет" из прошлого века.
Вообще я не в курсе как там развивалась линейка AMD, но то что я нашёл по этой информации похоже на ядро Palomino, а это даже рядом не валялось с Celeron_ом 3 (вроде Tualatin - это максимум, что там было).

Цитата:
Intel против AMD: Celeron 1300 versus Duron 1200

Celeron 1300 должен конкурировать с AMD Duron 1200, поскольку обе эти топ-модели нацелены на один и тот же сегмент рынка. Однако Celeron 1300, даже базируясь на ядре Tualatin, работает все-таки слишком медленно. Причина кроется в частоте FSB и частоте памяти, которые ограничены 100 МГц. При таком ограничении все упирается в пропускную способность шины, и производительность начинает слабо зависеть от тактовой частоты процессора. Поэтому Intel может сколь угодно задирать тактовые частоты Celeron, но к ощутимому росту производительности это не приведет. Говоря другими словами, современный процессор устанавливается на устаревшую платформу 100 МГц FSB. У Duron 1200 эффективная тактовая частота FSB в два раза выше - 200 МГц DDR FSB.

Еще один "тормоз" Intel Celeron 1300 заключается в требовании использования обычной SDRAM памяти, которая никак не улучшает результаты производительности. Если бы Celeron работал на 133 МГц FSB и использовал DDR SDRAM, то он бы показал свой потенциал: Однако попытки увеличить частоту FSB продемонстрировали, что выше 120 МГц система становится крайне нестабильной.
Цитата:
Сообщение от Beermonza
Ответьте на вопрос: вы бы играли в такую игру, если бы действия происходили как бы в "реалтайме", а изображение по отношению к нему было дискретным, при том, что игра на одного пользователя?
Нет, но я бы и не купил такую игру, если бы на коробке было написано "системные требования P4 и т.д. и т.п.", а у меня кроме Celeron_a нет ничего. И это было бы правильнее (по крайней мере честнее), чем купить шутер, а сидеть играть в какое то амёбное нечто. Я плачу деньги за игру - за игровой процесс, который подразумевает динамику.
__________________
И чем больше я узнавал людей, тем больше мне нравились компьютеры.
------------------------------------
Страничка с моими программками http://ulex-masm.ru
Ulex вне форума   Ответить с цитированием
Ответ

Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
wi-fi и скорость stenl1 Железо 19 01.06.2010 17:48
Скорость рисования графиков Master07 Общие вопросы C/C++ 3 16.07.2009 21:45
Скорость bakanis Работа с сетью в Delphi 6 05.04.2009 12:39
Скорость скачивания Терминатор Свободное общение 3 30.03.2009 19:03
Скорость проигрывания Bigtyoma Мультимедиа в Delphi 0 30.09.2008 15:57


03:36.


Powered by vBulletin® Version 3.8.8 Beta 2
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.

RusProfile.ru


Справочник российских юридических лиц и организаций.
Проекты отопления, пеллетные котлы, бойлеры, радиаторы
интернет магазин respective.ru