Slick2D vs Straight LWJGL

我不认为这两者真的有关系。我的意思是，我知道Slick是建立在LWGJL之上的，但这不是我在这里得到的。

Slick的存在是为了利用硬件图形和声音加速，并通过一组对2D游戏有意义的对象和类（精灵和瓷砖贴图，而不是几何模型和3D坐标空间）为2D游戏提供这种能力。就是这样 - 这是它的使命，它旨在解决这个问题。Slick基于LWJGL的事实只是LWJGL是一个库的问题，你可以在其上构建像Slick这样的东西。在人们试图用Java制作游戏的历史上，图形性能一直是将任何高质量产品推向市场的主要问题。Slick基本上消除了桌面上2D游戏的障碍（希望有一天能在Android上）。

在考虑Slick与LWJGL时，它是“正确工作的正确工具”之类的东西。如果你正在用Java构建2D游戏，Slick是一个很棒的方法。如果您实际上正在构建3D游戏（或具有自上而下的2D视图的游戏，但您需要实际以3D渲染场景），那么LWJGL可能是您最好的起点。

但是，如果您正在构建一款2D游戏，并且您认为值得花时间在LWJGL中构建它，那么为了完成这项工作，您要构建的99%将是精灵，动画，键输入，寻路和声音。Slick已经为你构建了这些东西 - 你几乎可以保证会重新发明轮子，而且尽管你是出于好意，但你不会像那些花了数年时间在Slick上工作的开发人员那样做得那么好。2D游戏渲染是一个已解决的问题 - 不要浪费你的时间。除非你认真对待渲染引擎（我甚至不是在谈论游戏引擎，你花时间研究游戏玩法和机制，而是实际的渲染技术），否则你会发现它不仅仅是有点令人沮丧。挫折感不会来自它太难解决的问题（你当然可以解决它），只是你会花几个月的时间构建它，当你完成时，你会有一些已经包含在Slick中的功能子集，但没有游戏可以展示它。制作Slick的聪明人已经为您解决了Java中2D游戏引擎的元素 - 利用他们的工作，不要花费数月时间试图构建就在您面前的东西。

最后打个比方，90年代初PC上游戏的巨大爆炸式增长确实发生在DirectX进入市场时。当然，一直到Atari，Apple][，Commodore等，周围都有视频游戏，但是当DirectX加入并拯救开发人员编写自己的声音和视频驱动程序时，游戏和技术绝对是巨大的飞跃。这就是开发人员当时在编写游戏时必须做的事情 - 为他们希望游戏运行的每个声卡和视频卡编写或许可单独的驱动程序。DirectX让开发人员有机会不再担心这一点 - 只担心硬件与某个版本“DirectX兼容”，并且对于提供他们需要的性能具有最低限度的强大功能，仅此而已。

很难解释这有多大 - 但如果你正在用Java开发2D游戏 - Slick（或其他游戏工具之一）就是你的DirectX！

来自正常性的非常好的答案，我只想说，如果你想真正优化你的Slick2D中的绘图场景，你需要知道比Slick的标准绘制方法使用glBegin/glEnd。

使用大量的子画面（~10 000），这种方法真的很慢。要避免此问题，您可以在非常大的子画面表上使用 drawEmbedded 方法，或者使用 LWJGL 创建自己的方法。最好的方法是使VBO渲染=>http://lwjgl.org/wiki/index.php?title=Using_Vertex_Buffer_Objects_（VBO）。