Drawing Sprite Speed Test

In an attempt to make my code a bit more elegant, robust, and fast, I've started review my newly created Sprite class in detail. I included percentage resizing and alpha blending. I chose an easy way to alpha blend but had two choices on how to resize my images. I started to become curious:

What is the best way to draw my sprites in Java 2D?

I turned off my sleep timer in the game loop and then drew a 59x448 pixel index image on to my canvas. Note I tried the same image as RGB and had scary slow downs. Making sure your art work is all indexed will be your greatest speed boost by far.

The results where interesting.

Resizing causes a much greater hit than alpha blending.
drawImage(img, destination, source) was slightly faster than drawImage(img, destination, size)

Here are the details in milliseconds over 10 seconds.

// As fast a you can get. Used whenever the others are not required.
g2d.drawImage(buffImg, 40, 40, null);

Result: 1381.4

1375
1390
1378
1378
1386


// Slowest draw. Half size, setting width from 448 to 224, and height from 59 to 30.
g2d.drawImage(buffImg, 40, 40, 224, 30, null);

Result: 1313.6

1292
1374
1298
1290
1314

Result second test: 1305.4
1310
1298
1307
1302
1310

// Oddly enough faster than the above method.  This is what I use.
       g2d.drawImage(buffImg,
                40, 40, 40+224, 40+30,   // destination, scalable
                0, 0, 448, 59,  //source on sprite
                null);

Results: 1309.8
1303
1307
1301
1311
1327

Results: 1313
1320
1286
1319
1339
1301

// Sets alpha blending to 50 percent. Not as bad as expeced but changing the composite 100 times would be terrible.
g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 0.5f));
g2d.drawImage(buffImg, 40, 40, null);
g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 1.0f));

Results: 1366.2
1360
1376
1364
1368
1363

Read More

Timers: Part Two

Timers:
Part One | Part Two

Lets start with a review of Part One.

• Any increments of 10 ms jitters Java on Windows.
• High frame rates are not as important as smooth graphics
• The loopGame delay smoother must never be negative.

With this in mind, I've decided to build a simple but real game called "Subby and the fishes." For the beginning of my development, I was setup on my desktop PC. With my delay smoother set to 21 milliseconds and a hefty graphics card, a Radeon 3800, everything ran smoothly.

Once I moved the code over to my laptop with the Intel video chipset, my delay smoother started hitting negative numbers again. My output was 21, 6, 6, -7, 21, 21, 6. I watched the screen and sure enough the bubbles I had floating up on the splash screen jittered. Bah!

I had to up my delay up to 31 milliseconds. Note I couldn't do 30 because of the Java bug that causes more jitter.

long sleep = loopTime+31-System.currentTimeMillis();
System.out.println(sleep); // check to make sure never negative
try { Thread.sleep(sleep); } catch (Exception e) {}

Ok now I viewed the screen. Still jittering...what the hell.

I checked to make sure my animation was using the smoother. Yes, my move smoother was using the timeLapse variable of the game . Now, when I thought about it, something didn't make sense. Since my game loop was smooth, in other words, never negative, that meant that the time lapse variable I sent to move things should be pretty darn close to constant.

delta = (int) ((timeLapse * speed) / 1000);
System.out.println(delta);

It should be constant but it wasn't. It was all over the place with an output of variance of 6 pixels. Wow, it was terrible. Time to research. Hours later I found David Holmes blog.

http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks

Okay it has a ton of information and I'm thankful for it. It just strikes me that if Java was serious about becoming a major gaming platform they would come up with a better than C++ solution for timers. One can only dream right?

So what in the article is useful? I decided to try to force high resolution and recheck my movement delta.

--xx:+ForceTimeHighResolution

My output was perfect. 14, 13, 14, 13, 14. All the movements were within one pixel of each other and looked much smoother.

So for the time being a delay of 31 milliseconds and forced high resolution timer seems to be good enough of my lap top. I really want to test on some even slower machines to make sure my smoother delay is large enough but I'm going to wait until the game is more complete.

NanoTime

I wrote a nano timer as well but had the same poor results. Since the resolution of the the thread.sleep is in milliseconds I think milliseconds are probably the best resolution you can hope for. I also found the manipulation of nano time more than a little annoying. It was very hard to tell how many zeros in the code. 1,000,000,000 is fairly easy to read but 100000000 is not--note the error. Writing 1000*1000*1000 seemed awkward.

I also made a half hearted attempt at using the delay. However, I would have to set up my animation code quite a bit differently to use this. At first brush, it seems like this would make my code simpler but it is not the way I've implemented my animations. Perhaps in the next game I'll try this loop from the outset.

I've tried GageTimer as well as per Kevin Glass's recommendation. However, I found it just as varied as writing my own.



Notes and Links:

Here are some things I'm still trying to organize.


http://stackoverflow.com/questions/351565/system-currenttimemillis-vs-system-nanotime
Need to figure this out.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6435126

Read More

Timers: Part One

Timers:
Part One | Part Two

I've had to learn more about timers than I really wanted to. My testing gave quite confusing results, so I had to dig into the issues and was not very satisfied with the answers. The bottom line is the resolution of Java timers is not very accurate because Java doesn't play well with Windows processor in a multiple processor architecture. Mac and Linux are fine, even with multiple processors, according to many other game programmers. It seems that Windows will sleep processes in different areas of the processor or even in different processors effectively blacking out the timer so Java does not know how much concurrent time has passed. Estimates seem that these blackouts can vary wildly from 2 to 20 milliseconds. This causes both inaccurate FPS reporting and jitters.

100 FPS and the Jitters

My basic millisecond counter counts the number of times the game loop loops in 1000 milliseconds or one second. To display smooth animations and movements, we need movement and frame rate to be constant over time. The easiest example is movement. Lets say I want to move a sprite across the screen 10 pixels every 20 milliseconds. In a perfect world, it would look like this. The velocity, rate times time, is constant and smooth to the eye.

Time: 20 40 60 80 100
Move: 10 20 30 40 50

Now if there is a delay in the game loop due to processing requirements or a poor resolution timer, the velocity become jittery as well as change speeds, either increasing or decreasing.

Time: 15 50 80 95 130
Move: 10 20 30 40 50

In the above case, the animation not only stutters but arrives late to the destination point. In a perfect timer world, this can be smoothed out by sleeping the game loop for constant amount of time. Mark the time at the very beginning of your game loop. Subtract the amount of time at the end of the game loop. This will give you a negative number. Add a delay that is greater than the negative number and viola you have smooth graphics. The game loop is always performed at the same time.

long sleep = delay+ loopTime-System.currentTimeMillis();

Now if my sleep interval is negative, I start getting the jitters on the display. If I don't put any sort of delay in at all, I can get 500 FPS or more but here come major jitters. Now you will notice if I'm always sleeping for 30 milliseconds for every loop with a positive sleep number calculation, my FPS will be around 33 FPS and never more. 1000/30 = 33.

My dreams of 100 FPS are starting to fade. The only way I can achieve 100 FPS is if my delay is set to 10 milliseconds. 1000/10 = 100. That means for any amount of processing, map rendering, sound, path finding, my PC only has 10 milliseconds to calculate it all. I did a quick test on my home computer and found some bugs in Java. I went to 9 milliseconds and it worked fine with a 1000 sprites. However on my lap top, even with very few slights I was starting to see a jitter of +/- 15 milliseconds. So the minimum delay for my lap top is about 20, depending on what other slow downs my engine introduces.

On a positive note, I did some research and the human eye does pretty well with anything around 18-24 FPS similar the the speeds of video and film. Of course there are a lot of exceptions on how the eye works in the real world like blurring which is not possible on a monitor. One interesting thing that seems pretty important is refresh rate of the monitor versus what is displayed on the screen. The eye actually becomes tired when these two things are different. For example if your screen is refreshing at 72hz or 72FPS the optimum for the game would 72 as well.

Assuming that your game can run smoothly without jitter, the best way to set your frame rate would be dynamically at the screen refresh rate. Another way to approach this, would be to test your worst processing moments (when your game loop is slowed to the absolute maximum amount for that pc) and then set your delay to a value greater than this maximum processing delay by a few milliseconds. It would be very cool to do this dynmanically. Something like set to delay to whichever is worse, process delay or screen refresh rate. At some point I may try to implement this, depending if Java 2D gives me enough wiggle room.

In the mean time, my desktop pc runs fine at 9 millisecond delay, even with a thousand sprites. For fun I tested 10,000 sprites and could still set a delay at 25 before going negative. Note I will discuss the Java/Microsoft bug of 10 milliseconds increments in the next part. However on my laptop 9 milliseconds gives me a negative sleep number. At 20 delays were 4, 4, 4, 4, 3, 4, -5, -5, -5, -6, 3 6 per loop. For even a pretty small amount of blitting I had to set delay to 30 to avoid negatives, pushing my FPS down to 33.

Bollocks! My dream of 100 FPS is gone. But games are vain. How a game looks is extremely important to gamers. My new mistress is smooth, sexy graphics. With that in mind, I'm happy to divorce my original goal of speed at any cost. We do have a new rule though.

Rule: Sleep must be positive for all target machines.

I have a feeling that this is going to be hard to figure out when a game is completely flushed out. I think the maximum delay that I would like to go would be 50 which gives 20 fps. I really prefer though to keep the FPS as high as possible, as close to the refresh rate as possible.

Read More

OpenGL and D3D Pipeline

OpenGl Pipe versus D3D Pipe:

On my desktop, OpenGL showed no performance increase. However, turning off D3D gave a huge speed hit, dropping FPS by 30%.

-Dsun.java2d.d3d=false

Unlike "-Dsun.java2d.opengl=True" where the capital "T" in true lets us know if it is initialized in the IDE, -Dsun.java2d.d3d=True doesn't let us know if it is connected. I have Direct X 9 on both of my test machines. Oddly only my desktop takes the speed hit when I turn off D3d. If I turn it off on my laptop, frame rate remains the same.

So I did an interesting test on my desktop, turning off D3D and turned on OpenGL and found no difference in FPS.

-Dsun.java2d.d3d=false -Dsun.java2d.opengl=True

On my laptop, OpenGL failed to load completely. Researching the issue I found that Intel chip set and OpenGL rarely work together.

I think the only problem with my testing is I'm not using a game that uses heavy graphics yet, only a few 100 sprites. I will have to revisit the test once I start pushing the graphics card more.

Read More

Optimizing Java 2D for a game

I like Java 2D. 3D engines seem overwhelming for me at the moment despite the fact that the pros say OpenGL or an OpenGL wrapper is the way to go. I'm a firm believer that 2D art still rocks hard with the right artist. The "Mona Lisa" was not tossed out of the museum when "The Thinker" statue was added to the collection. The question is can I do a large screen implementation that is fast enough for most computers. I have my doubts that it will be fast enough but I'll let the numbers decide.

Goal:

• 100 FPS with a reasonable animation smoothing delay of 10 ms.
• Screen size 1024 x 768 and greater, hopefully 1900x1200.
• 32x32 tiles with multiple layers.
• One background
• 2 Parallax backgrounds.
• Mode: Windowed. If Linux supports fullscreen, I'll test that as well.
• Do a little bit of alpha blending

Ideas for improvement:

• Force OpenGL and D3d Pipelines
• Test Timers
• Test VolatileImage
• Optimize Code
• Try different blitting techniques.
• Try different art formats, png, jpg, bmp, gif with different depths.

Test Environments

Publish Post

a) Desktop Radeon 3800 with 512mb of ram. 2 gigs memory. Windows xp pro.
b) Laptop Intel Chip set. 1 gig of ram Windows xp pro.








Another




I need to sleep my game loop for time than the processing time of the game loop.


Changing of my original goal of 100 FPS was quite surprising to me. Over the years, several gaming buddies and I have had silly competitions about who gets the most FPS out the game we play. Basically, FPS is not a true
representation of how smooth the graphics really are.

Problems

Jitter
System.currentTime() & nanoTime not accurate on Windows
Thread.sleep() not accurate on Windows, probably related to above.
Third Party timers inaccurte.
Bugs in Java

Jitter: Jitter is basically the varying time lag between paints. It is caused by several things, bugs, poor resolution of timers, Windows issues, and implementation.





I was System.currentTimeMillis() for my timer, thinking it really doesn't matter that much. I began playing with it and noticed if I set my delay between 5-13 milliseconds I saw no change. Weird. I then moved the delay to 14 and presto my FPS went from 65 to 70. I assume what this means is the inaccuracy of the timer was causing a delay in display. To test this I'm going to add a third party timer.

I tried using the GAGETimer a free timer. With the same resolutions of delay, I was getting about 1% improvement. Ok that is a bit strange, maybe a math difference.

Then I plugged in the number 10 a few times. I got totally random results.

I'm using the standard Kevin Glass setup with a delta with non-recommended System.currentTimeMillis

try { Thread.sleep(loopTime+10-System.currentTimeMillis()); } catch (Exception e) {}

Results

1) Framerate changes drastically everytime I run the test even though all I'm doing is drawing tiles and backgrounds. Sometimes it is 65 fps and others 94.
2) For some reason setting the delay between 9-12 seems to have little effect on the frame rates.

Question: Why does the frame rate vary everytime I run it?

Okay so now I throw out the System.currentTimeMillis and go to the Gage timer.

try { Thread.sleep(loopTime+10-SystemTimer.getTime()); } catch (Exception e) {}

I still get random results but I got a slight improvement by not using 10. 9 gave me an awesome frame rate. 105! woot this was the number i wanted. Even 11 gave me frame rates in the high 80s. 10 gave me 65.

Lets see if I can do better with the nanotimer.



Test number 1:

import java.awt.Canvas;
import java.awt.Color;
import java.awt.Graphics2D;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.awt.image.BufferStrategy;
import javax.swing.JFrame;
import javax.swing.JPanel;


/**
*
* @author Darrin Adams
*/
public class Speed extends Canvas{

private BufferStrategy bsStrategy; // fast flips
private boolean bRunning = true; // main loop
private static final int CANVAS_X = 1024;
private static final int CANVAS_Y = 768;

public Speed (){
//  Frame Setup
JFrame frame = new JFrame("Speed Test");
frame.setBounds(0, 0, CANVAS_X, CANVAS_Y);
frame.setLayout(null);
frame.setLocationRelativeTo(null);
frame.setResizable(false);
frame.setVisible(true);
frame.addWindowListener(new WindowAdapter() {  // a new way to close
@Override
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});

// Panel added
JPanel pane = new JPanel();
pane.setBounds(0, 0, CANVAS_X, CANVAS_Y);
pane.setLayout(null);
frame.add(pane);

// this Canvas added
setBounds(pane.getBounds());
pane.add(this);
setIgnoreRepaint(true); // active painting only on canvas, does this apply to swing?
requestFocus();  // get focus for keys

// make it fast with this strat
createBufferStrategy(2);
bsStrategy = getBufferStrategy();
}

public void loopGame(){
// Timer and FPS
long loopTime = System.currentTimeMillis();

int fps=0;
int frames=0;
long startTime = System.currentTimeMillis();

// TODO remove this external timer for weapons
long shotTime = System.currentTimeMillis();

while (bRunning) {
long timeLapse = System.currentTimeMillis() - loopTime;  // used to move objects smoothly
loopTime = System.currentTimeMillis();

Graphics2D g2d = (Graphics2D) bsStrategy.getDrawGraphics();

// Wipe
g2d.setColor(Color.black);
g2d.fillRect(0, 0, CANVAS_X, CANVAS_Y);

// fps counter
if ((System.currentTimeMillis() - startTime) > 1000){
   startTime = System.currentTimeMillis();
   fps = frames;
   frames = 0;
}
++frames;
g2d.setColor(Color.green);
g2d.drawString("fps: " + fps, 5, 30);


// finally, we've completed drawing so clear up the graphics
// and flip the buffer over
g2d.dispose();
bsStrategy.show();

// Attempt to sleep for a consistant time. Smooths out bumps in processing.
try { Thread.sleep(loopTime+10-System.currentTimeMillis()); } catch (Exception e) {}
}
}

/**
* @param args the command line arguments
*/
public static void main(String[] args) {
Speed game = new Speed();
game.loopGame();
}

}

Reference:

2d tests using pixel draws not quite what I'm doing but a good start
http://www.yov408.com/javagraphics/javagraphics.html

How to open the Opengl Pipe and logs. Also include D3d.
http://java.sun.com/j2se/1.5.0/docs/guide/2d/flags.html


http://weblogs.java.net/blog/campbell/archive/2004/11/behind_the_grap.html

Explanation of VolitileImages
http://www.javalobby.org/forums/thread.jspa?threadID=16840&tstart=0

Ibm's example of frame double buffered
http://www.ibm.com/developerworks/java/library/j-mer04293.html

Read More