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!

Maybe you missed it because you were busy writing fundamental game utilities. Or, maybe you were just lazy.

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.

Learning is not same as writing from scratch. When you have more time you should make more games. This give really good feedback what is actually needed features at game development and then you can put all the time and effort for right things.

At my day job I code iPhone games. We have our own framework for ios. Still I have never written a single line of objective c. My main task is being graphics programmer. Still I don't even know how gl contex is made with ios. I could use my time and learn objective c and rewrite the boiler plate but what would anything gain with that? That would only delay our games and cause new bugs.

Programming is team work. You need to learn to use others people code and spent your time more effectively if you want make games as job instead of just solo developer hobby.

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.

Err, you don't use repaint when you code in java2d... Or at least I don't... There's magic thing called setIgnoreRepaint() (Or something like that xD) which disables it, so that you can use your own active rendering, instead of passive rendering(repaint() and paint()).

Err, you don't use repaint when you code in java2d... Or at least I don't... There's magic thing called setIgnoreRepaint() (Or something like that xD) which disables it, so that you can use your own active rendering, instead of passive rendering(repaint() and paint()).

Passive repaint works good enough for quite a lot of games. Not everything is a shooter or a jump-and-run.

I'm a bit puzzled about the hate for Java2D. It served me well since I first tried to make a game in Java 1998, a boulder dhas clone to see if Java is "good enough" for gaming. For me it was, and I've been using pure java for my games until a few weeks ago, and it still looks appropriate to me for most of my game projects.

Quote

why are people trying to use Java2D to make games?

People are not "trying to use", but they are making games with Java2D. Why? Java2D is good enough for many sorts of games, it's bundled with Java and does not need any extra install, setup or download. And it's pretty straightforward to use, even if some messages in this thread claim otherwise.

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.

The "you" is one of my new Year's pledges. I already watched most of the youtubetutorials, I think they are quite good explained.-> Back to Topic,In my opinion awt offers a lot of great stuff for java2d, especially because you can write your own components, it's highly customizable. Furthermore if you use the "double-buffered-layer-renderer" and active rendering it's fast and accurate enough for desktop-applications. If you just want to add a scroll-pane in jogl/lwjgl/libgdx it's not that easy as it would be in java2d.best regards

I love java2d and can get it to do all sorts of stuff. Most of the pics of particle effects I post are with a program that uses java2d so it can look great. Problem is, it is slow...and will not let you do anything past basic sprite games. No lighting without hacks and hair pulling, no additive blending so that cuts out more stuff, and it is very finicky with performance when changing from computer to computer. Not saying you can't make good games but it is very limiting.

I can make it perform well enough on most computers but just using glBegin glEnd is faster. Libgdx's silly simple sprite batch is even faster. Although it hurts to say this because I still like thunkin around with it, I agree that we should start pushing away from java2d. We should still answer questions when asked, but point to something much better...

Why people use it? Because when you google "java" and "game" you get java2d for the most part. And when you google anything about java and graphics stuff guess what, java2d.

Problem is, it is slow...and will not let you do anything past basic sprite games. No lighting without hacks and hair pulling, no additive blending so that cuts out more stuff, and it is very finicky with performance when changing from computer to computer. Not saying you can't make good games but it is very limiting.

I'm not sure if I want to believe in the "good game == high tech graphics engine" equation. There are enough types of games which do not need a high FPS. This forum has a lot of jump and run projects, but really, there are other games.

Puzzle games, card games, simulated board games, simulation games in general, point-and-click adventures, visual novel type projects and the like all do not need a high-tech graphics engine to become a good game.

I also see nothing bad in sprite or tile based engines. With good quality pre-rendered sprites and tiles you can make very good looking games, and Java2D is really good enough to draw tile based maps with sufficient FPS.

But I know that I have a different opinion on sufficient FPS from many forum inhabitants. Even for games that involve movement, I think that a stable 10 FPS are often good enough. But people post about engins that do like 800 FPS or 1200 FPS or more. I wonder what is this good for? It's a technical achievement, and demonstration of coding ability, but it won't make you a good game just by itself.

I dunno. I'm just worried that the "you need open gl to make good games" will teach new game designers wrong things. You don't need open gl to make good games. First of all you need a good idea for a game, and skills to make this idea into a game ... and if you are a good designer, you can bring a good idea alive even wiht very simple graphics. I believe more in the creativity of the designer to be important for games, than in the excellence of technical execuation. Particularly for indy and hobby projects - if you make a AAA game title, I would talk different, but 90% of the forum population don't. Maybe 95%.

So I keep saying Java2D is good enough unless you are going to make a shooter, action RPG or jump-and-run. ANd even those you can make with Java 2D if your game can live without the most flashy effects - and these effects will not make a bad game any better. They just make it sell better if you advertise with the graphics.

I'm not sure if I want to believe in the "good game == high tech graphics engine" equation. There are enough types of games which do not need a high FPS. This forum has a lot of jump and run projects, but really, there are other games.

Puzzle games, card games, simulated board games, simulation games in general, point-and-click adventures, visual novel type projects and the like all do not need a high-tech graphics engine to become a good game.

I also see nothing bad in sprite or tile based engines. With good quality pre-rendered sprites and tiles you can make very good looking games, and Java2D is really good enough to draw tile based maps with sufficient FPS.

I dunno. I'm just worried that the "you need open gl to make good games" will teach new game designers wrong things. You don't need open gl to make good games. First of all you need a good idea for a game, and skills to make this idea into a game ... and if you are a good designer, you can bring a good idea alive even wiht very simple graphics.

Fancy graphics won't make a good game. But you need a platform that can deliver reliable graphics and sound across a variety of systems, and Java2D/JavaSound falls short of this need. You also need a platform that won't hold you back creatively. Nothing worse than "Wow, that would look fantastic, but it won't work in Java2D."

Video games are ultimately a visual/auditory experience -- you are kidding yourself if you think graphics don't matter. Just like in film, game developers strive to create an immersive experience. Take a look at Desperate Gods, which utilizes advanced graphics to bring your standard board game genre to a new level of immersion.

Quote

Particularly for indy and hobby projects - if you make a AAA game title, I would talk different, but 90% of the forum population don't. Maybe 95%.

I think you are underestimating the abilities of JGO. Check out the Featured Games. Almost every game there would not be possible in Java2D alone. These are games made by forum members; indies and hobbyists.

Even the simplest puzzle games on JGO (Shijin Reversi, Atomic Harmony, Lost Geometry) require OpenGL because they are being distributed to Android.

Aside from all this, you are missing the whole point of the discussion. It's not just about graphics or sound, but the platform itself was not designed for games and thus you end up needing a lot of boilerplate to get a simple game working. Tiled maps, game loops, texture atlases, input, themed GUI, etc.

Don't even get me started on sound...

It seems like the only reason you are defending Java2D is because you are too stubborn to learn a new platform. Or maybe just ignorant of how much easier game development is with LibGDX.

EDIT:

Quote

So I keep saying Java2D is good enough unless you are going to make a shooter, action RPG or jump-and-run

If you're trying to emulate Minesweeper, Solitaire, and other static games of the 90s, then sure, Java2D is suitable. But most of us aspire to make slightly more complex games. As soon as sound or a game loop is involved, Java2D/JavaSound is the wrong choice.

Fancy graphics won't make a good game. But you need a platform that can deliver reliable graphics and sound across a variety of systems, and Java2D/JavaSound falls short of this need. You also need a platform that won't hold you back creatively. Nothing worse than "Wow, that would look fantastic, but it won't work in Java2D."

Video games are ultimately a visual/auditory experience -- you are kidding yourself if you think graphics don't matter. Just like in film, game developers strive to create an immersive experience. Take a look at Desperate Gods, which utilizes advanced graphics to bring your standard board game genre to a new level of immersion.

Graphics are a great way to pull people in to buy your game, but the level of immersion felt is completely done by the game play itself. If you want proof, take a look at books. 0% graphics, 100% immersion. They can inspire you and immerse you in the same way a great game can. To be honest, I believe it is very distracting to game makers to have all these extra features that OpenGL gives. There is a lot more people now thinking they'll be able to make an AAA title game on their first try.

It is just an argument about game creation speed vs. learning game programming.

For all you aspiring game creators out there, the best course of action is to learn a library. LibGDX is pretty much the best decision if you want to make sure your game will be played by the most people fast. If you stick directly to the library defined functions, you should be able to create your game vision decently without much issues. The problem is when you try to achieve something that the library API doesn't show you.

Enter learning game programming...

For those of us who started with Java2D or OpenGL, we have a deeper understanding of the underlying technologies. When the LibGDX library comes to us with a limitation, we are much more equipped to deal with the problems than those who decided to take the library learning route. The sad part is, those who learned the library first will have it 150% harder to learn Java or OpenGL because they will have no basics to fall back on.

What does this mean?

It means that time is truly of the essence. Game designers have to create a good plan for themselves.

Learning the library first will get a game out faster in most cases. But, you will not have a fail safe if you find the library documentation or functions limited. Designers who take this route have to be prepared to not get every single feature in their game, and just get used to working within the limits of the technology.

Learning the language is more like a journey. Most of the things you'll learn from Java2D you'll be able to take with you when you code OpenGL, and work with libraries like LibGDX. You'll have a building tool set that'll last you no matter what new technologies or libraries emerge. When problems occur, you'll be able to spot them and adapt much easier.

People have to realize that there is more than one route to a good game...

For us programmers, building a good tool set will make sure we will be able to survive. We are the architects, the builders of the programming world. When Java is faced with destruction from a flooding river, we are the ones with the most knowledge that'll get a moat built of OpenGL to keep Java from going under. We are also the ones who can build games, but most of us are always looking and preparing for the next wave of destruction.

For the game designers, they invested in property in our Java world through libraries. Some of these properties are bustling cities, like LibGDX. Others are going down in the suburbs like Java2D. All of our community is important to game creation. People who live in the city have the dreams to create great games, but they are confined within the structures that they live in.

Where do you fit in this world?

That is the question we should really be asking ourselves before even thinking about game creation.

1. Every tool you use to make a game has to solve some problem you've got, otherwise you're just wanking around creating problems for yourself. I started out using OpenGL because it solved the problems I had, which were basically performance, features, reliability, and portability. Ease-of-use is a bit of a harder one to nail down because basically if the API you're using hasn't got the features you want then trying to bend it to your will can get extremely complex and frustrating. OpenGL solved this by being right at the very bottom of the graphics stack; it can be bent in any direction.

2. Missing from a large majority of game developers is some sense of what is shit. I mean, you create something, get it out there, feel all proud and that... but if you really took a critical eye to your own work, you could probably come up with 100 things wrong with it straight away. And the surprising thing is that you won't actually spot any of the massive areas of shitness that the other 50,000 people who see it will instantly spot. Like for example, there is this general attitude amongst developers that it's ok to make 2D games that don't run at 60Hz. It isn't. Everyone else who plays your game instantly notices and compares it to all the games they played at 60Hz and it instantly looks and feels shit to them. You might also think, for example, that you can get away without antialiased sprites these days. Unfortunately there is a shrinking section of the population who actually remembers real pixel art and a very large and growing section of the population who never saw it the first time round. Your graphics look like shit to them. And then there's sound. It's actually one of the most fun bits to do of a game and also surprisingly one of the most important but it's almost always a total afterthought. And woe betide anyone trying to use the standard Java Sound APIs to do it. (Btw: MIDI is shit. Please. Just don't do it. You might think it's great but it really does help to try and put yourself in the shoes of, uh, some other million people and guess what their reaction will be to it)

3. There are awesome games that don't need performance, or even many features. If you don't need performance or features particularly then Java2D is probably a great choice, although one might question again why you're using a low-level language at all if this is the case.

If you show someone a game, the first thing they look at is graphics. If all your game does is look good, they would still think it is better then a game that you could actually play because it is super purdy. Sound is another animal all together. Most people will not notice much about sound when it is done right. If you do it wrong, then it drops the game to shittery. Even if everything is super polished, people will still find thousands of things that are legitimately bad. Try taking a friend that knows nothing about programing and showing them some of the stuff on here and you will quickly find out how truly ugly all the games on here are. (Not being discouraging, but our stuff is ugly) You need every edge you can get and java2d is like taking a stone to it.

I watch a video someone posted on here about totalbasket or something reviewing Titan Attacks. He liked it but the big thing he liked was the graphics and retro-ness. He didn't talk about game play much at all but boy did he mention how he would buy any remake game that had that style of art.

I try to keep everything I do looking at least some what presentable and even then it is months of polish behind most flash games today. If you are at all serious about making a game more then solitaire, then you need to move on from java2d.

Graphics are a great way to pull people in to buy your game, but the level of immersion felt is completely done by the game play itself. If you want proof, take a look at books. 0% graphics, 100% immersion.

Apples and oranges. Games are visual/auditory media, whereas with books you become immersed through your own imagination.

When a game's frame rate drops, or when the sound glitches, or when the GUI looks like something from Windows 98, the effect is lost.

The rest of your post is pretty incoherent, and I'm not sure what you are trying to say.

Learning LibGDX will not hinder your ability to learn OpenGL. In fact, it's probably much easier to learn the OpenGL pipeline through a library like LibGDX. The design of the API forces you to think about textures, vertices, batching, matrices, and even shaders

Whereas with Java2D these concepts are foreign. The graphics programming you learn from Java2D will not translate well to the OpenGL pipeline -- "square peg in a round hole" -- nor will it prepare you for matrices, shaders, vertices, or anything else of the sort.

Graphics are a great way to pull people in to buy your game, but the level of immersion felt is completely done by the game play itself. If you want proof, take a look at books. 0% graphics, 100% immersion.

Apples and oranges. Games are visual/auditory media, whereas with books you become immersed through your own imagination.

When a game's frame rate drops, or when the sound glitches, or when the GUI looks like something from Windows 98, the effect is lost.

The rest of your post is pretty incoherent, and I'm not sure what you are trying to say.

Learning LibGDX will not hinder your ability to learn OpenGL. In fact, it's probably much easier to learn the OpenGL pipeline through a library like LibGDX. The design of the API forces you to think about textures, vertices, batching, matrices, and even shaders

Whereas with Java2D these concepts are foreign. The graphics programming you learn from Java2D will not translate well to the OpenGL pipeline -- "square peg in a round hole" -- nor will it prepare you for matrices, shaders, vertices, or anything else of the sort.

Well, comparing games to film is the exact same type of comparison, like apples and bananas. Games immersion comes through the actions you do within the game. Movies immersion comes through connecting with the characters and story. I would like to believe that people don't play games for the cut scenes alone.

To be more concise with my previous point post, it is this. Just like you used LibGDX to create an easier jump into OpenGL. People can use Java2D for a better jump into LibGDX. You need to understand the basics of programming in order to use the underlying libraries correctly.

Most gaming problems are not because of drawing issues, they are because of logic issues. I can say that without any doubt. Most people who can't build Pac-Man on Java2D, will not be able to build Pac-Man on LibGDX or OpenGL. It has nothing to do with the hardware, people just can't figure out how to make code do what they want.

For those who just want to get games published, using a well-made game library will get it done. Point-and-click game engines like "The Games Factory" are fully capable of creating games. However, it comes with the price that you will not manually be able to change the coding. That is the price for using libraries, you can't always get everything you want.

I'd really like to see an increase in graphical games for Java. However, we are just not there yet technology wise. If the JVM could target X-Box Live, PS Store, and other console venues, this discussion would not exist. The fact is, we need more games period. It shouldn't matter the technology as long as we have a healthy community that continues to produce.

It will be a struggle regardless of the library you choose to start with, but choosing LibGDX will make the experience much less painful.

Person A spends their first year learning to use Java2D. They learn how to program in that time, but they'll still be unprepared when migrating to OpenGL.

Person B spends their first year learning to use LibGDX. They learn how to program. They will also write more games, and less boilerplate. Their games will run faster and more reliably across systems. Their games will be playable on a variety of platforms including mobile and HTML5. They will have a richer community of game developers (forums, IRC), and more game-development geared documentation/tutorials. They will be more comfortable with textures, matrices, vertices, etc. And after it all they will be much better prepared to use lower level OpenGL (which, in fact, they may never need).

Why is this still a discussion!? You'd have to be a fool to recommend Java2D as a viable alternative for newcomers.

The fact is, Java2D is useless beyond the very small confines of the Java platform. Knowing OpenGL not only lets you understand how Java2D might work under the hood and graphics processors in general, but also let you move on to Android coding, iOS, and Playstation, and will give you a steady foundation into DirectX as well. The bigger picture is that Java2D is an obsolete, stagnant API that lives in a wasteland; the future is OpenGL (ES). So get learning that, from scratch if you really want to do something useful with your time beyond Java.

Another fish for the kettle - back in 2000 when I started doing graphics in Java, Java2D was considerably more rubbish than it is today. It's made a lot of improvements in 12 years.

Fact - you NEED to use OpenGL directly or using library to make ANY more advanced, good looking game. I would not recommend Java2d for anything related to game programming, with exception of 4k games and minigames.

After all, I think that... Java2d is good for newbies. Why? Java2d API is very simple, you don't need to make your own texture loaders, camera classes and stuff like this, so I think it is good if your first (mini)game is made in Java2d.

My 2p for Java2d - it's a powerful and flexible drawing API which produces high quality images with near pixel-perfect accuracy between platforms.

Yes, quite! Somewhere the good advice to not use Java2D for (most) games turned into a general slanging match at Java2D for not being what it was never designed to be. As a general purpose graphics toolkit, it still has a lot of other uses.

OpenGL solved this by being right at the very bottom of the graphics stack; it can be bent in any direction ... And woe betide anyone trying to use the standard Java Sound APIs to do it.

I generally agree with most of what you've said, but those two statements don't exactly match up, assuming you're suggesting (as per recent JS thread) to use OpenAL. If you ignore all the cruft in the JavaSound API (Clip, Port, Control, etc.) the direct mixers and output lines give you far lower-level interaction with the soundcard - it's about as close-to-the-metal as you can get without working with each platform's sound API natively. It would be possible to implement something similar to OpenAL on top of it.

The general advice that most people should choose a decent library still holds, though. Audio is often an afterthought, and that goes for audio code too - there's about as much to learn about doing low-level audio programming as there is about low-level graphics! A decent JavaSound backed library can be as stable and usable as OpenAL.

(Btw: MIDI is shit. Please. Just don't do it. You might think it's great but it really does help to try and put yourself in the shoes of, uh, some other million people and guess what their reaction will be to it)

hmm .. MIDI could potentially be interesting again in a Java 7+ world. The Gervill software synthesizer now built into the JRE is actually a great bit of code. Mix that with a decent customized sound bank, and you've got a powerful and fairly easy to use live DSP system for background music and SFX.

hmm .. MIDI could potentially be interesting again in a Java 7+ world. The Gervill software synthesizer now built into the JRE is actually a great bit of code. Mix that with a decent customized sound bank, and you've got a powerful and fairly easy to use live DSP system for background music and SFX.

If you want sequenced music (which is the common reason for wanting midi) then there are several better alternatives like .xm or .s3m, some of which have open source players already available. They support more feature than midi which will make your music guy happier. And you don't tie yourself to a VM release.

Using MIDI to play music is like using SVG to render sprites. Don't! Make OGGs and stream them! And pre-render your sprites into an atlas while you're about it!

Yes, pre-render if it's a static thing - I did say "live" system. If you want to do some interesting stuff where SFX and music respond to player actions though, Gervill might be an interesting way to achieve that. Combine that with JFugue as well and you've got an interesting system for evolving and adapting music at runtime (note the comment on the JFugue front page about music responding to game states! )

If you want sequenced music (which is the common reason for wanting midi) then there are several better alternatives like .xm or .s3m, some of which have open source players already available. They support more feature than midi which will make your music guy happier. And you don't tie yourself to a VM release.

As well as noting the "live" comment (I'm not really meaning sequenced music - the fact that it involves using MIDI messaging is incidental), MIDI combined with Gervill (SF2, DLS, etc.) potentially offers more features not less. And whether your music guy prefers mod files really depends on the music guy - they have their own limitations!

Oh, and you're not tied to a VM release, you can ship Gervill by itself.

btw - I only brought this up here as Cas mentioned not to use MIDI earlier. I generally agree with that comment (as regards MIDI files) but we shouldn't disregard a rather good sound processing system embedded in the JDK just because it needs driving by MIDI messages - they're just method calls really! ... And, I have a pathological need to act as devil's advocate at times!

Just as an aside: gamma space rendering is wrong. It's worse wrong the not pre-computed alphas. Go into a dark room and shine two identical flashlights with new batteries such that the spotlight overlaps..or go look at the moon. End of aside.

Nobody cares what is better. You can try your hardest to convince someone that you are doing something the best way, but as long as they think they're doing it the best way, there is no way to convince them otherwise.

You think LibGDX is the best? Good for you. I don't care, and neither does anyone else who just uses LWJGL. There is no way you can convince us otherwise, and there is no way we can convince you to use LWJGL.

The fact that Java2D is useless for making games is irrelevant. Those who use it don't care if your API is better. They just want to make games with it, and change over when they feel like it.

A person's idea of laziness (or anything for that matter) is their own. If they want to share their opinion, then they have the right to. You can't stop them. They can't stop you from sharing your opinion.

A person's idea of laziness (or anything for that matter) is their own. If they want to share their opinion, then they have the right to. You can't stop them. They can't stop you from sharing your opinion.

You remind me that some C++ programmers think we are lazy because we use Java. I think that there are tons of ways to learn game programming as I explained here but those who succeed in creating games are not lazy, it requires some time not only to create them but to learn how to achieve that.

I spend so much time in writing tools and my main game is currently not very good, I'm happy when I learn that some "lazy" guys use them to make their own game(s).

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