Движение объектов

[abyrvalg]

как всетаки правильно реализовать скорость объекта, не зависящую от железа?

[B.V.]

Очень просто: завести константу, относительно которой в цикле отрисовки вычислять время вызовов анимации в зависимости от fps. Меньше fps, чаще вызовы.

[amk]

Смещение равно скорости, умноженной на время. Время, это время прошедшее с отрисовки прошлого кадра.

[Mikle]

Цитата B.V. @ 06.05.16, 13:11

вычислять время вызовов анимации в зависимости от fps

Точнее даже не FPS, а время, прошедшее с предыдущего кадра.
Но я предпочитаю делать по-другому - выполнять физику с фиксированной частотой, не зависящей от FPS видеоадаптера.

Сообщение отредактировано: Mikle - 06.05.16, 14:33

[Славян]

Цитата Mikle @ 06.05.16, 14:32

Но я предпочитаю делать по-другому - выполнять физику с фиксированной частотой, не зависящей от FPS видеоадаптера.

Весьма странное предпочтение, ибо это положение - неустойчиво, на что и намекает автор темы.

[amk]

Цитата Mikle @ 06.05.16, 14:32

Но я предпочитаю делать по-другому - выполнять физику с фиксированной частотой, не зависящей от FPS видеоадаптера.

А если у тебя время обсчёта физики меняется?

[Mikle]

Цитата Славян @ 06.05.16, 15:39

это положение - неустойчиво, на что и намекает автор темы.

Намёков я не прочувствовал. На счёт неустойчивости не понял, ведь я как раз пишу, что пусть графика рисуется как угодно, физику можно считать с фиксированной частотой.

Цитата amk @ 06.05.16, 15:43

А если у тебя время обсчёта физики меняется?

Естественно, время расчёта физики должно быть не более определённого, не более того.
Вот мой главный цикл:

  While Running
    DoEvents
    If RenderEnabled Then
      DoControl
      NowTime = QTime
      While NowTime > OldTime + Quant
        OldTime = OldTime + Quant
        PhysTick
      Wend
      SetCamera
      Render
      FPS = FPS + 1
    Else
      Sleep 20
    End If
  Wend

Quant - это период, с которым расчитывается физика, DoControl - опрос управления, RenderEnabled - значит игра не на паузе, QTime - функция на основе QueryPerformanceCounter, возвращает текущее время.
PhysTick - функция расчёта физики для фиксированного периода, благодаря тому, что он фиксирован, физика сильно упрощается, тем более, что я величину Quant принимаю за единицу.

Сообщение отредактировано: Mikle - 06.05.16, 18:39

[Славян]

Цитата Mikle @ 06.05.16, 18:37

Вот мой главный цикл:

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

Добавлено 06.05.16, 19:17
Да, всё же вот кардинально разные (противоположные подходы):
1.

Цитата Mikle @ 06.05.16, 18:37

он фиксирован, физика сильно упрощается

2.

Цитата Славян @ 06.05.16, 19:04

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

А ещё может произойти, что ЦП будет адски быстрый, 1000 кадр/сек выдаётся, а стрела у вас висит кучу кадров на одном месте, ибо физика считать соизволит только в свои кванты времени. А могли бы для каждого кадра её чуточку двигать, показывая плавность. Эх...

[amk]

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

[Славян]

1.Я привык, что расчётам уделяется намного больше времени, нежели на отрисовку сцены. Хотя сейчас стараются показать такую-то красивость да сякую, так что вполне может оказаться, что показ тоже долог.
2.Физика блестяще распараллеливается, чего не сказать о картинке. Не представляю как отдельно нарисовать дерево с птичками, а потом сие как некое готовое в сцену загнать.
3.Следствием из п.2 является то, что физику можно (нужно?) считать в несколько этапов: капитальные движения (разрушения до́ма, ...), мелкие (полёт стрелы, движение поезда, ...) и т.д. Т.е. если чухаем, что кадров хватает, то можно бы и мелкое подвигать/досчитать, а если уж тяжко кадр делается, то и чёрт с ними, с тонкими смещениями.

[amk]

Цитата Славян @ 06.05.16, 20:16

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

На самом деле графика тоже прекрасно распараллеливается. Более того, она распараллеливается даже лучше, чем физика.
Дерево с птичками можно поделить на дерево и птичек. Считаем положение дерева и птичек, после чего рисем дерево отдельно, каждую птичку отдельно. Дерево не успевает отрисовываться? Делим дерево на ствол и ветви с листьями: Рисуем ствол отдельно, ветки отдельно, листья отдельно. То же можно сделать с птичками: отдельно рисовать тело, лапки, крылья, голову, хвост. Разбивать можно чуть ли не до отдельных треугольников тесселяции. Собственно вершинные шейдеры этим и занимаются. В результате параллелизм такой, что для рисования одного кадра спокойно можно задействовать чуть ли не все процессоры на Земле. Правда каждому из них достанется всего несколько операций.

[Mikle]

Цитата amk @ 07.05.16, 08:09

Разбивать можно чуть ли не до отдельных треугольников тесселяции. Собственно вершинные шейдеры этим и занимаются.

+1, а пиксельные шейдеры далее распараллеливают ещё глубже, вплоть до растеризации отдельных треугольников всеми пиксельными конвейерами одновременно.

[amk]

Цитата Mikle @ 07.05.16, 08:26

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

Ну это уже распараллеливание на уровне отдельных пикселей.
Кстати, действительно, там уже ничто не мешает растеризовать все треугольники одновременно. Даже все пиксели всех треугольников одновременно. Даже, если они перекрываются, и одновременно будет обновляться один и тот же пиксель, z-буфер спокойно выберет тот из вариантов, который соответствует ближней (обычно) точке. Процесс отрисовки до такой степени не распараллеливается только потому, что пропускная способность каналов связи в видеокарте нужна будет совершенно невообразимая.

[abyrvalg]

QueryPerformanceCounter подойдет?
всмысле с ее помощью вычислять разницу между вызовами функции отрисовки, и эту разницу множить на скорость?

Сообщение отредактировано: abyrvalg - 10.05.16, 09:24

[amk]

Да там такая точность не нужна, подойдёт любая функция с подходящим разрешением по времени.

[abyrvalg]

timeGetTime()
GetTickCount()

[abyrvalg]

первая величина кол-во тиков в сек, ничёсе, так много

Прикреплённая картинка

последние два практитски неотличаются

Сообщение отредактировано: abyrvalg - 11.05.16, 10:07