Swing vs Lwjgl

Java 2D
#1

Hello,

I’m fairly new to java game development. All the games I’ve dabbled with so far were in swing. I’m guessing that for a number of reasons, swing isn’t a very good environment for proper game development.

I’ve heard there are problems with rotating images and speed. Also, I suspect that handling resolution will be problematic, as the types of graphics swing can handle don’t scale well. (Please correct me if I’m wrong) One thing I do like about swing is the components. Are these problems bypassed/easier to cope with using the lwjgl?

I’d really like to keep working on games in java, as I have an intermediate grasp on the language itself. The game I’m working on will use simple 2D graphics, and basic animation. Animation is causing me the most trouble at present. Does Lwgjl sound like a good library for me to use? I’d like something with good documentation and maybe some examples (which LWJGL seems to have)

Thanks for your help!

#2

LWJGL has neither UI components nor animation at all. It’s strictly a java API for OpenGL, OpenAL, OpenCL, plus some input libraries for mouse/keyboard/controllers. You’re going to find it an awfully tedious low-level affair for what you’re describing, unless you try something on top of it such as LibGDX (highly recommended around here).

#3

Thanks sproingie. I’ll look LibGDX up!

#4

We need a site bot that instantly replies “LibGDX is the answer” when it finds the words “new”, “library”, “unsure”, “what”, etc.

#5

No need that if it’s still on JGO, I’ll do that.

#6

I have something against high-level libraries. I only started using LWJGL when I went into 3D development. Of course I then realised how efficient it was and now I can develop just as fast as when I used Java2D.

Even then, I only use a tiny fraction of the classes in the library.

The second library I used was Kryonet, because I can’t manage to make a stable network by myself. ;D
Even then I was reluctant, but it turned out that the API features I needed were few and easy to use.

However, I still refuse to use libGDX until I have interest in HTML5 games (which I could make without libGDX) or get an Android phone/tablet.

Why? In the amount of time it could take me to work out how to use something, I could implement it myself without all the other junk.

Libraries are only required for these things:

Input from controls
Output to screen
I/O for other things

Anything else is not worth it.

IMO: only use libraries when
1: You NEED them or
2: They are better where the default java libraries are lacking
3: They have documentation/a wide range of tutorials.

Use LWJGL if possible. Only libGDX/Slick2D if you can’t learn quickly enough.

#7

Most libraries are by definition better where the default library is lacking, otherwise they wouldn’t have much reason to exist. The dirty little secret is that no one else will ever care about how macho you are for reinventing everything from scratch.

#8

Collsion detection libraries do what default libraries don’t but it’s better to make your own physics as it helps you learn. And you don’t get a whole load of methods for working out whether a duodecagon collided with a semisphere etc.

Oh, and output to the screen AND speakers is what I should have put (see my previous post)(I couldn’t be bothered editing)

#9

Highly unlikely, except you need many months to learn libGDX …
There is a big gap quality wise from hacking something together and having a matured software stack to rely upon.
In the world of professional business software no sane mind would first write a new database, OR mapper and web framework before starting to care about the real customers needs.

#10

I was only referring to libGDX, not all libraries.

In the case of libGDX, if I need to use something, it is best if I understand how it works to avoid having mysterious glitches that slow my progress. Once I understand how it works, I should be able to implement it myself, whether I need to look up free-to-use code then type out the parts I need, or whether it is just a matter of maths and complicated drawings.

Example: converting an image to a texture. I googled it, read it, understood what it does, implemented it myself and now I am free from bulky libraries AND I know how to convert images to textures (without destroying/‘seriously editing’ them).

However if I find that using a library is more efficient than reinventing the wheel, I would use the library.

Anyway, who buys a whole car just to get the wheel? (Oh yeah! metaphor)

On topic:

LWJGL: If you understand maths and how to fix errors in the native code
Slick2D: If you want the advantages of LWJGL while still coding like Java2D or if you want to slowly move from Java2D to LWJGL.
LibGDX: If you want to be able to make games for HTML5/Android(/iOS yet?) have lots of time, like reading and asking questions.

#11

hmm…I would say that you can do most basic things in java2D and still keep things fast. (don’t worry too much about rotation as long as you don’t have 2k+ objects rotating.)

LWJGL is not an engine it is JUST bindings to opengl. What you are looking for is what everyone here said, libgdx/slick2D

I am with Heroes a little. I think you should start with trying to write a game engine in LWJGL just so you can begin to understand what higher level engines do under the covers. You do not need to create an other libgdx just get your head around what is going on. After that, libgdx will seem like godsend.

I have never had to fix errors in native code for LWJGL.

You can get going rather quickly with libgdx. Hard part is setting everything up.

PS:
I had looked at how to draw text using opengl, and looked again, and did one of these O.o, then grabbed slick-util and was a happy camper…well for the most part. (do not like have to unbind textures and reset glColor after drawing stuff…think it should be done in the lib but w/e)

#12

Thanks for all the pointers. Had a go with slick 2d today. Spent 90% of the time getting it set up, but made one of the tutorial games in the remaining 10%. Kinda like it.

How would you rate slick vs libgdx?

#13

slick is easier but libgdx is much faster 2-3x. libgdx will also let you do android and html5 which is nice.

#14

Thanks. Will get stuck into slick for a few weeks and take it from there!

#15

[quote]slick is easier but libgdx is much faster 2-3x
[/quote]
This isn’t really true. If you use Slick’s drawEmbedded or vertex array renderer you’ll get comparable speeds with minimal changes to your code. The difference is that the nature of LibGDX’s SpriteBatch encourages users to think about batching and OpenGL concepts (like flushing a batch before changing blend function, and the implication that will have if you plan to use many different blend funcs per frame), whereas newbies using Slick may not think about those things since they are hidden and/or abstracted away.

The main things with Slick vs LibGDX:

  • Slick is buggy, and not likely to be fixed anytime soon
  • Slick is no longer maintained
  • Slick’s setup requires pulling from git; it’s not nearly as easy as LibGDX (especially considering LibGDX’s setup tool)
  • Slick is outdated, and uses old school OpenGL techniques
  • Slick’s library was not well designed. It has a lot of kludgey code that has developed over the years from various sources who clearly have varying levels of experience with API design.
  • Slick’s tools (PackULike, Particle Editor) are buggy and/or limited. LibGDX’s tools are much more complete and still growing.
  • LibGDX is much more flexible and allows you to get down to the nitty gritty OpenGL without everything blowing up.
  • LibGDX has a stronger community of professional and semi-professional game developers, whereas 99% of Slick’s community is still on chapter 1 of Learning Java.
  • LibGDX’s UI is more complete than Slick, and arguably better in some respects than the complexities of TWL
  • LibGDX ports to Android, HTML5, iOS
  • LibGDX supports 3D and its 3D API will only continue to grow in the future
  • LibGDX’s API often uses JNI for increased performance, e.g. Pixmap rendering, image decoding, Matrix math, etc.
  • and many countless other benefits of LibGDX…

Here is the real question: Are you too lazy to learn simple concepts like matrices, orthographic projection and what a framebuffer is? Then go with Slick2D. Do you want a stable and solid game development platform with a booming community? Then go with LibGDX.

EDIT:

[quote]do not like have to unbind textures and reset glColor after drawing stuff…think it should be done in the lib but w/e
[/quote]
There is no such thing as “unbinding textures” in OpenGL. Texture unit zero can hold data and be bound just like any other. You shouldn’t need to disable texturing, either, unless you plan to render something without textures. Not sure what you’re on about, or what you think Slick should do differently…

#16

Not unbinding I was wrong. Binding 0 so no texture is used. And I am talking about the slick you can download with LWJGL that gives things like Texture loading and text rendering. I am not disabling texturing.

I know that if you do not bind 0 before rendering, it will use the last bound texture. And if you want transparent text or different colored text that you need to call glColor4f(1,1,1,1) after rendering as it will not reset the color back. I may be using an old version that has this but w/e it works.

Last time I checked matrices, orthographic projection, and what a framebuffer is not simple. Maybe for someone such as yourself who has been programming for years, but for those who have been coding for less than a year or who have yet to embark on the linear mathematics train, it is very very complicated. Sure it is not too horribly hard to learn compared to all the other complex things out there, but it is by no means simple.

#17

Not fixing errors in native code, working out what caused them in java and fixing the java code.

It happens when you set up VBOs wrong :-\

#18

Why should Slick reset the color for you? GL is a state-based API – if you set something, expect it to remain that way until you set it again. Having Slick reset colours for every draw call would result in a lot of redundant driver calls.

If you want transparent or coloured text you simply specify a color for the filter parameter to drawString, and the colour will be bound for you. If you don’t specify a colour, white will be bound.

[quote]Last time I checked matrices, orthographic projection, and what a framebuffer is not simple. Maybe for someone such as yourself who has been programming for years, but for those who have been coding for less than a year or who have yet to embark on the linear mathematics train, it is very very complicated. Sure it is not too horribly hard to learn compared to all the other complex things out there, but it is by no means simple.
[/quote]
Agreed that somebody very new to Java may have a harder time with LibGDX than Slick. Ideally somebody will write a LibGDX extension that makes it more “Slick-like” (i.e. aimed at beginners in Java and game dev) and abstracts concepts like blend functions and frame buffers.

#19

There is nothing that force you to use any libgdx high level functionality. Just code against opengl wrapper and you get multiplatform support for free. Only price that you pay is 1-2MB library that you don’t use. This is hardly a problem nowadays. Also tested, robust and efficient utility classes make you much more productive. Just using stuff like textures, mesh, shadersProgram and mathUtils make perfect sense.

Learning curve for libgdx is easier than for lwjgl. not harder for similar usage.