Slick2D vs Straight 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?

回答1:

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!

回答2:

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).