Mazzi, ключевая фраза

Rickert, вот вы спорите о том, сколько должно быть кадров в секунду, а мой алгоритм не зависит от этого. Мяч будет одинаково выглядеть хоть при частоте 100 fps хоть при частоте 10 fps. Именно для этого я считаю количество тактов пройденных с момента последнего рендера, после чего на основе этой цифры изменяется ускорение. В этом случае не нужно даже думать сколько кадров выбирать. Это называется не зависеть от системы. А звуковая  и графическая карта тут вообще не причем, так как в расчетах скорости участия не принимают и работают паралельно.

Добавлено через 2 минуты и 40 секунд


Блин, а я что делаю? 
вот этот кусок кода не о чем не говорит?



Добавлено через 4 минуты и 54 секунды

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

Bitter, ну считайте - считайте, пока на грабли не наступите - не поймёте.

Rickert, ну объяснили бы сразу в чем грабли-то, а то получается как "я такой классный знаю, а вот вам не скажу бугага"

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

Bitter, помоему не так

а так

должно быть...

cardinal, ну я просто до этого написал: 



то есть дельту уже учел.

Bitter, в случае, что g = const

integral a dt = v
integral v dt = s

соответственно перемножать нужно два раза...

Вы разработками в области параллельных вычислений занимались? Вот у вас есть два потока, которые считают два значения и складывают их в область памяти. Каждый работает независимо от другого разное количество секунд. И есть третий поток, который должен сложить результаты работы первых двух. Вопрос: как организовать работу? Как узнать что первые два потока завершили свои вычисления и в обусловленных областях памяти лежат конечные значения?
Когда вы считаете такты ЦП - вы следите за выполнением только одного потока, забывая, что есть ещё поток GPU и остальные вычисления, которые в конечном итоге, дают результирующую картинку. Т.е. чтобы верно отсчитывать время вы должны отталкиваться от реально отображённых кадров, а не от тактов ЦП.
Конечно, возможно что при небольшой нагрузке вы можете учитывать только такты ЦП и иметь на руках достоверную картинку. Но стоит вашему проекту вырасти до шейдеров и большого количества объёма данных - как начнутся непонятные артефакты в просчёте физики, на отлов которых у вас, скорее всего, уйдёт очень много времени.

Rickert, кстати, а где тут проблема? Bitter считает дельту с последнего рассчета и учитывает ее. Всё равно у тебя один поток для всего получается, а там где драйвер скидывает command buffer в видео карту, основной поток будет ждать. Т.е. нет смысла заморачиваться на параллелизм в данном случае. Это как из пушки по воробьям.

зачем мне считать такты, кадры! у меня тут идет просто вычиления значения по оси "y"!
программа готова в ней отображается щарик(мячик), только осталось в бить что делать с координатой и все.
и на данный момент как я писал в пред посте, он просто опускается с ускорением

sSilence, либо Вы задете вопрос не относящийся к теме данного раздела, либо Вы не поняли, что Вам отвечают.

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


именно это вам и объяснили


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

http://forum.vingrad.ru/index.php?showtopi...t&p=1884589

arilou, с пушки попадёшь с большей вероятностью, а точность в физ. расчётах - наше фсё.

Ну если 20 мало, то думаю 30 будет вполне достаточно. А больше для падающего шарика не нужно, скорее всего...