java - 渲染 : To draw-once or to re-draw? JOGL + Java2D + Java Swing 会很麻烦吗？

Question

1) 重新绘制与绘制

这是一个哲学问题，但是...在不同分辨率下渲染游戏的“正确”或“可接受”的方式是什么(2d，我理解 OGL 视角如何工作...)？我应该为我的图像(如 Android APK)添加单独的尺寸，并在一个 Canvas 上绘制时单独调整每个对象的大小，还是应该在设置分辨率的绘图 Canvas 上绘制，然后将该图像的大小调整到另一个显示 Canvas 上？我说的是一般性的，但是，如果您需要我具体说明，我将使用 Java 来构建引擎。

可预见的好处/问题:

#1) Resize at Draw
    + No additional drawing step
    + Sweet resolution
    - Possible math/physics/placement issues
    - Tons of math each step for scale
    - Lots of resources

#2) Resize at Render
    + No additional math; one step
    + One set of images; smaller res. package
    + One set canvas size (easier to do math/phys./placement)
    - Additional drawing step
    - Poor resolution =(

考虑到好处与问题的数量，#2 似乎是显而易见的选择，但是......是吗？有调整 2D 游戏大小的标准方法吗？

2) JOGL + Java2D + Java Swing

同时使用JOGL、Java2D、Java Swing会不会很麻烦？在 JOGL 中进行 2D 或布局值得吗？为什么或为什么不？

编辑:使用 BufferedImage 绘制并将 BufferedImage 渲染为面板大小(相对于长宽比)在 swing 中效率极低。显然，最好立即绘制到面板，同时单独调整每个图像/元素的大小。这不是我的第一个假设...

编辑2:愚蠢的我......只需在任何其他操作之前将图形上下文缩放并转换为调整后的分辨率的大小。性能提升真是太棒了。这是问题的正确答案。绘制一次，进行缩放/平移。 B)

Answer 1

我无法完全回答你的第二个问题，因为我对 JOGL 或 Java2D 没有太多经验，但我不认为它们有任何冲突或麻烦的理由。

对于你的第一个问题，我可以肯定地说这要看情况。您的目标受众是什么？您的游戏是否占用大量内存(是否注意到许多游戏都有高分辨率/低分辨率选项)？这是一款适用于截然不同的屏幕尺寸的游戏吗？如果是这样，您可能需要提供 2-3 个不同的资源“包”，每个包以原始尺寸(最大的尺寸)进行缩放。绘制图像的数学并不像您想象的那么复杂。

此外:

如果您以正确的方式构建游戏，您根本不需要做太多数学计算。如果您有某种 Camera 类来负责查看 GameWorld，那么您只需缩放相机的图像，而不是单独缩放每个图像。