Slick2D 与直 LWJGL
我一直在用 Slick2D 深入研究游戏编程，我开始想知道从长远来看，了解 LWJGL 是否会更有帮助。一方面，Slick2D 快速且简单，但 LWJGL 似乎更具适应性，因为它同时具有 2D 和 3D 功能。对于java中级水平并且想要制作游戏的人来说，立即学习LWJGL是否值得付出额外的努力？
I've been delving into game programming with Slick2D, and I've began to wonder if in the long run, knowing LWJGL would be more helpful. On one hand, Slick2D is fast and simple, but it seems LWJGL is more adaptable in the sense that it has both 2D and 3D capabilities. For someone who is intermediate in java, and wants to make games, would it be worth the additional effort to learn LWJGL right off the bat?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不认为这两者有真正的关系。我的意思是，我知道 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% 都是 Sprites、动画、关键帧输入、寻路和声音。 Slick 已经为你构建了这些东西 - 几乎可以保证你会重新发明轮子，尽管你的意图是好的，但你不会像在 Slick 上工作多年的开发人员那样做得好。 2D 游戏渲染是一个已解决的问题 - 不要浪费你的时间。除非你认真进入渲染引擎（我什至不是在谈论游戏引擎，你花时间研究游戏玩法和机制，而是实际的渲染技术）我们会发现这有点令人沮丧。挫败感不会来自于它是一个太难解决的问题（你当然可以解决它），只是你将花费几个月的时间来构建它，当你完成时，你将已经拥有一些功能子集包含在 Slick 中，但没有显示它的游戏。制作 Slick 的聪明人已经为您解决了 Java 中 2D 游戏引擎的要素 - 利用他们的工作，而不是花费数月时间尝试构建就在您面前的东西。
最后打个比方，20 世纪 90 年代初 PC 游戏的巨大爆炸确实发生在 DirectX 进入市场时。当然，从 Atari、Apple ][、Commodore 等一直以来都有视频游戏，但当 DirectX 出现并让开发人员免于编写自己的游戏时，游戏和技术出现了爆炸式的飞跃。声音和视频驱动程序。这实际上就是开发人员当时编写游戏时必须做的事情 - 为他们希望游戏运行的每个声卡和显卡编写或许可单独的驱动程序。 DirectX 使开发人员有机会不再担心这一点 - 只需担心硬件与某个版本“DirectX 兼容”，并且只能提供最低限度的功能来提供他们所需的性能，仅此而已。
很难解释它有多大 - 但如果您正在使用 Java 开发 2D 游戏 - Slick（或其他游戏工具之一）就是您的 DirectX！
I don't think the two are really related. I mean, I know Slick is built on top of LWGJL, but that's not what I'm getting at here.
Slick exists to take advantage of the hardware graphics and sound acceleration, and to give that power to 2D games with a set of objects and classes that make sense for 2D games (sprites and tilemaps, as opposed to geometric models and 3D coordinate space). That's it - that's its mission, and it's built to be awesome at solving that problem. The fact that Slick is based on LWJGL is simply a matter of LWJGL being a library upon which you could build something like Slick. In the history of people trying to make games in Java, graphics performance had always been a major problem to getting anything of quality out on the market. Slick essentially removes that hurdle for 2D games on the desktop (and hopefully on Android, someday).
When considering Slick vs. LWJGL, it's a "right tool for the right job" sort of thing. If you're building a 2D game in Java, Slick is an awesome way to go. If you're actually building a 3D game (or a game with a top-down 2D sort of view, but you have a requirement to actually render your scenes in 3D), then LWJGL may be your best starting point.
If, however, you're building a 2D game, and you think it's worth your time to build it in LWJGL, 99% of what you're going to build in order to make that work is going to be Sprites, animation, key input, pathfinding, and sound. Slick has already built these things for you - you're pretty much guaranteed to be reinventing the wheel, and as well intentioned as you are, you won't do it as well as the developers who have spent years working on Slick. 2D game rendering is a solved problem - don't waste your time. Unless you're seriously into rendering engines (I'm not even talking about game engines where you spend your time working out game play and mechanics, but actual rendering technology) you're going to find it more than a little frustrating. The frustration won't come from it being too difficult a problem to solve (you can certainly solve it), it's just that you'll spent months building it, and when you're done you'll have some subset of the features already included in Slick, but no game to show for it. The smart people that made Slick already solved the elements of a 2D game engine in Java for you - take advantage of their work and don't spend months trying to build something that's right there in front of you.
To make one final analogy, the huge explosion of gaming on the PC in the early 90's really happened when DirectX hit the market. Sure there were video games around all the way back to the Atari, the Apple ][, the Commodore, etc., but there was an explosion, an absolutely huge jump in games and technology when DirectX came aboard and saved developers from writing their own drivers for sound and video. That's literally what developers had to do back then if they were writing games - write or license individual drivers for each sound and video card that they wanted their game to run on. DirectX gave developers a chance to stop worrying about that - to only worry that hardware was "DirectX compatible" to a certain version, and was minimally powerful to deliver the performance they needed, and that was it.
It's hard to explain just how big this was - but if you're developing 2D games in Java - Slick (or one of the other game tools out there) is your DirectX!
Normalocity 的回答非常好，我只是想说，如果您想真正优化 Slick2D 中的绘图场景，您需要知道 Slick 的标准绘制方法使用 glBegin/glEnd。
对于大量精灵（~10 000），此方法非常慢。为了避免这个问题，您可以在非常大的精灵表上使用drawEmbedded方法，或者使用LWJGL创建您自己的方法。最好是做一个VBO渲染=> http://lwjgl.org/wiki/index.php?title=Using_Vertex_Buffer_Objects_(VBO) 。
Really nice answer from normalocity, I just want to say if you want to really optimize your drawing scene in Slick2D, you need to know than standard draw method of Slick use a glBegin/glEnd.
With a lot of sprite (~10 000), this method is really slow. To avoid this problem you can use drawEmbedded method on a very big sprite-sheet or make your own method with LWJGL. The best is to make a VBO rendering => http://lwjgl.org/wiki/index.php?title=Using_Vertex_Buffer_Objects_(VBO).