No input handling. 
But even so, I’d say it proves my point – Java2D is less beginner friendly.
You should post that to the “game loops” thread since the code examples there are lacking (yours is nice and compact, self-contained, uses proper game loop, and uses buffer strategy).
Need input handling? That’s only a couple lines or so. Either way, that also proves my point that all the boiler plate is necessary to learn the basic game loop and organization of code. Otherwise, they end up with a super compact set that only does things, while they don’t themselves learn. If you want results without caring about code, go with Slick2D fine, but I care about learning my way to the results.
Anyway, input handling: http://www.java-gaming.org/?action=pastebin&id=106
[quote](Java2D) is necessary to learn the basic game loop and organization of code
[/quote]
I'll reiterate what I said before...
- You don't need to know how to write a game loop in order to make a game. There are thousands of Unity, Flash, etc. game developers who have probably never written their own game loops from scratch -- and maybe they will never need to.
- Slick reduces this type of boilerplate and "low level" coding for the sake of [i]simplicity[/i] and ease of use. Along the same vein, Java2D's Graphics allow you to use matrix transformations (rotate/scale/translate) through a high-level interface. You can "scale" the view without understanding exactly how the matrix math works, [i]and[/i] without having to write your own matrix math boilerplate.
- Many beginners will copy-paste code without fully understanding what it does. This is especially true on their first couple projects -- you just want something up and running. You have time to learn about matrix math, game loops, VBOs, etc. later in life. :)
Lower level knowledge is always good to have, but it's not necessarily the best place for a beginner to start, nor is it needed to make good games.
[quote]they end up with a super compact set that only does things
[/quote]
Did you mean "super compact code that [i][b]does exactly the same thing[/b][/i]"? ;D
EDIT: for some reason JGO keeps wrapping my post in 'code' tags.. odd.
This might blow your mind: you can write your own game loop in Slick. :o
I agree that re-inventing the wheel can sometimes help you learn better practices, but most beginners (and experts alike) are not looking to re-invent the wheel. That’s why high level classes exist: JFrame, ArrayList, Graphics2D, BufferStrategy, java.util.Properties, etc.
And to say that all Slick users don’t care about code… that’s a ridiculous statement.
I’d disagree with the above, IMO its actually harder to get started writing Java games with Java2D than with Slick2D/LibGDX.
Some reasons are as follows:
- Slick2D is designed specifically for games while Java2D is not.
- To use Java2D you not only have to learn its API but also either AWT or Swing (or both) windowing API’s.
- With Java2D you have to write your own game loop and timer code while Slick2D comes with a built in tried and tested framework that provides both.
- Java2D on recent OS X Java releases is pretty much dead performance wise, especially the all important active rendering.
- Java2D’s many different rendering pipelines lines provide very inconsistent performance and stability while Slick2D’s one should be pretty much consistent.
- JavaSound which you’ll most likely use if you are avoiding natives is pretty crap for games while Slick2D’s OpenAL backend is fast and provides low latency sound that is suitable for games while also providing support for formats like Ogg and XM.
- Slick2D’s built in framework and game focused API’s mean you need less Java code than to do the same thing in Java2D.
- Ask anyone that has done serious game development with Java2D, you need to jump through all sorts of hoops to get performance and smoothness out of it for fast games (like managing your own bufferstrategy for double buffering while this is done by default for Slick2D) and in the long run it is a dead end for games as you’ll likely hit some sort of performance limit.
- Slick2D is just a light wrapper around LWJGL and you can easily drop down to the lower level OpenGL API if you like (I even occasionally use it for prototyping 3d stuff as the framework is nice and fast for getting stuff up quickly).
- Performance is much better on Slick2D and you can throw all sorts at it (including images with lots of transparency) before you need to worry about performance, not so with Java2D as it has a lower limit which can be hit much more easily thus causing frustration and less productivity.
- Slick2D has a strong gaming focused community around it and thus easier to get game related help for it while Java2D’s game community is more scattered.
- Java2D, AWT and Swing are pretty much legacy API’s at this stage with Oracles engineers and resources having been moved to their successor/replacement, JavaFX. Soon these old API’s will be moved to some JDK module for backward compatibility only where they’ll be left to slowly die.
As for the LWJGL step you don’t have to download it separately, it comes with the Slick2D download bundle and is a simple 2 step process to set up (do note that Java2D/AWT also have natives, its just that they are added to classpath by default, for now :)).
I agree with most of the points above, though I’d take issue with a couple. You learn Swing, period, and when you want clicky button UI elements or other Swing things, the integration is nice to have. Not that a swing UI is all that desirable for games, but it suffices for learning projects. Similarly, you already have a game loop dealing with your input, so it’s really just a matter of scheduling redraws, which is hardly rocket science.
Performance-wise however … java2d is a dead end. Worse than a dead end, a tarpit. JavaFX could be promising, but I think it’s not going to be til jdk8 that it will ever feel really “official”, and maybe not even then.
Agree on Slick2D and your arguments for it.
Libgdx not so much.
You have to have knowledge of graphics programming before using Libgdx.
Like whats a power of 2 texture, and why cant I just load any image.
Whats a spriteBatch or textureAtlas; why are these things needed or at least so very encouraged.
My time in Slick told my everything I needed to know; but our game still uses Slick and still loads some images which are not power of 2…
bottom line: Slick is very easy to use, but performance gets questionable when the project gets bigger, if you dont develop your opengl skills.
Libgdx is better designed but harder to use. It’s understandable because it has a heavy focus on android, and performance is very important there.
Of course its all better than java2D by far. Especially when Slick2D’s API is so easy and straight forward and familiar to Java2D users.
Ok fine I concur on your posts, but I’m quite stubborn on my stances too
Slick2D won’t really let you get away without knowing these things either. Try tiling your NPOT texture in slick, or managing a couple hundred individual texture objects without using a SpriteSheet.
if by tilting you mean rotation: works just fine.
we actually only use tilesheets, everything else is still individual images. Works just fine. Of course it depends on how you do it.
If your textures are like 200x300, and you will only use 512x512 textures MAX, using spritesheets is not really useful, if you can hardly put 2 sprites on there.
Example : http://southtownexpress.deviantart.com/art/Takuma-KoF-XIII-Sprite-Sheet-279236989
I wouldn’t want to make on image with an height of 17000 pixel =D
We do 512 or 1024 max, for compatibility reasons.
I said tiling, as in “to tile”. IIRC, slick will pad it out to POT dimensions, which makes it not a tileable texture.
One texture per sprite is reasonably common for characters with very smooth animations. I’m talking about one texture per frame, and yes some people actually try to do that.
ah yes, I read tilTing, as in rotation I guess
(Slick hacks it so that an Image has the correct width and height, not POT, so tiling that way does actually work)
yeah for tiles you really have to use a proper implementation, in my case tilesheets and vbo’s
well yeah, eventually we are going to do it properly too, we just want to release something first
anyway my point is, that it’s nice slick at least lets you do this
IIRC tiling works fine for NPOT textures since Slick doesn’t rely on GL_REPEAT. The texture fills just draw multiple quads within the same glBegin/glEnd. The downside of course is that seams will show if the texture uses GL_LINEAR and is being scaled.
For tiles VBOs won’t help too much – most of the performance loss comes from fill rate (or state switching if you aren’t mindful).
I also like and reccomend Java2D to begginers, I would of made no progress if i hadn’t been able to draw game graphics with the ease of Java2D. Now onto opengl tho ^^