Choosing a Library

Engines, Libraries and Tools
#1

Hello everybody,

I’m new here to the java-gaming forums but not a complete beginner to game programming in Java. I’m looking for which library or wrapper to use for my next game.

First I’ll give a little background that may be unnecessary but should provide a decent overview of my programming background and capabilities. Last year I took AP Computer Science which covered fairly basic Java programming and some OOP concepts. It was almost all text-based stuff and I don’t believe it got into Swing, AWT, and any graphical interface programming. After I finished the class I decided to start some researching into graphics programming in Java because I’ve always enjoyed gaming and thought it might be fun to program some games. I ended up using AWT and Swing to create a simple Space Invaders type game with some upgrades. However, I used a JPanel to draw on and didn’t know anything about frame rates so the game speed was dependent on the CPU and had no hardware acceleration.

From there I looked for better and more reliable ways to make games and discovered Slick2D. I rewrote and much improved that first game using Slick and learned a lot more about game programming through the experience. Now I would like to learn more about my options and decide what to use to write my next game,

I plan on having a game somewhere between boxhead and Gun Bros. I haven’t really brainstormed the whole design and plan on doing that over the next few days before getting started programming it. From some personal research I know that there are a few options available to me. I heard that I could use AWT because apparently Canvas has hardware acceleration (?). I could stay with Slick, use LWJGL, use JOGL, or LibGDX to name a few.

LWJGL seems like a pretty good choice because most of the alternatives seem to be based on it. However, this also means that programming in straight LWJGL would be more difficult or more complex, but most likely offers the best performance, correct?

I don’t know much about JOGL and am doing some research on it right now.

I really don’t know a lot about LibGDX either other than it having easy Android compatibility which is a plus because I might like to do an Android port.

Based on what I need and know can you guys offer any suggestions to help me out? I appreciate your time and comments. Thanks,

David

#2

Hey David and welcome to JGO!

Seems like this post should be helpful in explaining the whole situation.

If you want to stick with Java2D (AWT), read this post.

However, since you seem to have enough experience, I say you should quit using AWT and switch to OpenGL.

If you have any questions, feel free to ask! I tried explaining things as thorough as possible in that first post, so you should read it carefully. :stuck_out_tongue:

Good luck! :slight_smile:

#3

To answer your questions:

  • Dont use AWT/Java2D/Swing. They are not really suited for game development. If you’re looking for hardware acceleration you should just stick to LWJGL/JOGL.
  • LWJGL and JOGL are simple wrappers around OpenGL; it’s “apples and oranges” when compared to LibGDX/Slick. If you have never used OpenGL, you will probably find it extremely challenging even to produce a simple 2D sprite. And chances are whatever techniques you employ will already exist in libraries like LibGDX or Slick; i.e. your pure OpenGL game may not necessarily be any more performant than a LibGDX/Slick game.
  • Porting to Android shouldn’t be an afterthought. Making a game well supported on Android means re-thinking your art assets, game/UI layout, input, shaders, etc. You should know before developing your game whether or not you plan to support Android; and then include Android in the development process every step of the way.

I’d say use LibGDX if you need an Android/HTML5 port; or if you feel comfortable with concepts like matrices, shaders, blending, and “modern OpenGL.” If those things frighten you, stick with Slick.

You can still use low-level OpenGL within LibGDX/Slick (and I’d say it’s even encouraged, if you know what you’re doing). These libraries only exist to minimize “re-inventing the wheel” – no need to write a game loop, or a texture decoder, or what have you. IMO you should only resort to pure OpenGL if (a) you can reinvent the wheel better, or (b) you want to learn how the wheel was made. :slight_smile:

#4

Thanks for the replies. That post was indeed helpful :slight_smile:

Dave - I’m fine using and transforming matrices and enjoy the mathematics. I’ll probably major in CS and minor in Math when I get to college so the math shouldn’t be an issue. I really haven’t dealt with shaders and blending before and have stuck to simple images, never really drawing things from scratch yet. That last point of yours is certainly an interesting one. I do like learning what goes on behind the scenes and think it would be helpful in debugging. Also, I don’t plan on sticking with Java for game programming forever. I have nothing against Java but may want to get a job doing game programming in the future and Java really doesn’t look that good professionally. However, I believe Java game programming can certainly give me fundamentals that are fairly easily applied in other languages.

Would JOGL or LWJGL, in your opinion, transfer better to OpenGL in C++ or is there little difference?

As for Android, I watched the LibGDX intro video and obviously from there to Android is very simple. How difficult would it be to go from something like LWJGL to Android compatibility?

#5

LWJGL would help the most when transferring to C/C++ due to its static design.

LWJGL allows to access OpenGL through Java on PCs.
LibGDX uses LWJGL for its desktop component and OpenGL ES for Android so there shouldn’t be any difference in API OpenGL-wise.

#6

I use LWJGL; it’s very actively maintained and has a much wider user base (irc #lwjgl) than JOGL. It’s also got a much cleaner API in my opinion. A number of tools (e.g. TWL, Slick-Util) support LWJGL but not JOGL. Both are simple wrappers around OpenGL, though; so the concepts (vertex buffer objects, texture states, shaders, etc) will all be the same, and will easily be applicable to OpenGL in C++ or any other language.

[quote]How difficult would it be to go from something like LWJGL to Android compatibility?
[/quote]
If you’re talking about the low-level stuff, OpenGL programming for desktop is pretty different from OpenGL ES programming for Android. In theory, if you program OpenGL using modern techniques, and don’t rely on anything that isn’t in OpenGL ES, you could port the code very easily. But most OpenGL tutorials do not give you OpenGL ES compatible code (i.e. in OpenGL ES 2.0 there is no glOrtho, glPushMatrix, glTexCoordPointer, immediate mode, or anything else that you will tend to encounter in code examples). And there are other things to consider, where OpenGL ES doesn’t support certain desktop features. I’d suggest trying to learn modern OpenGL before you start thinking about OpenGL ES, though.

You can sit around and talk about this forever… Just download LWJGL 2.8.4 and start coding. :slight_smile:

#7

Thanks again guys. One last thing on LWJGL. Would you recommend getting an OpenGL book or just reading tutorials and test projects from LWJGL?

#8

I fully recommend OpenGL SuperBible v5! :slight_smile:

#9

haha

JOGL is a much more professional developed lib then lwjgl, lwjgl on the other hand has some bad design in it. Which can be a bad example for beginners. A problem which both libs have is that both don’t really distinguish between a raw OpenGL wrapper for Java and other utility functionality.

#10

Both libraries are amateur developed, in that nobody is paying for them to be developed.

That said, one of those libraries has gone on to make a few huge fortunes for them’s that’s used it in the gaming space.

Cas :slight_smile:

#11

Who dictates what design is “good” or “bad”? LWJGL design is “fitting” because it tries to imitate C-like OpenGL code as much as possible…which is good considering all OpenGL tutorials are in C…

#12

There are a few bits in it which could be nicer. They’ll get fixed.

Cas :slight_smile:

#13

Would you recommend starting with the old fixed-function pipeline or not?

#14

If you’re not the type of person that just wants to learn everything (like me :(), then skip the fixed function pipeline and get to learning OpenGL Core!

#15

I don’t think I’m really understanding the difference between fixed function pipeline and programmable pipeline. I was reading this Red Book before I asked about fixed function and believe it uses the fixed function pipeline, right? Are shaders the difference between fixed and programmable? Why are they so different?

According to the red book, a quad parallelogram can be drawn like this:

GL11.glBegin(GL11.GL_QUADS);
	GL11.glVertex2f(400, 400);
	GL11.glVertex2f(350, 350);
	GL11.glVertex2f(300, 350);
	GL11.glVertex2f(350, 400);
GL11.glEnd();

Is that not how it’s done with the programmable pipeline?

What sources would be best for the programmable pipeline? I came across this site that says it uses programmability and avoids fixed function implementation. Is there a newer Red Book somewhere that I missed or should I buy the SuperBible 5th edition?

Could you explain that or point me to something that can? Thanks.

#16

That code sample is the fixed function pipeline. The programmable pipeline is completely different.

I recommend you read the intro of SuperBible 4th Edition to understand the difference between fixed and core. Then read the 5th Edition to learn about Core OpenGL.