DXTimer

← →
breakmaster © (2004-08-01 22:58) [0]

Люди, никто не знает, почему когда я размещаю второй ДХТаймер, первый прекращает работу?

← →
NikeOLD (2004-08-02 11:37) [1]

Потому что, если мне память не изменяет, то в этой лобуде под названием DelphiX таймер использует событие OnIdle объекта Application.
В связи с этим наличие второго таймера или перекрытие OnIdle приведет к потере функциональности первого таймера.

← →
Ландграф Павел © (2004-08-02 12:56) [2]

breakmaster>используй один Дх, другие простые...

← →
NikeOLD (2004-08-02 13:02) [3]

> Ландграф Павел © (02.08.04 12:56) [2]

во-во.
А зачем вообще тебе несколько таймеров? Уменьши интервал и обходись одним.

← →
breakmaster © (2004-08-02 17:41) [4]

это, блин, сложно...
тем более, что у меня в 1-ом таймере интервал 0.
как быть с остальными? Заводить переменную типа longint для отсчета fps?

← →
Ландграф Павел © (2004-08-02 20:29) [5]

breakmaster>? что-то я проблемы не вижу... я лично всегда одним обходился... а нафиг тада таймер, если интервал 0??? используй delphix, никакие переменные не придется заводить... в таймере у тебя должно быть только перерисовка экрана и опрос клавиатуры... что ты туда еще напихал-то?=)

← →
breakmaster © (2004-08-02 22:12) [6]

начнем...
если у delphiX таймера интервал 0 - значит событие ontimer работает постоянно.
так вот у меня куча таймеров:
1 с интервалом 0 ответственен за клавиатуру(getkeyboardstate)
2 с интервалом 250 ответственен за монстров.
3 с инт. 125 ответственен за летающие предметы (fireball)
4 с инт 3500 ответственен за систему охраны(появится в новой версии)
и еще там до фига всякой фигни...
монстры, скажешь, не в таймере должны двигаться?

← →
NikeOLD (2004-08-02 22:33) [7]

> breakmaster © (02.08.04 22:12) [6]

Я с DelphiX особо не возился, но если правильно помню, то в методе DoMove (или как он там называется) как раз и передается значение таймера. Просто сравнивайте это значение с монстрами (250) или что там еще и двигайте монстров только в этом случае.
Неужели Вы думаете, что в профессиональных играх куча таймеров? Один и только один.
А если заводить таймеры на каждый спрайт, то ресурсов Win98 просто не хватит.

Событие OnTimer объекта TDXTimer - это событие OnIdle объекта Application, с установленным в False значением Done. Читаем MSDN: если Done установлен в False, то это приводит к тому, что событие возникает так часто насколько это возможно в системе, что вызывает повышенную нагрузку на процессор. Приложения не должны это допускать за исключением .... За исключением игр.

Посмотри подробнее примеры. Их даже на этом сайтеполно (см. http://DelphiGFX.mastak.ru).

← →
Ландграф Павел © (2004-08-03 10:58) [8]

breakmaster>монстры, скажешь, не в таймере должны двигаться?
скажу - нет! NikeOLD приавельно сказал, есть такая стучка как inherited DoMove(movecount), вот ее и используй... у меня например выстрел происходит после первой перезарядки, и потом еще время на прицеливание... дык чтож мне три таймера на один выстрел цеплять что-ль?!

← →
NailMan © (2004-08-03 11:45) [9]

А у меня вообще нет ни одного таймера на события(акромя WinAPI таймера на обновление строки FPS) типа передвижений - синхро у каждого объекта решают все проблемы и геморрои.

Думаю применить их к DelphiX также просто как и к любому API.

---
WBR, NailMan aka 2:5020/3337.13

← →
cyborg © (2004-08-03 11:51) [10]

А у меня вообще не синхро, не шминхро :), каждый игровой кадр увеличивается переменная, по ней все объекты пляшут.

← →
NailMan © (2004-08-03 12:38) [11]

cyborg ©
А с какой частотой обновляется эта переменная. Каков по продолжительности промежуток между "игровыми кадрами"? ;-)

---
WBR, NailMan aka 2:5020/3337.13

← →
Micah'GF © (2004-08-03 15:23) [12]

[11] NailMan
расскажи как нужно синхронизировать объекты когда много потоков? без таймера?

← →
cyborg © (2004-08-03 16:14) [13]

> [11] NailMan © (03.08.04 12:38)

Мои игры играют 33 кадра в секунду, каждый кадр счётчик увеличивается, соответственно каждую секунду на 33, только в танчиках старых 25 помоему сделано. И делаю я так из расчёта на сетевую игру и синхронизацию между клиентами, посылаешь например что, например, на сотом кадре нужно создать бомбу, мессага приходит, если указанный кадр ещё не дошёл, то пока её не создаём, как кадр подошёл, создаём её, время жизни бомбы, например 330 (=10 секунд), соответственно бомба должны взорваться на 430-ом кадре у обоих клиентов. А с таймерами и твоими синхронизерами, которые работают с системным временем компьютера, по сети игру не сделаешь.

Сейчас скажут, что "раз такой умный, то почему игру по сети не сделал?" :), отвечаю - потому, что это не простая задача ;).

← →
NailMan © (2004-08-04 10:32) [14]

cyborg ©
Ну если у тебя фиксед-FPS тогда понятно.

Только вот Quake`s, Doom`s, UnrealTournament`s, сдаланы по тому же принципу как и у меня(даже несколько проще), и тем не менее сетевая игра у них имеется. ;-D
Ну и как это объяснишь?

Micah"GF ©
http://delphimaster.net/view/9-1089528478/

с шестого поста

Мой подход работает всегда и независимо от производительности компа. Синхронизация естественно изменений состояний объектов и производительности компьютера.

Только вот зачем много потоков в игре?

---
WBR, NailMan aka 2:5020/3337.13

← →
cyborg © (2004-08-04 10:36) [15]

> cyborg ©
> Ну если у тебя фиксед-FPS тогда понятно.
>
> Только вот Quake`s, Doom`s, UnrealTournament`s, сдаланы
> по тому же принципу как и у меня(даже несколько проще),
> и тем не менее сетевая игра у них имеется. ;-D
> Ну и как это объяснишь?

Дык не обязательно же к рендеренным кадрам приписывать, у тебя всё равно логика игры больше какого-то кол-ва в секунду не идёт, ну например 50 игровых циклов в секунду в которой перемещаются объекты, создаются и удаляются, прсчитываются коллизии. Вот в таком цикле и увеличивай счётчик игровых кадров. А все вышепривидённые игры весьма глючат по сети, когда играешь по модему.

← →
breakmaster © (2004-08-04 14:28) [16]

А где можно почитать про синхронизацию или хотя бы надыбать определение?

← →
NailMan © (2004-08-04 18:16) [17]

Дык точного определения не существует, есть только трактовки.
Суть синхронизации:
сделать обновления состояния объекта(анимация, движения и т.д.) с четко заданной частотой на любой машине(любой производительностью).

по нижеозначенной ссылке:
http://delphimaster.net/view/9-1089528478/

я приводил реализацию своего варианта.

Суть моего метода: для каждого объекта есть набор параметров, которые отвечают за масштабирование его будущих изменений. Коэффициент масштабирования вычисляется как отношение фактически пройденого времени с момента предыдущего изменения состояния к теоретическому времени(ВремяЗадержки или интервал его персонального "таймера").

Моменты времени я беру из HighPerfomance счетчика процессора(не путать с командой asm-а RDTSC).

Скажем объект изменят состояние в момент A(будем считать это значением счетчика) и считаем это началом отсчета(в первый раз задаем время при создании объекта).
Мы говорим объекту что он будет изменять свое состояние каждые 20 милисекунд(50 раз в секунду), а потому задаем ему время задержки(в dx-таймере это интервал таймера) в 20мс(естественно переведенных в разрешение HP-системного таймера. см. в примере как это реализуется).

Далее в игровом цикле(OnIndle) мы делаем проверку для нашего объекта:
Если ТекущееВремя - А >= ВремяЗадержки тогда пора обновлять состояние объекта. Тоесть другими словами если прошедшее время с момента предыдущего изменения больше или равно задержке, то надо делать изменение. Естественно в конце операций изменения состояний(скажем обсчет колизий для объекта, анимация, перемещение и т.д.) мы должны задать ему новое время А - присваиваем переменной значение счетчика из системы, так как расчеты могут быть и не мгоновенными, и при следующем изменении будет очень небольшое масштабирование).

А самый главный параметр - коэффициент масштабирования процессов вычисляется по формуле:
КоэффМасшт = (ТекущееВремя - А) / ВремяЗадержки

Если время прошедшее с последнего изменения превысило время задержки, то коэф будет больше единицы иначе будет единицей(очень близко к ней).

Применять его очень просто. Скажем изменение координаты объекта каждый раз идет на какую-то определенную величину(скорость), значит чтобы у нас на дохлой тачке объект изменил координату на такое-же расстоние как и на быстрой тачке нам надо прибавить к координате значение скорости умноженное на полученный коэффициент. Т.е.
X := X + Vel * КоэфМасшт;

Визуально на дохлой тачке(если совсем все плохо) это будет как бы большое изменение координаты объектом или как бы "рывок". На нормальной тачке все будет плавно.

---
WBR, NailMan aka 2:5020/3337.13

← →
breakmaster © (2004-08-04 19:57) [18]

надо же... сделал для себя открытие, что gettickcount использовать низзя...(а мне тока уже посоветовали)
только я не врублюсь что значит масштабирование(

← →
NailMan © (2004-08-05 09:27) [19]

breakmaster ©
Я же написал - это увеличение изменения состояния объекта(скажем координаты) пропорционально производительности компьютера.
На медленных машинах будет увеличенный прирост координаты за "тик", а на быстрых он будет нормальным.

---
WBR, NailMan aka 2:5020/3337.13

← →
pavel_pavel © (2004-08-05 10:19) [20]

Cool

← →
breakmaster © (2004-08-07 12:14) [21]

кстати, про QueryPerformanceCounter в хелпе ничего нет...

← →
breakmaster © (2004-08-09 16:50) [22]

Люди, а если в таймер Очень много всякой фигни запихать, он тормозить будет?

← →
NikeOLD (2004-08-09 17:15) [23]

Может так получиться, что код будет выполнятся все время до следующего "тика" таймера и дольше, что приведет к зацикливанию.

← →
NailMan © (2004-08-09 17:49) [24]

Если в моем варианте, то вряд-ли у тебя все объекты будут одновременно что-то трабатывать. В теории они(их кванты времени) будут равномерно размазаны по секунде, что даст равномерный ФПС. Если что-то сильно нагрузит проц, то все остальные отмасштабируются по этому лагу.

Если же юзать какой-то фиксированный таймер где все будут изменяь состояния, то тормозить будет и еще как(в зависимости от эффективности алгоритмов изменения состояний).

---
WBR, NailMan aka 2:5020/3337.13

nailman-у
Кстати когда у меня был нормальный таймер, у меня монстры на всех компьютерах нормально двигались. Может в синхронизации нет нужды вообще?

а как называется главная процедура, которая постоянно выполняется?

или по-другому игровой цикл.
Судя по-всему вопрос ламерский, но мне нужен на него ответ

> [27] breakmaster © (12.09.04 14:26)

Никак она не называется, как назовёшь, так и будет называться ;)
Например Procedure SuperPuperGiperCycle; :)

ладно, тогда спросим по-другому.
Что нужно сделать, чтобы процедура работала постоянно?

> Что нужно сделать, чтобы процедура работала постоянно?

Зациклить :)

Repeat
Until условие

или

While условие do
begin
end;

Выход из цикла - поменять условие или выполнить Break;

> breakmaster © (07.08.04 12:14) [21]
> кстати, про QueryPerformanceCounter в хелпе ничего нет...

The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter, if one exists.

BOOL QueryPerformanceCounter(

LARGE_INTEGER *lpPerformanceCount // address of current counter value
);

Parameters

lpPerformanceCount

Points to a variable that the function sets, in counts, to the current performance-counter value. If the installed hardware does not support a high-resolution performance counter, this parameter can be to zero.

Return Values

If the installed hardware supports a high-resolution performance counter, the return value is nonzero.
If the installed hardware does not support a high-resolution performance counter, the return value is zero.

See Also

QueryPerformanceFrequency

Repeat
Until условие

или

While условие do
begin
end;
- ЭТО где писать??

Ведь есть наверно специальные названия процедур, которые выполняются постоянно. Там, например, procedure TGameEngine

> [32] breakmaster © (13.09.04 21:37)
>- ЭТО где писать??

Ты программист или где? :)
Откуда я знаю где в твоей программе это писать? Где тобой задумано, там и пиши!

Если не пользоваться долбанными формами(VCL) для создания игры и прочих OnIdle, то все шикарно реализуется простым Repeat Until с каким-либо условием выхода(скажем переменная состояния приняла значение выхода).

У меня так вообще нет такого понятия как игровой цикл. У меня их сколько угодно. Если селектор процессов, в котором выбирается режим работы программы, а каждый "игровой процесс" есть процедура со своим уникальным игроывм циклом. Скажем когда игрок находится в режиме кокпита(основной вид изнутри корабля), то цикл имеет свой вид. Когда игрок смотрит на свой корабль снаружи, то игровой цикл совершенно другой, так как в этом виде рендерятся другие элементы сцены, а какие-то нет.

---
WBR, NailMan aka 2:5020/3337.13

все понятно.
Я просто думал что есть такие зарезервированные процедуры, которые сами по себе выполняются постоянно.

DXTimer Найти похожие ветки