This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Dot n Munch: Postmortem

Dot n Munch

My wife, Miho, was pretty busy with kid's school work, taxes and what not, so I thought that I would make a game that was super easy to tied me over before I got help with the art work. If the wife is happy, I'm happy.

I decided to make what I thought would be a simple game. It was a timed, "fit the piece in a hole" type of game, giving me hopes of advancing my skills and increasing my reusable code. In particular, I wanted to develop a level manager, something that would display unique splash screens, then load the next level, then display a different fail or try again screen.

The Good:

1. Improved my classes.
2. Improved my state machine.

The Bad:

1. Time estimate was off.
2. Did not reuse my sprite class for collision detection.
3. Not that excited about the game.
4. Adding complexities did not work out.

The Good:

1. Improved my classes.

This is pretty minor actually. I cleaned up my timer and frame rate classes. My favorite class by far in this whole game is my BubbleChat class. Basically it reads the size of the text and puts a bubble around it with a pointer to the sprite who is talking. It can contain up to four lines of any length. I can change the color and what not.

2. Improved my state machine.

I was really hoping for a nice segue to my next game, Pixel Rescue. I wanted to become comfortable with loading levels and scripting them to what I wanted to do. This was a semi-success.

I set up a very nice scripting for the talking dot. It is a simple state progression. Probably along the lines of how I would set up some scripting. State is progressed when timer is done.

private void draw1 (Graphics2D g2d){

    // move over to the center
    if (state == 1){
        x = player.getX() + 4;
        if (x > 388){
            x = 388;
            chat = new BubbleChat(x,y, Color.WHITE, "Hi there!", "Please don't let me get crushed.");
            timer = new Timer(messageDelay);

        y = player.getY();

        player.set(x, y);

    // say hello for timed period
    if (state == 2){
        if (timer.done()){
            chat = new BubbleChat(x,y, Color.white, "Use your arrow keys to", "move me to a safe spot.");
            timer = new Timer(messageDelay);


    if (state == 3){
        if (timer.done()){
            chat = new BubbleChat(x, y, Color.white, "Good luck!");
            timer = new Timer(messageDelay);

I did not get the level loader quite to where I wanted. It progresses but not as cleanly as I would like.

The Bad:

1. Time estimate was off.

Game number two in java for me, and I still can't estimate how long something will take. I estimated a week and again I'm at two weeks with many more hours than I expected. On the inside I even told myself this should take 20 hours. The two biggest delays came from collision detection issue and motivation. There was also a lot of sitting and staring at the game, thinking to myself "how can I make this better?"

2. Did not reuse my sprite class for collision detection.

Since I was not going to rely on Miho's artwork this time, I used Java2D to create my polygons. I went too simple and ran into major problems. The bottom line is testing for an intersection of two polygons might work for hitting something but if you need to bounce back, it doesn't work well because it doesn't provide directional information. It much better to use the sprite approach of testing edges. If the left edge has passed the right edge, then move the sprite right. This works.

I spent a lot of time trying to guess at the direction and counter directions. Then the keyboard input created a bit of lag time so I could never ever get it working perfectly. I went back to the sprite style of checking edges and that fixed nearly everything. There is still a small problem when two sides are over at the same time but it doesn't seem to effect game play much. I'll have to see if someone complains during the feedback phase.

Not using my sprite class from Subby and the Fishes seemed to be dumb decision as I had to rewrite and troubleshoot a bunch of code.

3. Not that excited about the game.

The game is okay. I've tried to make it funny and as addicting as possible within a very confined design space. However, I'm just not that into it. Working on the collision issues for over a week was really demotivating for me. I was thinking "I don't like this job" when I should have been thinking "this will be so cool when I'm done." Procrastination and avoidance added several days to the development time.

The funny thing about it is that I could have sworn I had spent four weeks working on the game but when I look at my completion date for Subby and the Fishes, this one was only two--but sure felt like four.

4. Adding complexities did not work out.

Firstly, there were just general design ideas, not really thought out, so no reason to implement things like slippery movement or bouncing. The game is more about finding the spot rather than motor skills.

Second, I am happy to be done.

Best Java Games

Best Java Games

I'm a little bit cynical about developing in Java. It is such a nice language, but I find myself having hard time finding games that are developed in it. With flash, I can find 2,500 games in an instant. With Java it took me several hours to find 300 or so. Not sure which comes first here, the chicken or the egg.

Here is a listing of the best and most successful Java games I've found.

Subby and the Fishes
Bang Howdy
Alien Flux
Puzzle Pirates
Tribal Trouble
Coke and Code Games
Erik v Erik is my favorite here
Arcade Pod has bunch
Java Game Tome has even more
Dan Ball Very cool physics


Call of Juarez
Titan Attacks
Star Wars Galaxies
Kingdom of Wars
Law and Order II
IL-2 Sturmovik
Galactic Village
Wurm Online.

Subby and the Fishes: Postmortem

So how did the development "Subby and the Fishes" go. My goal was to write a simple applet game that could be sold to advertising based sites. Lets review 10 things that went right and 10 things that went wrong on the development.

The Good:

  1. Starting with a small project.
  2. Choosing Java2D over 3D.
  3. Rewriting to make code more elegant
  4. Having other people play it.

The Bad:

  1. Estimate to completion was completely off.
  2. No refined sprite class.
  3. No refined sprite manager class.
  4. Display class was not abstracted

The Good in detail:

1. Starting with a small project.

Starting with a small project is just about the best thing a programmer can do. We all want to make an even better World of Warcraft but this isn't the way to go. First progress is immediate. It is quite motivating to see the game become better and better by the hour. I found the how to write an RPG in 40 hours quite inspiring.

Second, it is much easier to rewrite your code. If you did something wrong with the structure, you only need to refactor a few classes versus thirty or more. I think rewriting for elegance is key. With a big project, there is just no time to rewrite with huge pieces of code. My first rewrite and reorg took almost 8 hours on a very simple game. I hate to think how much it would have taken on a larger one.

Third, feature creep is limited. For example, my sprite class resizes, animates, and alpha blends. It does not flip, rotate, or force pixel colors. At some point I will want to add these features but they are not needed for this game. Each would probably take me hours to complete if I implemented properly with speed tests.

Fourth, there is little to no artwork delay. Art takes a long time to make and can be expensive. It can be quite quickly developed. In my case, my wife, Miho, can knock out most of the sprites in a weekend.

2. Choosing Java2D over 3D.

This could probably be retitled to "Go with what you know." In my case, I've spent a month playing with Java2D. It is familiar, and there are a ton of excellent tutorials on the subject. JOGL looks extremely attractive and will probably be the only way to go in the long run for developing desktop applications. However when I sat down to try to learn it, I found myself wasting valuable time. It was going to take me a month to become quite comfortable at least.

I also felt like I had more important things to learn like object orientated structures, sound, map management, user input. Kevin Glass has a nice tutorial that abstracts the display of the game from the game itself. Flip a switch and run JOGL, Java2D or LWGL. I'm still deciding if I should go this far perhaps as a final rewrite.

3. Rewriting to make code more elegant

I can't say enough about this. Since it is a small game, there is time to go back and make it right. For me, my first rewrite was to make reusable sprite and sprite manager classes. Maybe this is just good object oriented design but it was a first for me and I love the way it turned out. I can now add sprites in a matter of minutes. My code is much easier to read.

A spin off of the sprite class was to create a resource manager for the art work. It was simple hash map that loads everything into memory. But it sets up my sprite manager for timely reads so I don't have to wait for hard drive loading. It also sets things up for later if I ever need to manage video or PC memory with a large game.

4. Having other people play it.

Feedback is invaluable, no matter how hard it is to listen. About 10 people played it on JGO, finding bugs and making excellent suggestions with regards to speed and difficulty. What was also quite important was that I was able to pare down my TODO list just to get in what players wanted.

The Bad in detail:

1. Estimate to completion was completely off.

My original estimate was one week. Total time was four weeks, working part-time, nights and weekends. Rewriting the code to make in organized well took a week and half alone but improved my programming skills. The sound was a bit of a nightmare. I originally tried to add some music but the EasyOgg and another free library have major bugs in them, making them scratchy and bugging on different operating systems.

Here is the list of things that took longer than I thought.

Rewriting the code 1.5 weeks
Reorganizing the code 2 hours.
Sound and music 1 week, OGG never worked.
Compiling for Java 1.5 1 hour
Art mistakes 2 hours

2. No refined sprite class.

I spent the most time working out a nice sprite class. This took a long time to get it perfect. The nice thing though is that is completely reusable. I loved the fact I can add sprites in minutes.

3. No refined sprite manager class.

The overall structure of the code could still probably be improved. There are controllers and actors. Then there is a controller for the controllers. The first time going through this makes it a little confusing as to what controls what.

4. Display class was not abstracted

This is more of an I wish I would have thing. I wish that my display class was setup perfectly for a JOGL or LWJGL conversion. I'm very curious to see how much more speed I would have with these in place. 33 FPS cap just doesn't seem that good. However, no one that played it really went lower.

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


// 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


Result second test: 1305.4

// Oddly enough faster than the above method.  This is what I use.
                40, 40, 40+224, 40+30,   // destination, scalable
                0, 0, 448, 59,  //source on sprite

Results: 1309.8

Results: 1313

// 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

Finish Damin it!

While looking at books at Amazon, I found an forum discussion that posed the question, "Can a self taught programmer get a job?" The answer was a resounding yes but with a few caveats. Note I'm not really interested in a job; I'm interested in making games which requires being a good programmer. So the discussion was pertinent to my goal and steps that I should take.

The first thing that was rejected was the idea of certifications, most saying they are waste. (My guess is that this is only partially true because you just never know if one word on your resume makes a difference or not to the person screening.)

There also seemed to be a couple of tiers of programming complexity. Many programmers posted that they never used linked lists or hash tables, mostly focusing on the user interface and web side of things.

Others seemed to have quite challenging, problem solving jobs. Programmers seem to come from many different backgrounds, and their performance, and pay, has little to do with their college degree.

What was more relevant to this blog is that several coders said the key to getting yourself trained came in three parts.

1. Finish projects.
2. Learn everything you can.
3. Make your code elegant.

I think there is another important piece to that was stated by Peter Norvig who discusses the foolishness of learning a programming langue in 21 days. He points out that it takes time to master something. So lets add this as the four key to learning programming.

4. Stick with it.

With these four items in mind, let me go over them as they pertain to me. I started programming in Java in mid January of 2009.

1. Finish projects.

This really was a very nice wake up call for me. Taking a hard look at the files on my hard drive and the date, I'm was sitting at about three months since I started learning Java with one semi- playable game and quarter of a playable game. Not good. No finished projects. With this is mind I put away my space game and decided to make something simpler that could be finished. Now it took me over a day trying to figure out what that something was but it was well worth it.

2. Learn everything you can.

As for the learning side of things, I've actually done pretty well. My speed has increased. I've learned more than I ever imagined. Programming is not for the feint of heart. Game programming is only for the brave because it is actually very complex. Currently I'm dreading learning sound for my games. It looked like at one time there was a very nice interface for it but has since been depricated.

But on the positive side of things, not only have I memorized a ton of java syntax, object oriented programming is starting to make sense to me. Abstracting class and making re-usable code is becoming fun. I've become comfortable with Java 2D and have a fair understanding of swing.

When I think about the sound api for my game, in some ways this conflicts with number one. I really don't want to learn how to code sound API. It is one of those things that seems so simple to use. Play this sound once with this animation, or loop some background mood music. Of course you can set up a mixer to play multiple sounds at once with time delays for background moods but really it is just play and loop. But it is quite difficult to build an Ogg streamer. The wav player seems reasonable but even then there are many reports of crackling as well as mix problems. There are also threading issues. So my dilemna is whether or not to hire someone to write the code for me, thus completing my first goal of finish damn it. But at the same time it defeats my goal of learning everything I can.

3. Make your code elegant.

What about elegance? I wasn't quite there. As the blog stated most beginner coders probably don't even know what elegance means in terms of code. I think this probably a pretty fair statement; however I do know that in writing elegance can be gained through a lot of hard work and rewriting. The same seems to be true of coding.

With this in mind, I spent an entire week reworking the Subby code just to make it feel better, make flexible, organized. I looked for patterns in my code and tried to turn those into abstractions for reuse.

The greatest sucess I had in this area was my sprite and sprite manager classes. They were readable, documented, extensible. I had a nice little frame work to add different sprites in a manner of minutes.

4. Stick with it.

This is by far my worst issue. Typically I can dive into something for a few months, then get distracted by something new. Oh, look how cool is that thing over there! This time though I've promised myself to stick with it for a year.

I did have a three month lull but I just took a week and half off then came right back to it, quite refreshed.

Timers: Part Two

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);

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.


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.


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.


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.

Need to figure this out.

Timers: Part One

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.

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%.


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.

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.


  • 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

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.


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.


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) {}


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.addWindowListener(new WindowAdapter() {  // a new way to close
public void windowClosing(WindowEvent e) {

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

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

// make it fast with this strat
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.fillRect(0, 0, CANVAS_X, CANVAS_Y);

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

// finally, we've completed drawing so clear up the graphics
// and flip the buffer over

// 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();



2d tests using pixel draws not quite what I'm doing but a good start

How to open the Opengl Pipe and logs. Also include D3d.


Explanation of VolitileImages

Ibm's example of frame double buffered

Finding the right 2D Engine

I spent alot of time getting Java 2D to work for my next game. There were some amazing tutorials out there, especially those done by Kevin Glass at http://www.cokeandcode.com/. However, when I did a test rendering a large screen (1024 x 768) with four parallax layers my FPS dropped to about 20. With map display optimization I could increase it to 42 but still I wanted to do a 2d engine 1900 x 1200 with a good frame rate of lets say 100. My home computer runs a radeon 3800 and my old work lap top a couple of years old couldn't even achieve 10 fps. So 40 on a pretty robust machine was just not enough.

What are the options?

A. Use a third party Game Maker.

B. Use a third party Engine.

C. Write my own Engine.

D. Optimize Java2d Engine.

Before looking into all three of these options, I should probably decide what I want. Lets start with the dream list.

Dream 2D Engine

Fast Frame Rate at high resolutions 100+
Full screen, windowed or browser embedded
Multiple OS Windows, Mac, Linux.
Sprite Engine including a sprite manager database
Graphic alpha blending, rotation, gamma controls
Map Manager
Map Editor
Flexbile maps: Baldur's gate style, Zelda style 2d, Mario style sidescrolling, Diablo isometric.
Parallax Scrolling
Scripting Extensible for adding maps, levels, art.
Widgets for the GUI
Sound and Music
Database reader/writer
Package maker for art and sound
Collision Detection

Not too much to ask for is it? :P

Other Requirements
Low cost, prefer free.
Great tutorials.
Published games
Maintained and active.
High quality community.

Coding Language

There are only a few choices for coding games and each has its advantage.

  • C++
  • C#
  • Flash (Actionscript)
  • Java
  • Others

C++ is the language of game makers. It is an old language and is quite difficult for the non-professional programmer. The memory management is a real pain for myself. I've done a bit of coding in it--half a game--and just ended up getting a bit frustrated. I also do not like Microsoft's implementation of web launch. That being said, it is still king of the game languages and most coders can make it sing and dance. It can be ported to other platforms but generally speaking there are issues. Decision: Rejected.

C# looks really good. It solved MFC mess and handles the memory management much better. However it is tied strongly to windows and is not as portable as others. The IDE is reasonable but still costs. Decision: Rejected mostly because of IDE and portability.

Flash is a winner. It is on every system with an Internet connection. It is popular with great tutorials. Publishing looks very easy. There are third party agents that automatically find you place to generate advertising revenue. The downside is that the IDE is expensive and proprietary. Another downside is that Flash is not suited for those ginormous, pipe-dream games that require major networking and 3D. This can be a pretty important decision depending on the games you are building. I've seen some very successful indie game makers build one game over and over again improving it with each version. The same can be done with Flash of course but it will never be a triple AAA title (see Fantasy Tactics and Sword and Sandal). Decision: I'm going to hire someone to port a game to test the market. Revenue seems almost exclusively ad based although some do have license locks.

Java should be a winner. Why it is not an instant winner seems to mostly come from a false rumor about it being slow. Yes it is a bit slower than C++ but the reality is any game you love to play can be written in it. The web launch is slick. The IDEs Netbeans and Eclipse are both free. I'm partial to Netbeans. It has applets. How cool is that? However I did notice on a recent visit to the Yahoo game's portal that it is almost all Flash whereas 3-4 years ago there was a healthy mix of Java. David Brackeen wrote a slick applet game called Milpa as well as a good java book called Developing Games in Java. The game is similar to some popular Popcap games but he still made a few thousand on it. Decision: For better or worse, this is the language of choice for now mostly because of price, great community, web integration, portability, and ok tutorials.

Others include Delphi and VBasic. I programmed a Simon Says game in Delphi, selling one copy! It is quite usable but at the time I used it the graphic libraries were terrible. Both can work with OpenGL and DirectX. I'm not sure about the portability issues. They are quite old languages. IDEs are free which is nice. Decision: Rejected for portability and lack of web launch.

Before I pare down the dream list alot, let me quote some forum wisdom.

You cannot create a generic network engine/library. There's no shortcut. You have to understand the problem and write the solution. Anyway, stop putzing around and dive right in. You'll never figure this out if you keep waiting for a magical library to fix your problems for you. Backov writes http://forums.indiegamer.com/showthread.php?t=14146

I took a look at some cool scripting engines like RPGVX which is extremely enticing. It comes with an editor, Ruby, artwork, sound, just about everything you need to actually make an old schoool RPG. The two major issues I had with it was the screen size is limited to 640x480 (note the older version RPGXP which has better artwork is even smaller screensize) and the second was that I would have to master Ruby, the scripting language.

Game Creators





RPG Maker

C++ Engines/Graphics

These have been eliminated because they use C++ which is an older language and mostly focused on the Widnows platform.