Лучшие проекты таймеров для видеоигр Java2D

Question

Я создаю видеоигру Java2D с одновременным обновлением нескольких спрайтов и искал обратную связь в отношении лучшего способа обработки обновлений с помощью таймеров.

Я искал обратную связь по наилучшему способу управления дизайном таймера, который обновлял местоположение каждого Sprite. В настоящее время, как я это делаю, у меня есть один таймер. Когда он истекает, я обновляю позицию каждого спрайта. Я только обновляю местоположение Sprite на 1 пиксель, чтобы поддерживать плавное движение. Если что-то должно было обновляться медленнее, чем в остальном Sprite, я обновляю его положение, заявляя каждые 3 или 5 раз вызов getImage() (используемый для получения текущего изображения значка спрайта).

Теперь при таком подходе все обновления зависят от основного таймера и типа обновления Sprites относительно друг друга. Поэтому, если бы я хотел ускорить игру, я просто обновляю частоту обновления основного таймера.

Однако я не знаю, является ли это наилучшим подходом. Было бы лучше поставить каждый объект на свой собственный таймер, но это вызовет другие проблемы? Может возникнуть проблема для основного метода paint()?

Был просто поиск обратной связи по хорошей технике проектирования для этого.

Answer 1

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

Это будет означать, что ваш класс Sprite (или что бы то ни было) имеет точки x и y с плавающей запятой, а также скорости с плавающей точкой x и y. Чтобы изменить скорость определенного спрайта, вы измените скорость (которая будет равна пикселям/чертежуUnitsEtc за миллисекунду/наносекунду) и не будет ограничена тем, как быстро вы можете запустить таймер.

Однако я не знаю, является ли это наилучшим подходом. Было бы лучше поставить каждый объект на свой собственный таймер, но это вызовет другие проблемы?

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

Вы также столкнетесь с проблемой того, как вы можете обеспечить постоянный возврат таймера. С отдельными таймерами представьте, что в игре могут быть два спрайта, которые идут рядом друг с другом в игре, которые хотят обновляться с интервалом в 10 мс, но один из них работает в 11 мс из-за отстающего таймера, в конце концов, он будет запускаться в заднюю часть другие, обернуться и испортить ваш уровень дизайна или какой-либо другой игровой механик. Другим является то, что они могут быть двумя Sprites того же типа, но теперь один из них теперь представляет собой анимационный кадр впереди другого, в то время как это не подтвердилось в течение первых нескольких секунд, которые вы их видели. С помощью одного таймера, который обновляет все спрайты, которые работают вместе, вы получите эти последовательные результаты.

Answer 2

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

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

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