Метр в секунду или измерение величин в играх

Hello, World!
Игры до этого момента не писал, но что-то захотелось написать ...
И похоже, столкнулся с фундаментальной проблемой ...

Пишу сейчас на Perl используя библиотеку OpenGL + GLUT под Windows 7 64. Но это не суть важно.
Не могу понять, как принято измерять в играх время, скорость и расстояния.

Я так понимаю, что время в программе вещь относительная. На выполнение программы влияет множество факторов.

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

Как лучше разбить физику и графику ( процессы\потоки, синхронно\асинхронно). Может быть есть стандарты кодирования или что то ещё. С чего начать?

Если есть код на языках C\C++ c описанием, буду рад.
То есть, проблема в том, что я никак не могу себе представить в будущей программе что такое метр в секунду, так как измерения относительны. И как в самом начале заложишь эти единицы так и поплывешь.

Жду ваших коментов, ребят.

Добавлено через 4 часа 33 минуты
Неужели никто не знает как правильно задать скорость\время?

Почитал статейки, пишут, что нужно скорость перемещения множить на скорость отрисовки кадра.
положение объекта = скорость объекта * среднее время отрисовки кадра

В GLUT есть функции glutTimerFunc и glutIdleFunc ... к какой правильно привязывать функцию рисования сцены?

0

Сообщение от PetyaVasechkin Я так понимаю, что время в программе вещь относительная. На выполнение программы влияет множество факторов. Вообщем, ребят, в голове моей кашка ... кто подскажет, куда копать, чтобы понять как организовать нормальную не сложную заготовку для простенькой игры типа змейки или тетриса? Мне бы хотелось разобраться как можно организовать плавное движение, скажем, шара со скоростью 1 метр в 1 секунду.

Нельзя сделать 1 м/с. Можно сделать 1 ширину экрана за 1 секунду. Или одну высоту. Или одну диагональ. Или некоторую часть ширины, высоты, или диагонали. Или несколько ширин, высот, или диагоналей. Плавность же достигается не воспринимабельностью отдельных шагов, то есть они должны быть достаточно малы по времени.

1

Сообщение от taras atavin Время реально, размеры и расстояния условны. Если ты нарисуешь всех по 6 футов, а друг сделает точно такую же игру с 60-ти футовыми великанами и при этом удесятерит все игровые объекты от травинки до горизонта, то различить на глаз эти игры будет нельзя точно также, как и мы ничего не заметим, если вдруг завтра проснёмся в 1000 раз больше на планете радиусом 6 000 000 км на орбите радиусом 150 000 000 000 км вокруг увеличенного Солнца, так же тысячекратно увеличатся все межатомные расстояния и скорость света. Так что условно прими логическую единицу длины за любую физическую единицу длины на свой вкус и применяй последовательно.

Спасибо, я возьму за основу 1 метр, 1 килограмм и 1 секунду.

0

Сообщение от PetyaVasechkin Я так понимаю, что время в программе вещь относительная.

Нет. Время - это реальное время пользователя.

1

Сообщение от taras atavin Нет. Время - это реальное время пользователя.

Спасибо.

0

Можно единицу принять за метр, миллиметр, дюйм, километр, световой год... За что угодно. А в 2D хоть за пиксел.

Добавлено через 1 минуту
А ещё можно принять её за световую секунду. Или за световую терцию. За световую минуту, за световой час. За что угодно. Время же изначально размерно и надо узнать единицу, в которой его измеряет используемая функция. В зависимости от самой функции это тоже может быть что угодно от суток до микросекунды, но этот выбор заложен в инструмент.

1

Сообщение от taras atavin А в 2D хоть за пиксел.

Во, точно, я забыл, а теперь вспомнил, ... при удалении объекта на определенное расстояние он может выпасть из усеченной пирамиды перспективной проекции, так? И делает он это резко вроде бы. А вот как плавно сделать? Не подскажете?

Добавлено через 3 минуты
Мне интересен сам принцип ... туман войны нужен?))

0

1. Если объект имеет глубину, то сначала пропадёт его дальний слой и постепенно дойдёшь до ближнего.
2. Можно завысить глубину пирамиды отсечения, но на некотором расстоянии от камеры разместить туманную стену, по мере погружения объекта в которую его изображение будет постепенно размываться.
3. Можно завысить глубину горизонта, но смоделировать кривизну Земли.

1

Сообщение от taras atavin 1. Если объект имеет глубину, то сначала пропадёт его дальний слой и постепенно дойдёшь до ближнего. 2. Можно завысить глубину пирамиды отсечения, но на некотором расстоянии от камеры разместить туманную стену, по мере погружения объекта в которую его изображение будет постепенно размываться. 3. Можно завысить глубину горизонта, но смоделировать кривизну Земли.

Благодарю!

Я сейчас с таймерами окончательно разберусь и перейду к отрисовке объектов, которые лежат внутри этой пирамидки проекции. Чтобы лишнее не рисовать.

0

Сообщение от taras atavin Время реально, размеры и расстояния условны.

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

1

Сообщение от PetyaVasechkin Мне интересен сам принцип ... туман войны нужен?))

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

1

Сообщение от vxg нет. все реально) ибо если сделать так что в OpenGL камера будет настроена таким образом что "глаз" будет на том расстоянии на котором сидит пользователь от экрана, а размер плоскости на которую осуществляется проекция будет размером с экран, то все угловые размеры (и даже линейные если пользователь поднесет предмет к себе на расстояние как от глаза до экрана) будут правлильными

Это было бы круто ))))
Но всё же, про время, таймер самый реальный это генератор прямоугольных импульсов, насколько я понимаю )
Интересно, к нему ли обращаются функции через ОС и драйвер?? Или может быть программное окружение влияет на этот таймер который я вызываю (glutTimerFunc)

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

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

Да, в 2D сценах туман только по краям не иследованной местности ))) Ещё с WarCraft помню )))

Добавлено через 3 минуты
vxg, srand(time(0)); хотел спросить ... это в main для чего? я не смог найти переменную куда результат заносится. Или может эта функция не явно что то устанавливает?

0

Сообщение от vxg нет. все реально) ибо если сделать так что в OpenGL камера будет настроена таким образом что "глаз" будет на том расстоянии на котором сидит пользователь от экрана, а размер плоскости на которую осуществляется проекция будет размером с экран, то все угловые размеры (и даже линейные если пользователь поднесет предмет к себе на расстояние как от глаза до экрана) будут правлильными

Нет. Угловые размеры - угловые и есть, с линейными они непосредственно не соотносимы. Кроме того, оптический зум и цифровое растяжение квада полностью эквивалентны, разница лишь в разрешении результата, но если цифрозумить не заранее отснятые пикселы, то и этой разницы нет. Не имеет значения, чему в игре соответствует расстояние до экрана. На самом деле это полметра? Эйси. А в игре по гигантвилю это будет 5 метров. Но в итоге пользователь увидит всё именно так, как должен видеть собственное окружение персонаж. При условии, что истинные угловые размеры окна равны угловым размерам поля зрения персонажа. А фокус в том, что персонаж видит не в размеры метрах, а в отношении к собственному росту. И настоящий человек тоже. Просто если он знаком с единицей "метр", то знает и как соотнести эту единицу с собственным ростом и уже отсюда человек может прикинуть на глаз расстояние в метрах. Но если чисто фантастически допустить вселение в тело персонажа, то в навыке соотношение роста к метру сохранится, а на самом деле изменится и как бы все предметы вокруг вдруг станут меньше, а дома великанов нормальными. Но нормальны они на взгляд великана же.

1

Сообщение от taras atavin Нет. Угловые размеры - угловые и есть, с линейными они непосредственно не соотносимы. Кроме того, оптический зум и цифровое растяжение квада полностью эквивалентны, разница лишь в разрешении результата, но если цифрозумить не заранее отснятые пикселы, то и этой разницы нет. Не имеет значения, чему в игре соответствует расстояние до экрана. На самом деле это полметра? Эйси. А в игре по гигантвилю это будет 5 метров. Но в итоге пользователь увидит всё именно так, как должен видеть собственное окружение персонаж. При условии, что истинные угловые размеры окна равны угловым размерам поля зрения персонажа. А фокус в том, что персонаж видит не в размеры метрах, а в отношении к собственному росту. И настоящий человек тоже. Просто если он знаком с единицей "метр", то знает и как соотнести эту единицу с собственным ростом и уже отсюда человек может прикинуть на глаз расстояние в метрах. Но если чисто фантастически допустить вселение в тело персонажа, то в навыке соотношение роста к метру сохранится, а на самом деле изменится и как бы все предметы вокруг вдруг станут меньше, а дома великанов нормальными. Но нормальны они на взгляд великана же.

Дело в психике?)

0

Но это 5 единиц, а не метров. А может быть это 1,64 единицы-фута? Великан не видит себя таковым, какие бы единицы ни были выбраны, даже не существующие, последовательное их применение ко всем объектам гарантирует правильность картинки.

Добавлено через 27 секунд

Сообщение от PetyaVasechkin Дело в психике?)

Дело в относительности по Маху.

1

PetyaVasechkin, тогда хочу посоветовать вам покопаться в потрохах любого движка, + обложиться литрой по этому случаю, пускай даже на с++ НО принципы то в основном те же. (от языка лишь незначительное быстродействие зависит это не столь важно. тк на компах нашего времени будет мало заметна разница в 0.1с и 0.01 с скорость будет зависеть от правильности кода собсно) и еще в гугле можно много полезного найти на эту тему, хотя бы в плане общего развития

1

Сообщение от taras atavin Но это 5 единиц, а не метров. А может быть это 1,64 единицы-фута? Великан не видит себя таковым, какие бы единицы ни были выбраны, даже не существующие, последовательное их применение ко всем объектам гарантирует правильность картинки.

Вообщем, я понял. Главное хвост и числа фибоначчи!

Главное пропорция и точка опоры. Если я всё правильно понял.

0

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

0

Сообщение от taras atavin Нет. Угловые размеры - угловые и есть, с линейными они непосредственно не соотносимы. Кроме того, оптический зум и цифровое растяжение квада полностью эквивалентны, разница лишь в разрешении результата, но если цифрозумить не заранее отснятые пикселы, то и этой разницы нет. Не имеет значения, чему в игре соответствует расстояние до экрана. На самом деле это полметра? Эйси. А в игре по гигантвилю это будет 5 метров. Но в итоге пользователь увидит всё именно так, как должен видеть собственное окружение персонаж. При условии, что истинные угловые размеры окна равны угловым размерам поля зрения персонажа. А фокус в том, что персонаж видит не в размеры метрах, а в отношении к собственному росту. И настоящий человек тоже. Просто если он знаком с единицей "метр", то знает и как соотнести эту единицу с собственным ростом и уже отсюда человек может прикинуть на глаз расстояние в метрах. Но если чисто фантастически допустить вселение в тело персонажа, то в навыке соотношение роста к метру сохранится, а на самом деле изменится и как бы все предметы вокруг вдруг станут меньше, а дома великанов нормальными. Но нормальны они на взгляд великана же.

я не спорю с тем что условные единицы используемые в OpenGL могут как угодно соотносится с реальными единицами и вообще быть никак с ними не связаны. однако можно выбрать их такими что 1 уе = 1 м и все будет выглядеть так как в реальности и при этом являться реальностью)

1

Сообщение от Крюгер тогда хочу посоветовать вам покопаться в потрохах любого движка, + обложиться литрой по этому случаю, пускай даже на с++ НО принципы то в основном те же. (от языка лишь незначительное быстродействие зависит это не столь важно. тк на компах нашего времени будет мало заметна разница в 0.1с и 0.01 с скорость будет зависеть от правильности кода собсно) и еще в гугле можно много полезного найти на эту тему, хотя бы в плане общего развития

Спасибо, я обязательно копну движок. Просто я сейчас читаю книжку по OpenGL потихоньку. И у меня их несколько штук. Я параллельно изучаю OpenGL и языки. До звука ещё не добрался.
Думаю, просто, освоить азы так сказать трёхмерной графики и попробовать написать что то простенькое использующее сеть\БД\анимацию\текстурирование\освещен ие\звук\простую физику (столкновение) ну и так далее. Хочу оценить время\силы.

Добавлено через 2 минуты
Нужно вообще посмотреть, чего я могу, а чего нет

0

Сообщение от PetyaVasechkin время\силы

-> бесконечности)

1