World Rally Driver 4K

[Mr_Gol]

@Ranger

Hi Mr Gol,

Yes, I changed my game loop and removed the use of VolatileImages. I’ve now modified the game loop again. Can you please see if this has fixed the problem?

Thanks!

The speed is still nowhere near to what it was before I’m afraid

[Ranger]

Just added some checking to stop people from uploading fast times if the game runs too slow. Fear not Java 1.5 people, there is now a low detail version that doesn’t use the large BufferedImage, so it should run silky smooth (but not look as pretty). There is a link on the main page that points here.

TimFoden: To save some more much needed space, I modified some more stuff that modified the car speed a little, so you’ll notice that your top time replay actually drives a little slower then the new car. Sorry! …not that anyone has come close the beating that time anyway! :

Mr Gol: If it did run quickly before, I’m at a loss as to why. All my testing points to my large BufferedImage being the cause of the slow down, and that has been there since day 1. :-\

Oh, and the old replay data cannot be submitted to the server, so make sure you close and reopen your browser to get the latest version if you would like to submit your replays.

Thanks all!

[trembovetski]

@Ranger

Ah! Yes! Thanks Dmitri. I switched back to 1.5 on my PC, and I now see the slow performance. …now to fix it.

Edit2: The problem is gfx.rotate(…) seems to be inefficient in 1.5 (I am rotating a somewhat large 2000x2000 image ::)). Not sure how I can fix this as rotating the image is a core part of my game.

Yeah, transforming a 2000x2000 image would indeed suck on 1.5. Do you set bilinear filtering hint?
I would suggest to disable bilinear filtering on 1.5 jvms.

What’s the image type of that BufferedImage?

Also, could you run your applet with -Dsun.java2d.trace=count and post the output on 1.5 vm?

Dmitri

[Ranger]

@trembovetski

Yeah, transforming a 2000x2000 image would indeed suck on 1.5. Do you set bilinear filtering hint?

I tried setting: g.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR); It did help…but not that much.

@trembovetski

What’s the image type of that BufferedImage?

TYPE_INT_RGB

@trembovetski

Also, could you run your applet with -Dsun.java2d.trace=count and post the output on 1.5 vm?

67 calls to sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb) 12062 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntRgb) 696 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntRgb) 26 calls to GDIFillRect 7218 calls to sun.java2d.loops.FillSpans::FillSpans(OpaqueColor, SrcNoEa, AnyInt) 2876 calls to sun.awt.windows.Win32GdiBlitLoops::Blit(IntRgb, SrcNoEa, "GDI") 696 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntRgb) 30546 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntRgb) 1 call to sun.java2d.loops.DrawGlyphList::DrawGlyphList(OpaqueColor, SrcNoEa, AnyInt) 316 calls to sun.java2d.loops.FillRect::FillRect(OpaqueColor, SrcNoEa, AnyInt) 54504 total calls to 10 different primitives

Any help much appreciated!!!

Thanks!

[cylab]

@Ranger

The problem is gfx.rotate(…) seems to be inefficient in 1.5 (I am rotating a somewhat large 2000x2000 image ::)). Not sure how I can fix this as rotating the image is a core part of my game.

You could only rotate the visible part on screen.

[Ranger]

@cylab

You could only rotate the visible part on screen.

Not quite sure how to do that. ??? Currently I have my 500x500 screen buffered image that I do the rotate (and translate + scale) on. The I say paint the 2000x2000 background buffered image (the slow bit). If the Java 2D Graphics code was smart, it would work out what part of the 2000x2000 buffered image was in the 500x500 screen buffered image, and only rotate that bit…no clue if it does this or not. Maybe that’s the difference between Java 1.5 and 1.6? :-\

[cylab]

Hmm, try it out: copy a 710x710 image around your car position from the 2000x2000 image to another BufferedImage and draw that one to the screen buffer.

Edit - In case you wonder: 710 because it’s slightly greater than the diagonal of your 500x500 screen. This way you make sure that the image is big enough to fill the entire viewport when rotated.

[Ranger]

@cylab

Hmm, try it out: copy a 710x710 image around your car position from the 2000x2000 image to another BufferedImage and draw that one to the screen buffer.

Edit - In case you wonder: 710 because it’s slightly greater than the diagonal of your 500x500 screen. This way you make sure that the image is big enough to fill the entire viewport when rotated.

I read your comment and slapped my self in the head. Can’t believe I didn’t think of doing this! Brilliant idea!

I had to make the image 1012x1012, as while the screen is 500x500, it gets rotated around the point of the car which sits at the position (250,440). 1012x1012 is still almost 4 times smaller then the original image, and it has made all the difference when running on Java 1.5. Woohoo! ;D

Thank you Cylab! You are a legend!!! 8)

If anyone notices it still runs slowly. Please let me know.

Cheers.

[cylab]

@Ranger

I had to make the image 1012x1012, as while the screen is 500x500, it gets rotated around the point of the car which sits at the position (250,440). 1012x1012 is still almost 4 times smaller

Am I missing something here?

If you have a viewport of 500x500, I think you need a rect of the viewport-diagonale to safely rotate the rect while filling the whole viewport. The diagonale is sqrt(500^2*500^2) ~ 708, so when (x,y) is the car position, you would need a subimage from (x-354, y-354) to (x+354, y+354).

Edit: And in case you aren’t already doing it, use BufferedImage.getSubimage() for this.

[Ranger]

@cylab

Am I missing something here?

If you have a viewport of 500x500, I think you need a rect of the viewport-diagonale to safely rotate the rect while filling the whole viewport. The diagonale is sqrt(500^2*500^2) ~ 708, so when (x,y) is the car position, you would need a rectagle from (x-354, y-354) to (x+354, y+354).

This is true if you rotate around the middle (250,250). However, I need to rotate around the the point 250,440 (where the car is). So that’s sqrt(250^2 + 440^2) * 2 = 1012. …I think. :persecutioncomplex:

[Ranger]

@cylab

Edit: And in case you aren’t already doing it, use BufferedImage.getSubimage() for this.

Sweet! Never realised this method existed! Thanks again!!!

[cylab]

Ah, now I understand, but it shouldn’t matter. Just offset the subimage: (x-354, y-354+oy) to (x+354, y+354+oy) where oy=[distance car to center]=440-250=190. Use Graphics2D.rotate(double theta, double x, double y) to do the rotation out of the center.

Edit: no, this was too simplistic, since I didn’t account the current car direction… but sqrt(250^2 + 440^2) * 2 is also wrong The easy way would be to use a subimage where the car-position is virtually in the center of the rect to rotate, so if the position is (250,440), then the subimage at least has to be 880x880. The diagonale is then sqrt(2*880^2)=1244 :-\

If you want to optimize this you could calculate the minimal needed subimage and use an out-of-center-rotation by projecting the rotated viewport-corners to the source image coordinate system, but the math for this could get a bit more complicated…

[trembovetski]

@Ranger

Sweet! Never realised this method existed! Thanks again!!!

Why use getSubImage when you can just do a drawImage with 8 parameters (dst, src rects)?
http://java.sun.com/javase/6/docs/api/java/awt/Graphics.html#drawImage(java.awt.Image,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20java.awt.image.ImageObserver)

Using getSubImage can have some non-obvious side effects in some cases.

Dmitri

[trembovetski]

@cylab

Ah, now I understand, but it shouldn’t matter. Just offset the subimage: (x-354, y-354+oy) to (x+354, y+354+oy) where oy=[distance car to center]=440-250=190. Use Graphics2D.rotate(double theta, double x, double y) to do the rotation out of the center.

Edit: no, this was too simplistic, since I didn’t account the current car direction… but sqrt(250^2 + 440^2) * 2 is also wrong The easy way would be to use a subimage where the car-position is virtually in the center of the rect to rotate, so if the position is (250,440), then the subimage at least has to be 880x880. The diagonale is then sqrt(2*880^2)=1244 :-\

If you want to optimize this you could calculate the minimal needed subimage and use an out-of-center-rotation by projecting the rotated viewport-corners to the source image coordinate system, but the math for this could get a bit more complicated…

Behold the AffineTransform.transform(array[], array[]) methods, which can transform your coordinates for you…

Dmitri

[Ranger]

Just noticed there is a comment http://www.java4k.com/index.php?action=games&method=view&gid=197 saying it is not possible to paste text into a Java window on a Mac. Is that true? Can somebody with a Mac confirm this for me? Ie: Can you load a replay ok on a Mac?

Thanks!

[Ranger]

I have confirmed that it is not possible to paste text into a Java window on the Mac platform. Sorry Mac users, you will not be able to load replays.

…I hope none of the judges use Macs! :persecutioncomplex:

[Ranger]

Huge thanks to Paladin (a coding Guru who I’ve worked with and who wrote Ice Fighters). I’ve been able to squeeze more bytes out and put back the good awesome looking textures.

Unfortunately, sorry Mac users, doing a forced copy / paste takes an enormous amount of bytes which I just don’t have. And hey, Spiderball 4k worked the same way (using an InputDialog), and nobody complained about that? …or did they :persecutioncomplex:

// Copy
Toolkit.getDefaultToolkit().getSystemClipboard().setContents(str, null);

// Paste
Transferable t = Toolkit.getDefaultToolkit().getSystemClipboard().getContents(null);
str = (String)t.getTransferData(DataFlavor.stringFlavor);

Anyway, good luck to all! I see via the java4k site we have a record amount of games! :o Awesome! ;D