【问题标题】:Rendering: To draw-once or to re-draw? Would JOGL + Java2D + Java Swing be cumbersome?渲染:绘制一次还是重新绘制? JOGL + Java2D + Java Swing 会很麻烦吗?
【发布时间】:2014-04-10 03:00:54
【问题描述】:

1) 重新绘制与绘制

有点哲学问题,但是...在不同分辨率下渲染游戏(2d,我了解 OGL 视角如何工作...)的“正确”或“可接受”方式是什么?我应该为我的图像(如 Android APK)包含单独的大小并在一个画布上绘制时单独调整每个对象的大小,还是应该在设置分辨率的绘图画布上绘制,然后将该图像调整到另一个显示画布上?我说的是一般性,但是,如果您需要我具体说明,我正在使用 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 渲染为相对于纵横比的面板大小在摇摆时效率非常低。显然最好立即绘制到面板,同时单独调整每个图像/元素的大小。不是我的第一个假设...

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

【问题讨论】:

  • 更新:我最终从头开始创建了一个 BufferedImage,它是原始分辨率的大小。然后我将该图像绘制到显示器的大小,一次。 B)

标签: java android swing opengl-es jogl


【解决方案1】:

我无法完全回答您的第二个问题,因为我对 JOGL 或 Java2D 没有太多经验,但我看不出它们有任何冲突或麻烦的原因。

对于您的第一个问题,我可以肯定地说这取决于。你的目标受众是什么?您的游戏内存是否密集(是否注意到许多游戏都有高分辨率/低分辨率选项)?这是一款适用于不同屏幕尺寸的游戏吗?如果是这样,您可能希望提供 2-3 个不同的资产“包”,每个都以原始大小(最大的一个)的不同大小进行缩放。绘制图像的数学并没有你想象的那么多。

另外:

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

【讨论】:

  • 感谢您的意见。我的情况需要极高的可移植性,所以是的,更多的资源密集型和更少的内存密集型是有意义的。我总是可以排除特定平台不需要的资源。相机的想法很好......也许我可以将一种 OGL 透视应用于我的 2D 透视(-1 到 1),这样分辨率就不再是问题了。很好的答案。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-07-15
  • 1970-01-01
  • 1970-01-01
  • 2014-12-16
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多