I was programming a simple game and wanted to display it via the Java Graphics + Swing API. It felt a little slow, of course, so I measured how long it took to repaint, which was around 32ms. Then I read about accelerated Java graphics and used the method described here: Space Invaders
However, somehow this is even slower. It now takes around 98ms to redraw. Why is that?
Note that I am aware of libraries like LWGL and JOGL, but I don't want to use a full-blown OpenGL wrapper for such a graphically simple game.
A few hints to improve performance:
Clip and just draw the area that has changed
Don't scale anything when drawing
Use the correct buffer strategy
Use full screen exclusive mode if appropriate.
Swing isn't inherently slow. Most of the confusion about Swing comes from people who don't know or understand about the Event Dispatch Thread (and yes, it's a lot of effort to get it right).
Regarding your times, are you just calling g.drawImage between the time settings? If so, what size are you repainting, and are you doing any scaling on this call?
EDIT: Forgot to mention Pulp Core - a very nice gaming framework for Java.
Read this about timers
Use an always sleeping thread in the background to lower the system interrupt rate to get much more precise timers!
You can take a look at my code in here
A small game I've created can be found here
long renderStart = System.nanoTime()
// render stuff here
long renderTime = (System.nanoTime() - renderStart) / 1000000;
Swing will be slow for a game. Your best bet is probably an SDL wrapper, such as jsdl or sdljava. SDL is quite lightweight and supported on many platforms.
The nice thing is, well-implemented 2d graphics library wrappers implement the Graphics interface, so you should be able to try several and see which one performs best for your app without modifying your code.
I am not an expert, but Java2D supports different rendering pipelines. On my machine, switching to the OpenGL one by setting the system property
sun.java2d.opengl=true
yielded a substantial increase in rendering speed.
You may look at processing.
I agree with Nicolas, for graphics / interactivity processing is great
Try JGame. It's a simple engine for 2D games which uses GL when its available and can produce games that run on anything from a mobile phone to a desktop system.
First of all, you should check and see how much time is spent in your own code vs. how much time is spent actually drawing the frame. You may have some bug or glitch that makes it run more slowly.
You should be able to get much better performance then 98ms to draw your screen. Those game libraries will probably be using the same graphics calls as you would. But which containers you use can have a big impact on how fast things draw. I remember a couple months ago working on some double buffered graphics code, and how the back buffer was created made a huge difference in performance.
In particular, make sure you only create background image once or at least, only when your canvas resizes. In my draw code I do this:
//create a graphics backplane
if(backplane == null || !backplaneSize.equals(this.getSize())){
backplane = this.createImage((int)this.getSize().getWidth(), (int)this.getSize().getHeight());
backplaneSize = this.getSize();
}
So the back plane only gets created if it's new, or if the component is resized. This has a huge impact on speed.
I've been doing graphics programming in java since JDK 1.0. Actually I'd never heard of this BufferStrategy thing. Heh.
I've never had any trouble getting good frame rates with basic java graphics calls. Another thing to look out for is making sure that Swing isn't trying to clear the background of your component for you. That can be another source of slowdown.
Java2D performance is a bit of a dark art. It can vary between platforms, but it possible to get it to perform well.
Sometimes doing seemingly innocuous things can result in much slower performance. You want to make sure that you are using accelerated images as much as possible.
The type of the image can also be significant. I don't know the full details, but I do know that my programs were much faster using type 1 images (INT RGB) than other types such as type 5 (3BYTE BGR) because of conversion issues.
I can't tell exactly what you are doing. Your question is about Swing but you mention a Canvas and Bufferstrategy. Well in Swing you would use a JPanel which is automatically double buffered so you don't have to worry about that.
I tested a simple animation with 1000 moving balls. The Timer was set to fire every 100ms. When the Timer fired, the 1000 ball where randomly moved to a new position and a new BufferedImage was created and the panel displaying the image was repainted. The difference in time between the repainting was 110ms implying it only took 10ms to create an new BufferedImage and do the painting. The painting was done a a full screen so no clipping was done.
This posting show the example code I tested.
Related
I'm making a 2D game in Java and one of the main issues causing low FPS (on my slow laptop) is having to re-draw complex structures to a Graphics instance, such as dials with markings.
The dial and its markings will never change unless the window is resized, so I thought it would be a good idea to draw to a BufferedImage and just re-draw the image rather than re-drawing the details. The position of the needle obviously changes, so this can just be drawn on top.
I've never heard about this being done to improve the FPS of 2D games so I'm wondering if it's actually good practice to store a cache of images or if there's a better way to solve this sort of problem? Are there any issues associated with this that I haven't considered?
Caching images isn't a bad idea: you can rely on raster rendering to be pretty well optimised on most any platform. In my experience (which is admittedly mostly on mobile devices where 2D graphics are concerned) the Graphics.drawXXX() methods are often considerably slower than Graphics.drawImage().
In my experience the vast majority of 2D games out there make use of sprites (i.e. images) for rendering just about everything. Often that's true even when the graphics look like they are rendered using primitives!
Another useful technique to think about is not redrawing regions at all unless you really need to!
EDIT:
As others have mentioned, the major tradeoff is that you're going to be using more memory. You're also going to have to make sure you free up those images once you no longer need them.
Is it good practice to cache parts of a 2D drawing?
You're making a trade-off between drawing speed and storage space. Only you can determine which is more important.
You might consider rendering your dials in advance and saving the images as GIF, JPG, or PNG files. You would have to scale these images to your window size before you draw them.
Are you using double buffering for your Graphics panel?
Yes, that is a good practice, and it's done all the time. Drawing to an image first before displaying it on the screen is called double buffering, and that method can be used in different ways according to the needs of the program.
The downside of double buffering is memory, since it takes more memory to store the second image, but that sounds like a trade-off you'll need to make.
I have a system in place for a game yet I don't know what I should use to display it. I am making a vertical shooter game and I have written the methods for all the classes controlling enemies and players, but I have not idea how to efficiently display the game. I was thinking a Canvas, that would repaint every frame, but is that really the most efficient method?
Important details:
ideal framerate: 25fps
It is a 2d game
There are anywhere between 25-100 objects on the screen at any one time, all of which are moving
All objects being displayed are images, all in PNG format
The window is 640px by 480px
Right now all the images are loaded as BufferedImage, although I could easily change this
7. I need a coordinate plane. This is the only fundamental part that cannot be changed without completely restructuring my code.
Most importantly the way I have everything set up, every frame all of the objects move and interact in a coordinate plane I devised (deals with collision detection and movement, no graphical component), then everything should get painted to the screen, simply by going through the ArrayLists which keep track of all moving objects and painting them one by one.
If Swing is acceptable, JPanel is double-buffered by default, and a javax.swing.Timer with a period of 40 ms will give you ~25 Hz updates. This example shows the basic approach, while this example shows a number of images in motion.
I need a coordinate plane.
It's not unusual to have the the model and view use different coordinates; all that's needed are functions to map one system to the other. In this game, the view relies on four methods that map tiles to pixels and vice-versa. The same approach is outlined here for map tiles.
You have a number of options available to you:
Firstly, you could use one of the existing Java game frameworks:
JMonkeyEngine (http://jmonkeyengine.com/)
Slick (http://slick.cokeandcode.com/index.php)
(Slick is aimed at 2D graphics, while JMonkey is aimed at 3D and uses OpenGL - While I have looked into their use, I've not actually used them myself)
Alternatively you can code everything yourself. From the sounds of things this is your first (graphical) game, so you may want to read up on a technique known as double buffering, whereby you write each frame off-screen and the just paint the whole thing to screen, as this can lead to smoother animation.
To get you into games development a bit more, I would highly recommend reading this site, Killer Game Programming in Java by Dr Andrew Davison, as he gives some good pointers, and also provides a good progressive learning path for new game developers, and moving them into 2D and then 3D development.
HTH
The answer really depends on whether this game is 2D or 3D.
If your game is 2D, an easy way to do what you want is to use Java's own 2D Graphics API. A good tutorial to start you off (at least in my opinion) can be found at The Java Tutorials. In my experience I have found that Java's graphics API is easy to learn, and is more efficient than one might expect. The basic technique is to have your game code keep track of the positions of all your objects, then translate those coordinates into screen coordinates and display appropriate images at those locations. I made a (very, very simple) game in Java once, and this is the method I used.
If your game is in 3D, OpenGL is definetly the way to go. I have only limited experience with OpenGL, so I'm not sure how easy the Java bindings are to work with. In general, 3D programming is a massive topic, so if this is a first-time project or you aren't prepared for a major time investment, I would attempt to find a good game framework to use or make the game 2D. If you are interested in OpenGL, or 3D programming in general, a quick Google turned up the JOGL project. I would recommend investigating JOGL as a way to access the OpenGL API from within Java code, but for actually learning OpenGL I recommend The OpenGL SuperBible(5th edition), commonly known as "The Blue Book".
The code examples are all in C++, but for the OpenGL functions it could possibly be just a matter of using a wrapper library. For example:
glDrawElements(...);
May become:
JavaGLWrapperObject.glDrawElements(...);
Unfortunately I can't give concrete examples because I haven't used OpenGL with a Java program, but the above example very coarsely approximates how OpenGL ES is used on the Android platform.
As far as performance... Java's API comes with a non-trivial ammount of overhead, but I could see it doing alright for your purposes. You may have to put a little more effort into making your algorithms efficient, and your game may not run as well on less-capable hardware. If you do decide to go the OpenGL route, it will almost certainly be much faster (again, depending on how efficient your algorithms are), but is correspondingly much harder to learn and get started with. Certainly doable, but it will be a challenge.
Canvas will quickly be too slow for 25+ fps targeted.
the number of object is irrelevant, what is is how complex they are.
if it is 100 images will take nothing compared to 1 3D model of Avatar for example.
in Java you can use either Opengl or Java3D
I would tend to go with Opengl as a personel choise
I have created my own canvas that has been extended from the JPanel, however I have noticed that w/ the content and so forth, that all of the sudden my FPS took a hit. I am following the swing rules from Filthy Rich Clients, by using paintComponent, creating a clip area, only redrawing what has been changed, and so forth. I have the FPS set to a constant 50 FPS, and I notice that sometimes my FPS will jump down to 31/32 FPS and go back up to 50 and so forth. While running my program it's only using about 25MB of RAM and 0 of my CPU, even when rendering. I also have OpenGL set.
Note: I have NO images, this is strictly using the shapes in Graphics.
Is there a major performance hit by drawing everything on a JPanel? Should I be extending a different component (I keep seeing Canvas component)? How "smart" is it to build a game such as tetris (or any of the other retro games) in JPanel?
It's a possibility that this is a timer issue, as I just added 100 additional painting calls and the FPS still does the 50 32/31 thing.
After much investigation I have found that the issue is not the JPanel at all. As a matter of fact, the issue is with the Timer in java. It's not 100% accurate, which has resulted in the FPS being way off. My solution to fixing this was reading this: koonsolo.com/news/dewitters-gameloop
I realise that you've found an issue with the Timer class, however I have another comment for you, which you may find useful:
You've not mentioned whether you're using the double-buffer technique. If you're not, then you may notice a FPS improvement.
Just in case you're not familiar with the technique, it involves creating a separate panel buffer, redraw your scene on this buffer, then switch this buffer with the one on the screen, etc.
I want to be able to draw consecutive bitmaps (of type BufferedImage.TYPE_INT_RGB) of a video as quickly as possible in java. I want to know the best method in doing so. Does anyone have any advice where I should start? From what I've read, 2 options are:
1) Use GDI/GDI+ routines in a JNI dll working with JAWT (Im on Windows)
2) Use Java3D and apply Textures to a Box's face and rotate it to the camera
Im interesting in any advice on these topics as well as any others.
I have done a decent amount of GDI/GDI+ programming in VB when i created an ActiveX control, so using GDI should be painless, but im guessing Java3D will utilize the GPU more (I could be wrong) and give better performance. What do you think? GDI and JAWT with my previous experience, or start and new API journey with Java3D.
Thanks in advance. :)
To obtain a fluid animation (if it what you want to get), you need to use double buffering. For doing this, you will need to create a new java.awt.Image (or a subclass like BufferedImage, or if you want OpenGL accelerated processing, VolatileImage) for each frame you want to display. If you haven't already done so, call Image.getGraphics() to get a java.awt.Graphics object (can also be useful to add your content to the Image). At the end, when you hidden Image is complete, call Graphics.draw() to replace the current display smoothly.
VolatileImage is OpenGL accelerated and much faster. When VolatileImage.getGraphics() is called, it actually returns a Graphics2D, which is also part of the accelerated graphic pipeline.
It works on Windows, Linux and Solaris, but you need to have OpenGL drivers installed for your graphic card.
Some additional refs:
Accelerated graphic pipeline:
http://download.oracle.com/javase/1.5.0/docs/guide/2d/new_features.html
http://www.javalobby.org/forums/thread.jspa?threadID=16840&tstart=0
Double buffering:
http://www.java2s.com/Code/Java/2D-Graphics-GUI/Smoothmoveusingdoublebuffer.htm
http://www.heatonresearch.com/articles/23/page2.html
http://www.javacooperation.gmxhome.de/BildschirmflackernEng.html
For my internship on Brain-Computer Interfacing I need to generate some very fast flickering squares on a CRT monitor (flickering = alternating between two colors). The monitor's refresh rate is 85Hz and we would like this to be the bottleneck, which means that repainting all squares can take at most 1000/85 = 11ms.
My language of preference for GUI/graphics programming is Java, so I tried making a prototype with AWT, because it's synchronous (unlike Swing). I now seem to have two problems: the first is that time measurements show that the repainting of even 9 squares simply takes too long. My algorithm takes the desired frequency and calculates the times at which the system should repaint in advance and then uses a loop (with no sleep/wait delay) that checks everytime if the next 'time' was reached and if so, loops through all the squares to repaint them. The way I implemented it now is that the squares are Panels with background color A and are contained in another Panel with background color B and the flickering happens because the Panels' visibility is changed. I figured that this would be faster than one Panel that has to draw Rectangles all the time.
I don't have a decent profiling tool (can't get Eclipse TPTP or NetBeans profiler to work) so I can't be sure, but I have the feeling that the bottleneck is actually not in the repainting, but in the looping (with conditional checking etc.). Can you recommend anything about what I should do?
The second problem is that it seems like the squares are rendered top-to-bottom. It's like they unroll really fast, but still visibly. This is unacceptable. What I'm wondering though, is what causes this. Is it Java/AWT, or Windows, or just me writing a slow algorithm?
Can you recommend some things for me to try? I prefer to use Java, but I will use C (or something) if I must.
I would avoid any kind of high-level "components", like JPanels and the like. Try getting a Graphics2D representing the window's contents, and use its fillRect() method.
Failing that, you could probably do this easy enough in C and OpenGL. rasonly.c is a standard template program that sets up OpenGL to work as a "rasterizer" only, i.e. 2D mode. Using this as a starting point, you should be able to get something running that draws your desired "squares" without too much trouble.
You don't describe your desired scene very well, it sounds from that equation as if you want to draw 100 squares, each having a different color. For maximum performance in OpenGL, you should draw all squares of the same color together, to minimize the "state changes" between drawing calls. This is probably a purely theoretical point though, as drawing 100 2D squares at 85 Hz really shouldn't tax OpenGL.
UPDATE: Oh, so it's been a bunch of years, and nowadays you probably need to take the above with a grain of salt and read some modern tutorial. Things have changed. Look up the Vulkan API.
(I remember a demonstration of this using the BBC micro and palette switching, though that would be 50fps rather than 85, as it was a British domestic TV)
I'd switch to jogl and use display lists. They get very high fps rates in Java.