Масштабирование игры Java Tile

Я создаю 2D-игру на основе плитки сверху вниз на Java. Естественно, вы можете панорамировать и увеличивать игру, в настоящее время увеличивая масштаб на 10 различных уровнях, где каждая плитка имеет размер от 10x10 до 100x100 пикселей соответственно. В настоящее время тайлы для каждого уровня масштабирования хранятся в отдельных листах спрайтов, считываются при запуске программы и сохраняются в массиве буферизованных изображений. Я уверен, что это не лучший способ сделать это.

Я ищу любые советы по повышению эффективности в долгосрочной перспективе, было бы лучше иметь только плитки 100x100 и динамически масштабировать их в java; как-то использовать векторную графику в java (я уверен, что как, но я уверен, что google мог бы мне помочь) или что?

Большое спасибо!


person Daniel Messias    schedule 06.04.2012    source источник
comment
Здесь подойдет svgs (векторная графика).   -  person Jon Egeland    schedule 06.04.2012
comment
Буду разбираться, спасибо за наводку :)   -  person Daniel Messias    schedule 06.04.2012


Ответы (2)


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

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

Я предлагаю вам следующие чтения:

http://docs.oracle.com/javase/tutorial/2d/advanced/transforming.html http://www.javalobby.org/java/forums/t19387.html

person Fermin Silva    schedule 06.04.2012
comment
При использовании аффинного преобразования для основного графического компонента компьютер визуализирует или, по крайней мере, вычисляет то, что находится за пределами видимой области. Очевидно, что если игра должна просчитывать все обычные вещи, но для всей карты, а не только для видимой области, это потребовало бы гораздо большей загрузки ЦП. Спасибо! - person Daniel Messias; 06.04.2012
comment
@DanielMessias, если плитка находится за пределами поля зрения, она не будет отображаться, но все равно будет тратить ресурсы. Для отбраковки вам все равно нужно оптимизировать код. Как правило, у вас есть прямоугольник, содержащий усеченный конус камеры, который вам нужно изменить с помощью перемещений и масштабирования. Затем вы применяете отбраковку на основе этого и отправляете на рендеринг только то, что видно. Вы не хотите выполнять матричные вычисления для невидимых объектов! - person Fermin Silva; 06.04.2012
comment
Этот ответ, возможно, только что изменил мою жизнь. - person helsont; 25.07.2013

Если вы выполняете фиксированное масштабирование (т. е. каждый уровень масштабирования представляет собой фиксированное расстояние от камеры), в отличие от плавного масштабирования (игрок может увеличивать масштаб в 3,3, 7,5 раза, а не только в 1, 2, 3 и т. ), то очень расточительно пытаться решить эту проблему, просто применив масштабирование. Это заманчиво, потому что это наименее сложный подход, и его легко понять с точки зрения реализации, но это означает, что при максимальном уменьшении масштаба вы будете отображать область, которая в 10 раз больше по оси X и в 10 раз больше по оси X. направление Y, поэтому площадь мира, которую вы должны визуализировать, будет в 100 раз больше, чем при максимальном увеличении. Я также сомневаюсь, что вам понравится, как ваши текстуры сжимаются аппаратным обеспечением при уменьшении масштаба. Компьютерная графика не то же самое, что оптика - субпиксельный рендеринг и другие вещи, которые происходят в компьютерной графике, не сделают ваши текстуры очень хорошими, если вы передадите эту задачу программному / аппаратному обеспечению.

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

Кроме того, 10 уровней масштабирования? Вы уверены, что вам действительно нужно 10 уровней масштабирования? Масштаб обычно используется в 2D-играх, чтобы вы могли выполнять различные действия с разным уровнем детализации, потому что определенный уровень масштабирования особенно хорошо подходит для определенного набора действий. Я не помню ни одной 2D-игры, в которой для этого требовалось бы 10 уровней масштабирования. 3-5 — это максимум, что я когда-либо видел, и я никогда не чувствовал, что этого недостаточно. Также кажется, что создание изображений на каждом уровне масштабирования для 10 уровней масштабирования требует большого количества художественных работ.

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

person jefflunt    schedule 06.04.2012
comment
Я вижу вашу точку зрения. Я согласен с вашей точкой зрения о том, что 10 уровней масштабирования - это слишком много. Это всего лишь небольшой забавный проект в свободное время, поэтому производительность не важна, но я полностью согласен, что вам не понадобится больше 5. Я относительно новичок в Java, поэтому использование преобразования изображения в упрощенной игре, вероятно, проще для меня. меня, но я полностью понимаю вашу точку зрения, спасибо за вклад :) - person Daniel Messias; 06.04.2012
comment
Это не то и не другое. Вы можете комбинировать плавное масштабирование (с преобразованиями) и различные уровни детализации. Возьмем, к примеру, средневековую Total War II. При уменьшении масштаба 3D-модели теряют качество текстур. А если уменьшить еще больше, ОНИ СТАНУТ 2D СПРАЙТАМИ!! - person Fermin Silva; 06.04.2012
comment
Кроме того, максимальное увеличение может не совпадать с обычным увеличением. Таким образом, отображение в 10 раз большей области экрана может быть не таким огромным, но нормальным. Все зависит от того, сколько объектов вы рисуете, и от качества текстур (плотность пикселей) у них. - person Fermin Silva; 06.04.2012
comment
Я уверен, что многие детали реализации будут зависеть от игры. И я согласен, это не то и не другое — это сочетание динамики и уровня детализации в случае плавного зума. - person jefflunt; 06.04.2012