Java Frustration

I have a slow machine (PIII 500Mhz), so it was really not running smoothly.

Maybe there are some techniques you are not using? You are of course using doble buffering. Are you using frame rate synchronization? And remember to reuse your objects. Every time the garbage collector runs, the applet freezes. So if you reuse all your objects, the GC don't run that often.

Maybe there are som errors in the paint loop, the order of which you clear, move, paint etc. Because I have a slow machine and wanted my own game to run smoothly on it, a also used a lot of time to make it run smoothly.

My game is in a way similar. A have a solid color background, and stars moving like your lines. And a spaceship moved by the arrow keys like your ball.

If you think my game runs smoothly, I could send you the source.

www.fnfconsulting.no

Hallvard

hal2000@suna at 2007-7-16 2:44:51 >

I looked at your code (GLApplet.java only), here's a few comments that should give you the red light that you're pulling Java by the feet and watching it trip.

Here's issue number one:

protected BufferedImage staticBackground, outOfFocusImage;

from what I saw, staticBackground is just there to clear the screen? BufferedImages can delay your game pretty good, so you should avoid using them when you don't need them. In this case if you need to clear the screen, call fillRect() in Graphics...

as far as outOfFocusImage is concerned, why do you need to strangle the memory with another BufferedImage just to display 3 or 4 string saying focus is gone. Instead, keep a boolean in memory indicating if you have focus or not. Then during paint, check if you have focus. If you don't, draw the strings with the current graphics object. If you do have focus, draw the game like normal.

So with those needless BufferedImages out the way, that should clear up some delay.

Now this next optimization probably won't show a huge speed difference, but you can do it anyway. Here's your method for drawing text in the middle:

public void drawMessageTextInMiddle(Graphics2D oofG2D, String string, int y) {

int offset = 0;

for (int i=0; i<string.length(); i++)

offset += oofG2D.getFontMetrics().charWidth(string.charAt(i));

oofG2D.setColor(Color.darkGray);

oofG2D.drawString(string, (getWidth()-offset)/2-1, y-1);

oofG2D.drawString(string, (getWidth()-offset)/2+1, y-1);

oofG2D.drawString(string, (getWidth()-offset)/2-1, y+1);

oofG2D.drawString(string, (getWidth()-offset)/2+1, y+1);

for (int i=1; i><6; i++)

oofG2D.drawString(string, (getWidth()-offset)/2-i, y+i);

oofG2D.setColor(Color.green);

oofG2D.drawString(string, (getWidth()-offset)/2, y);

}

That code has alot of dividing by 2 in there. Since you know you're gonna be dividing by two, you can save the computer some mathmatical frustration and not make it do as much division. Instead, you can bitshift. Bitshifting is faster because the computer isn't calculating, it's moving bits around. You can replace /2 with >>1. It's smart to put parenthesis around this because >> has low precedence. For example:

n = width>>1-1

is not the same as:

n = (width>>1)-1

So here's your method again (with the bitshifting added):

public void drawMessageTextInMiddle(Graphics2D oofG2D, String string, int y) {

int offset = 0;

for (int i=0; i<string.length(); i++)

offset += oofG2D.getFontMetrics().charWidth(string.charAt(i));

oofG2D.setColor(Color.darkGray);

oofG2D.drawString(string, ((getWidth()-offset)>>1)-1, y-1);

oofG2D.drawString(string, ((getWidth()-offset)>>1)+1, y-1);

oofG2D.drawString(string, ((getWidth()-offset)>>1)-1, y+1);

oofG2D.drawString(string, ((getWidth()-offset)>>1)+1, y+1);

for (int i=1; i<6; i++)

oofG2D.drawString(string, ((getWidth()-offset)>>1)-i, y+i);

oofG2D.setColor(Color.green);

oofG2D.drawString(string, (getWidth()-offset)>>1, y);

}

Again, this probably won't be noticeable except on slower computers...

By the way, antialiasing is a slug...

That's the basic mess I could pull out, I didn't look much at the other code. You're a really object-oriented guy, which is good, but there is such a thing as too many objects. If you're really worred about having a seperate image with antialiasing saying the game is out of focus, just load an Image (not BufferedImage) of an already made image from photoshop or something.

I know GLApplet isn't your actual game, but even optimizing GLApplet like that will speed up the general game rendering process. As far as your actual game code goes, I'll look at it later. Just lay off a bit of the antialiasing, and don't use BufferedImages when you could get away with an Image (or no image at all!). Images are faster than BufferedImages (for applets, anyway)

Woogleya at 2007-7-16 2:44:51 >

ah, you arn't *just* using [draw/fill]Rect, and drawLine?

ovals, polygons and other more complex primitives are *alot* slower, and you will almost always want to pre-rasterize them to a managed BufferedImage.

The only exception, is when you are dynamically changing the size/shape/color of the primitives - in this situation, you can't pre-rasterize them to a BufferedImage in vram.

So, either accept the sucky performance, or design around having dynamically changing primitves.

This will hopefully change in the future. (when HW acceleration for all Java2D operations is complete)

Abusea at 2007-7-16 2:44:51 >

hmm, ok I just skimmed over the code, and i've spotted these things so far :-

1) You are using passive rendering, I'd wager you realy want to be using active rendering.

2) You are using anti aliasing. Anti-aliasing in Java2D is not hardware accelerated yet, therefor performing it on every draw operation to the backbuffer is going to absolutely kill any possible hardware acceleration.

3) public void paint(Graphics g) {update(g);}

this is a) pointless, b) a potencially fatal error.

the normal sequence of calls for passive rendering are :-

i) you call repaint();

ii) repaint then places a redraw event on the Event scheduling Thread. (unless there is already 1 on the top of the queue, it may then coalesce the events into a single repaint [this behaviour is undesirable, and that is 1 of the reasons passive rendering is bad for animation])

iii) when the event scheduler gets to the repaint event, it calls the update() method of your component for which the repaint event was queued. It passes to this method the Graphics context for the component.

iv) the default implementation of update() does several things :-

a) clears the background

b) calls paint() (and passes it onto it the Graphics context)

Your paint() method calling update() is pointless (because it is unreachable unless called explicitly by your code), and also, more importantly, if you commented out your overridden update() method (so the default behaviour of update() was allowed to execute), your app. would crash due to a stack overflow (update calls paint, which then calls update etc etc)

I will recode your GLApplet class, so it is using active rendering; gimme10mins :p

Abusea at 2007-7-16 2:44:51 >

Another quick one re: shifting stuff...

I'd also pull out your subexpression into a temp variable, so that:

oofG2D.drawString(string, ((getWidth()-offset)>>1)-1, y-1);

oofG2D.drawString(string, ((getWidth()-offset)>>1)+1, y-1);

oofG2D.drawString(string, ((getWidth()-offset)>>1)-1, y+1);

oofG2D.drawString(string, ((getWidth()-offset)>>1)+1, y+1);

becomes: int iXPos = getWidth()-offset)>>1;

oofG2D.drawString(string, (iXPos-1, y-1);

oofG2D.drawString(string, (iXPos+1, y-1);

oofG2D.drawString(string, (iXPos-1, y+1);

oofG2D.drawString(string, (iXPos+1, y+1);

Any optimizer might perform that optimization for you,

but I always figure it can just as easily optimize the temp

variable into a register, and if the optimizer doesn't do it,

then you've knocked out a few excess method calls

and duplicatecalculations anyway.

rkconnera at 2007-7-19 18:35:45 >

> I removed my background and tried drawing my game with

> using:

>

> g2d.setColor(Color.black);

> g2d.fillRect(0, 0, getWidth(), getHeight());

>

> every drawing call, and it flickers like mad. Either

> that means fillRect is a lot slower that drawing a

> BufferedImage, or my double buffering isn't really

> double buffering.

The double buffering is not working, because you are calling g2d(the applet's Graphics) instead of offG2D(the offscreen Graphics), then all your callings are directly drawn to the screen..

Rafael

rdcarvalloa at 2007-7-19 18:35:45 >