To be blunt, as I am always blunt, knowing how things work under the hood allows you to write more solid and optimized code. Just linking things together in a way that works usually leads to a huge mess in the end, sure it runs, but you will have tons of memory leaks, extra CPU/GPU polls, and you will have no idea of how to fix those issues. A program is a work of art, not a hammer.

I don't think this is an absolute. It's certainly useful to know how your tool set works, but it often is not a necessity. Most Java developers don't understand how the JVM works, aside from at a very high level, and get along just fine. You may be able to write "better code" with more knowledge of the internals of whatever tool, but to me it's the mark of a quality library if you can get work done quickly and easily without having to *care* what's actually going on underneath.

It really shows a lot about the direction Java is going in the future. This doesn't even have to do with game programming. I think if we all believed in this specifically, Java will not have a foothold in the future of programming period. All that will be left will be the "true" base technologies: OpenGL ES, HTML5, and JavaScript. Java is completely unnecessary by this same logic, and LWJGL is a last ditch effort to keep a struggling library alive.

It was stated that there were plenty of tinkerers...

And rightfully so. There has to be when the technology does not leave easy answers to your questions. Tinkering is the way that people who care passionately about a technology try to improve it to become better. Many of the libraries we have today that made Java better were products of tinkering. These projects are necessary to improve the language by answering the basic questions no one else dared.

"Can a game written in Java be played on iPhone?""Is there a way to accelerate Java speed equal to C?"

How are these questions answered? Through tinkering.

why are people trying to use Java2D to make games?

Because, all the questions for Java2D are answered. Java2D still remains as our most sturdiest platform. You can ask anyone where to find documentation on how to display a screen. We can get them a direct site without telling them, "Go search Google." That is the major problem with our current technologies today. Java was built on great documentation along with its code. The newer projects were all tinkering ideas that happened to make it big. Not all tinkering projects have great documentation in mind. As a community, I feel that our lack of organization is the biggest nail in the foot, and for us to rely on Google shows our lack of faith in our own API.

We are all game designers here, so let me give you an example of how bad this sounds. Let's say I made this really cool RPG game on my website. I have a forum where users can speak about my game and tell me problems/ideas. Then, when a user comes to me with a game problem on my forum, my response is... go check on Google for other RPG's solutions to the problem. I hate to say it... but it is pure laziness on the people producing the API to not have proper updated tutorials for users who want to use their product.

Tinkering will be reduced if people knew where to find the answers. Plain and simple. Even something as simple as getting a book published for how to use LWJGL, JOGL, or even LibGDX will be a huge push forward for these API's. But, I know these are all running on a limited budget, so just having a focal point for the documentation will be helpful enough.

Final thoughts...

Game making is very difficult. You can have really great documentation for an API, but still games will not be created. The problem stated here is a lot bigger than just gaming. This is why we have so many people tinkering to try and make solutions to the problems easier to manage.

Actually, there are a lot of people on this site who are paving the way to much easier game development in the future. Procedural developed music, mass particle effects with minimal CPU, simplex noise generators, sound API that can work across platforms, video API that can work across platforms, etc. It is these technologies, once perfected, that is going to make Java as a whole keep its place in the programming world.

Games is only a small piece of this puzzle. As a community, however, we should strive to make it as easy as possible for users to answer these questions without having to trudge through forum threads or search on Google. It all starts with the people who are creating the API's. If the documentation is right on target, then you'll find a lot more people using your technologies to create games.

Learning every tiny bit of an API is hard, and my tiny brain is not big enough. Every time I figure out how to do something, I bung the code in a class somewhere and promptly forget about how it works afterwards.

So stuff like texture loading ... I did that years ago and never looked back at it. This is programming! You only have to solve something once. It doesn't take long.

Cas

This is how all programmers should work.

Random sentence to make at least 10% of this post mine...... Etc. etc.

I don't think this is an absolute. It's certainly useful to know how your tool set works, but it often is not a necessity. Most Java developers don't understand how the JVM works, aside from at a very high level, and get along just fine. You may be able to write "better code" with more knowledge of the internals of whatever tool, but to me it's the mark of a quality library if you can get work done quickly and easily without having to *care* what's actually going on underneath.

When developers understand how it works under the hood, they can contribute which is vital for free open source libraries. When they don't, they need some help from people who do. Therefore, such knowledge drives a developer more autonomous even though I agree with your last point.

As well as libGDX / Slick2D, Processing 2.0 would make a good starting point for someone new to creating games in Java. You've got the ability to work with software rendering or a modern shader-based OpenGL pipeline on the desktop (JogAmp based Julien! ), as well as export to Android (with OpenGL) and export to JavaScript (canvas or WebGL). It's generally much better documented, and there's a range of small games out there created with it (particularly HTML5 ones).

I am 15 and for me it is much easier to use Java2D to begin with, because, like a lot of people here have already stated, I can find simplistic, easy to follow answers to my problems with code that is easy to follow.

These libraries such as libGDX etc probably do have a ton of advantages, but the thought of having to write a lot of lines of code for the simple things is extremely daunting.

Counter-Argument:

Just like the time when I used XNA two years ago. The framework was solid and yes, I needed to write a couple more lines that necessary but after learning it once, I could do it. I'm sure these libraries are probably the same and are more than likely well worth looking into and using, but until they come with the support required by newbies( like me ) they won't be used by newbies, for now.

These libraries such as libGDX etc probably do have a ton of advantages, but the thought of having to write a lot of lines of code for the simple things is extremely daunting

You are missing the point... by using java 2D you are going to need to write MORE code! And it will be more challenging, and render slower.

For example, to set fullscreen mode in LibGDX you just need to set a boolean to true... In Java2D you need to deal with a lot more lines of code ("fullscreen exclusive mode") and it might not even work reliably on all platforms!! Same goes for rotating a sprite, tinting an image, using transparency, game loops, tiled map loading, custom bitmap fonts, game UIs... The list goes on. Java2D is a terrible library for 2D games.

More promoting libGDX...it has classes that you would otherwise have to make yourself, Camera, Vector2/Vector3, SpriteBatch, automatically caps fps to 60, better key detection (just one line of code for polling), particle effects, actors and stages, etc. Oh, and TWL

It may take longer to learn (not so much the learning curve as there aren't that many tutorials) but you will make games so much faster. Keep in mind that I am 14 and there are several people younger than me on this forum so age really doesn't matter too much as long as you spend time on it.

If at any point you wonder why you are taking some minutes out of your day to set up a library when you could instead just dive right into Java2D, remember: Java2D is crap for games, leads to poor performance, and will require you to write hundreds more lines of code. See this simple example: Java2D vs LibGDX

And, as a bonus with LibGDX, you will be able to port your games to Android and HTML5.

More promoting libGDX...it has classes that you would otherwise have to make yourself, Camera, Vector2/Vector3, SpriteBatch, automatically caps fps to 60, better key detection (just one line of code for polling), particle effects, actors and stages, etc. Oh, and TWL

It may take longer to learn (not so much the learning curve as there aren't that many tutorials) but you will make games so much faster. Keep in mind that I am 14 and there are several people younger than me on this forum so age really doesn't matter too much as long as you spend time on it.

All the reasons you have for using libGDX are just laziness.I've written my own classes for Vector2, Vector3, and Vector4.I've written my own equivalent simple version of a Spritebatcher.I've written my own camera class.I've written my own game loop.I've created particle effects.I've written a Key Listener.

All with LWJGL. And I'm 14 too. "Age doesn't matter too much if you spend time on it". When that sentence has the context changed, I agree.

LibGDX promotes laziness of coding. You're promoting it as a way for beginners to use OpenGL. But are they really learning to use OpenGL? Or are they just blindly doing what X tutorial said without knowing what on earth they're doing?

People who use Java2D are probably more likely to move on to LWJGL which really does help you learn OpenGL, and good coding skills.

I'm not saying people should'nt use LibGDX, because HTML5 and Android conversion are Awesome. I'm saying you should learn what that code you just typed out is actually doing.

Disagree if you wish, but if you don't want me saying 'Your library is bad', don't say it to the people using Java2D

Laziness, yes, but you've missed the most important of our resouces - time. While you made all those classes yourself, and while it may have been a good learning experience, libgdx users save time because we just have to download it.

This is like saying Python or Java is too high-level, and you must be lazy if you aren't using C, C++ and assembly. Hell, why use LWJGL at all, when you could instead write your own OpenGL wrapper from the ground up?

The truth is: people have different goals. A "game developer" wants to make a game, and it makes no sense for them to spend hours re-inventing the wheel. A "graphics programmer", on the other hand, wants to understand and optimize things at the lowest level -- even if that means going down to C/assembly -- and generally don't budget as much time for gameplay, storyline, content, etc.

Quote

You're promoting it as a way for beginners to use OpenGL. But are they really learning to use OpenGL? Or are they just blindly doing what X tutorial said without knowing what on earth they're doing?

You don't need to know how to build an engine to drive a car.

Just like you probably don't care which Win32/Cocoa/etc calls are being made by LWJGL's Display class, the newbie shouldn't be concerned with what's happening under the hood when he calls LibGDX methods like the following:

More important is that they understand the OpenGL concepts involved; such as texture filters and wrap modes. As they become more comfortable with graphics programming, they can choose whether or not to look "under the hood" to see how it all comes together.

Quote

Disagree if you wish, but if you don't want me saying 'Your library is bad', don't say it to the people using Java2D

I am beginning to wonder whether you've ever even tried LibGDX...

If you want to re-invent the wheel with "pure OpenGL" code, then you can still do that with LibGDX by calling Gdx.gl/gl10/gl20. There are very few reasons to use LWJGL these days.

In its smallest form, LibGDX is ultimately just another OpenGL wrapper. So, instead of writing your own SpriteBatcher in LWJGL (for desktop-only), you could have written it in LibGDX (for multiple platforms).

More promoting libGDX...it has classes that you would otherwise have to make yourself, Camera, Vector2/Vector3, SpriteBatch, automatically caps fps to 60, better key detection (just one line of code for polling), particle effects, actors and stages, etc. Oh, and TWL

It may take longer to learn (not so much the learning curve as there aren't that many tutorials) but you will make games so much faster. Keep in mind that I am 14 and there are several people younger than me on this forum so age really doesn't matter too much as long as you spend time on it.

All the reasons you have for using libGDX are just laziness.I've written my own classes for Vector2, Vector3, and Vector4.I've written my own equivalent simple version of a Spritebatcher.I've written my own camera class.I've written my own game loop.I've created particle effects.I've written a Key Listener.

All with LWJGL. And I'm 14 too. "Age doesn't matter too much if you spend time on it". When that sentence has the context changed, I agree.

LibGDX promotes laziness of coding. You're promoting it as a way for beginners to use OpenGL. But are they really learning to use OpenGL? Or are they just blindly doing what X tutorial said without knowing what on earth they're doing?

People who use Java2D are probably more likely to move on to LWJGL which really does help you learn OpenGL, and good coding skills.

I'm not saying people should'nt use LibGDX, because HTML5 and Android conversion are Awesome. I'm saying you should learn what that code you just typed out is actually doing.

Disagree if you wish, but if you don't want me saying 'Your library is bad', don't say it to the people using Java2D

Good programmers should be lazy. Laziness is virtue. It make you think more and write less. It will save you ton of work that have already be done. You have then more time for learning new stuff and writing interesting things instead of inventing wheels and writing boilerplate. But laziness does not mean that you should just use things that you don't understand at all or copy pasting randomly. Lazy coder search reference even when inventing wheel again because all humans make mistakes and its not helpful make same mistakes that others have already pointed out.

Just using java is lazy. You should write your own compiler and build own virtual machine and write libraries against it and only after that starting to write games. Heck why not inventing computer first? So if you are lazy like every coder should have why not be just a tad lazier and use all the goodies that community have write before you.

There is a difference between laziness in learning, and laziness in programming.One of them, you take shortcuts (such as x++; instead of x = x + 1; in the minor cases), or write utility code that you never have to touch again.The other, you take someone else's wheel.

This is like saying Python or Java is too high-level, and you must be lazy if you aren't using C, C++ and assembly. Hell, why use LWJGL at all, when you could instead write your own OpenGL wrapper from the ground up?

WHOAH! There is a difference between buying an assembled computer, assembling a computer, and making all the components for the computer.I don't use C/C++/ASM because of the syntax (or rather how the syntax makes the source code look).

Quote

You don't need to know how to build an engine to drive a car.

Yes, but as programmers, we are the people "making the car", not driving it (except when we test it). This statement can however be taken either way (as we could just be assembling the car), so does not contribute to the argument.

Quote

More important is that they understand the OpenGL concepts involved; such as texture filters and wrap modes. As they become more comfortable with graphics programming, they can choose whether or not to look "under the hood" to see how it all comes together.

True.

Quote

I am beginning to wonder whether you've ever even tried LibGDX...

Nope. Never tried it. And if it weren't for the next part of your argument, I probably never would

Quote

If you want to re-invent the wheel with "pure OpenGL" code, then you can still do that with LibGDX by calling Gdx.gl/gl10/gl20.

Wait, WHAT??!! Does that mean I can use my code designed for LWJGL with LibGDX and still port to HTML5 & Android? (obviously changing the classes & method calls etc.) Why don't they promote that as one of their advantages and I would have used it long ago!

Wait, WHAT??!! Does that mean I can use my code designed for LWJGL with LibGDX and still port to HTML5 & Android? (obviously changing the classes & method calls etc.) Why don't they promote that as one of their advantages and I would have used it long ago!

Yes that should be possible because it says that you can manipulate the pipe as u want, but I am just getting into libgdx so please don't bother if there are some limitations.

@TopicAs I started gamedev. I googled "java tutorial gamedevelopment" -> Youtube + Everything else was about java2d. jogl, lwjgl, libdgx aren't on the front-pages so as a beginner u want recognise them.best regards

Wait, WHAT??!! Does that mean I can use my code designed for LWJGL with LibGDX and still port to HTML5 & Android? (obviously changing the classes & method calls etc.) Why don't they promote that as one of their advantages and I would have used it long ago!

Yes that should be possible because it says that you can manipulate the pipe as u want, but I am just getting into libgdx so please don't bother if there are some limitations.

@TopicAs I started gamedev. I googled "java tutorial gamedevelopment" -> Youtube + Everything else was about java2d. jogl, lwjgl, libdgx aren't on the front-pages so as a beginner u want recognise them.best regards

Please use a proper 'you' instead of 'u', it's burning my eyes out right now. Take a look at TheCodingUniverse for some LWJGL tutorials.

Real men write all their code in assembly. Anything else is just laziness.

@HeroesGraveDev: Your idea of where the "being lazy" line is drawn is subjective. Some people think using pre-built game libraries is lazy, others don't. Some like using full-blown game engines like Game Maker, other's don't. There is no right or wrong answer.

Real men write all their code in assembly. Anything else is just laziness.

@HeroesGraveDev: Your idea of where the "being lazy" line is drawn is subjective. Some people think using pre-built game libraries is lazy, others don't. Some like using full-blown game engines like Game Maker, other's don't. There is no right or wrong answer.

Since you talked about being subjective earlier, an appropriate end to your post would be that there is no objective answer.

laziness or not, it's a fact that going through java2d is a bad idea. you place yourself at the mercy of the Event dispatch Thread, and you can't really control when you refresh. Repaint() is just a suggestion the EDT gets around to when it's good and ready.

laziness or not, it's a fact that going through java2d is a bad idea. you place yourself at the mercy of the Event dispatch Thread, and you can't really control when you refresh. Repaint() is just a suggestion the EDT gets around to when it's good and ready.

You can control when you repaint.

On Laziness:

It's relative to the amount of time you have available. The more time you have, the more learning you should do while working.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org