Hello people,I have learned that mixing mixing light-weight (Swing) and heavy-weight (AWT) components is generally considered bad programming style, but in some cases it seems to be practicable. In the following example, the graphics are drawn on a canvas while for the rest of the GUI Swing is used. Why that? Why not AWT?

Other questions I have: What is the best way to put the game loop into a separate class? Maybe a singleton GameLoop class which provides a loop() method that is later called in the run() method? Does it make sense to use a scene graph for 2D games and if so, how is it implemented?

Most people choose Swing since it is more powerful, usually looks nicer (themes etc) and more standard. The main problem with mixing light and heavy weight components is render order, e.g. for popups like menu items. Sometimes JPopupMenu.setDefaultLightWeightPopupEnabled solves the problem.

Singletons are generally not a good design pattern. There are many ways of decoupling your game loop, one easy choice:

Another common solution is to use a "listener" interface. So, instead of calling methods in AbstractGame, you pass a listener to the Game class at creation time, and then the Game class calls the listener's methods during the game loop. This makes it easy to support multiple backends and distributions.

Ultimately though, if you plan to make a relatively complex game (i.e. one that requires a scene graph, in-game UI, tiled maps, sprite sheet animations, physics, etc) you should not use Java2D. Not only is it slow, bulky to use, and doesn't give you anything "out of the box," but it only distributes to desktop and applets (which are now defunct, for all intents and purposes).

Instead it would make sense to use a game-specific framework built on OpenGL rendering, like LibGDX.

Thanks. The central point is that I want to use BufferStrategy, because according to some threads and tutorials this is more powerful than BufferedImage. However, it's part of AWT and not Swing, hence I think that it might make sense to use only AWT components to avoid any problems. At least for noobs that would be the less error-prone decision, wouldn't it?

1. Mixing AWT and Swing isn't that bad; it's probably worse having to deal with AWT itself than the subtle z-order problems that can occur when you mix it with Swing. If you get problems, you can use the JPopupMenu utility method to fix most of them.

And generally speaking your game won't need JMenuBar or JPopupMenu anyways, since that will be built as an in-game GUI.

2. BufferStrategy and BufferedImages are apples and oranges. You will be using both for an active rendering loop.

3. If you are looking for "good performance" than Java2D isn't the right choice in the first place. Like I said; build your game on OpenGL -- this means using LWJGL, JOGL, or something higher level like LibGDX, lwjgl-basics, jPCT, jMonkeyEngine, etc.

In-game-gui means that all messages and preferences/settings panels are written directly to the screen without using any Swing/awt GUI components? Seems like a lot of work, but maybe it's easier than I think. Do you know any example for such a GUI?

Thank you :-)My goal is to make a simple, very basic tetris-like game, but it should have a solid, efficient fundament which can be used to build more complex 2D games. I used OpenGL many years ago and have never used it since then, so I think it would be quite hard to implement. Most people don't recommend to use OpenGL for 2D, some do, but I don't have enough experience to evaluate the pros and cons. I also haven't found any tutorials on 2D OpenGL games in Java. Doesn't Java2D use OpenGL under the hood? OS window managers are also 2D, but sometimes based on OpenGL.

Most modern 2D games use OpenGL -- and virtually any 2D game on iOS/Android will use OpenGL ES. It's the best way to deliver high performance and provide flexible graphical effects (blurs, post-processing, etc). I'm not sure who told you that OpenGL is not good for 2D -- maybe that was true in 1991, but we have come a long way since then.

Java2D may or may not use OpenGL for rendering; on many systems it will default to software, and in many cases the hardware-acceleration it does take advantage of is not exactly reliable or performant. Basically, you can't rely on Java2D to take advantage of hardware.

LibGDX code abstracts a lot of OpenGL rendering for you; and isn't very difficult to work with. In this sense, it's a bit like Java2D in its abstraction of image/shape rendering.

This discussion is a bit silly.. Just try LibGDX for yourself before you continue to wonder about how difficult it may be. I can assure you that it will be easier and less painful to make a complex game in LibGDX than to program it entirely from the ground up with Java2D. Most importantly; it will be much more performant.

Thank you :-)My goal is to make a simple, very basic tetris-like game, but it should have a solid, efficient fundament which can be used to build more complex 2D games. I used OpenGL many years ago and have never used it since then, so I think it would be quite hard to implement. Most people don't recommend to use OpenGL for 2D, some do, but I don't have enough experience to evaluate the pros and cons. I also haven't found any tutorials on 2D OpenGL games in Java. Doesn't Java2D use OpenGL under the hood? OS window managers are also 2D, but sometimes based on OpenGL.

Actually, most people would recommend opngl. Once you get past the boilerplate code, everything should be a breeze and if you use libgdx, boilerplate code is handled by libgdx for you.

The only reason to do java2d for games these days it's fun learning it(at least for me).

Thanks. I am just thinking about how to decouple the game loop from the display update and game state update methods. In most cases you have a display class like

1 2 3 4 5 6 7

publicclassGameScreenextendsCanvasimplementsRunnable {

run() {// game loop here with update and render methods }

}

A separate generic game loop class doesn't know which methods are the render and update methods, so I have to inform the game loop class about the methods it should use. How could this be done? Maybe by wrapping the render and update methods in commands?

Another option could be to make an game loop class that implements Runnable and that contains abstract render and update methods that have to be implemented in the GameScreen class. I think this was the idea that was mentioned in this thread before. However, if I want to extend Canvas in my game class I cannot extend the abstract game loop class, but maybe I should better use Canvas as a property?

Like I always say with optimizations and designing the "perfect" system. All you are doing is getting nowhere faster and more elegantly. Get something that works and then if it is slow or too hard to use just then, you should consider a better more efficient design. As you code and recode you will get better and better. The over all design and structure of the stuff you write will naturally improve. Get something that does something first.

You don't really need to extend canvas. All a canvas is, is what its name implies. Just need to grab the graphics object in the render loop from it.

Thank you guys. Do you wrap your classes in design patterns? You could make a singleton of the game screen or wrap methods like start game, stop game, pause game, resume game etc. in command classes, but I don't know if that is making sense.

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