Best possible FPS achieved?

Java 2D
#1

Hi!
Im quite new to JavaGaming, but I made a demo to test the performance om my p4, 3GHz, radeon card machine.

I get around 60 FPS in 800x600 fullscreen and window modes.
With 1000 blits from the same BufferImage. (32x32 pixels Bitmask).
With 750 blits, I get 80 FPS.

My question is this the best I can expect from Java2D or is there something else I forgot?
I use BufferStrategy, 2 buffers for window and 3 for the fullscreen mode.

And a second question, what is the best way to implement a simple particle engine for
game explosions and smoke. Small sprites or colored pixels? And can I use transparency with
colored pixels and still retain the hardware acceleration?

Thanks in advance.

I use this code to load images:


URL url = getClass().getResource("../../"+fileName);
            
BufferedImage tempImage = ImageIO.read(url);
            
BufferedImage image = GameFrame.gc.createCompatibleImage(tempImage.getHeight(),tempImage.getWidth(),BufferedImage.BITMASK);
            
Graphics g = image.getGraphics();
            
g.drawImage(tempImage,0,0,null);
            
g.dispose();

This is the output of “-Dsun.java2d.trace=count”

#2

dunno about performance comparisons, I’ve never tried a similar benchmark.

For particles you will want to use a small graphics, not colored pixels, drawing lines and filling rectangles is quite a bit slower than drawing an image (how much faster will depend on the type of image you’ve created). Transparency you can do, bitmask transparency that is (1-bit). If you use ‘translucent’ images, its going to be damn slow. You won’t be able to create effects that are too convincing with only bitmask transparency because a lot of effects rely on the the particles blending together, your best off animating a spritesheet of the effect if you don’t have hardware accelerated blending.

Here is a somewhat limited example of what you can do with particle effects in java2d: http://www.cyntaks.com/projects/old_particle-effects.jar It just uses bitmask transparency with the images and you can compare the performance of rendering ovals vs. images (filling rectangles would be nearly as slow I’d guess). Please note that this was written without knowledge of how to achieve good performance in j2d and as such it probably doesn’t perform as well as it could/should :stuck_out_tongue:

#3

Well, would be interresting to have some values of the latest Mustang builds to have a comparison what has been done since Tiger :wink:
Also values for the new D3D pipeline or the great, wonderful and best-ever opengl pipeline…

lg Clemens

#4

:o I never thought that drawing a bitmasked image could be faster than drawRect(x, y, 1, 1)
Is that true even for single pixel particles?

#5

So it all comes down to Using LWJGL … :-\
But then I loose Applets. Hmm, its a hard descision.

How portable is LWJGL in practise?

#6

dunno if its true if the rect is 1x1, maybe someone else can answers that.

#7

JayTe, lwjgl works well on the big three: windows, mac, and linux. I personally haven’t tested on any other OSs. I developed my current lwjgl app on windows xp and tested on mac, it worked fine without changing a single line of code. Haven’t tested that particular app on linux, but you get the point :slight_smile:

#8

Thanks for the fast reply. :slight_smile:

#9

Hmm, why not simply use the OpenGL pipeline available in Tiger (5.0) and up?

Its almost as fast as if you would do it in OpenGL yourself (only minimal overhead) but you do not need to care about anything.
If no OpenGL available, fall back to D3D and if no 3D card is available there’s still the plain old GDI implementation.

For images a 1x1 buffered-image blit is more expensive than a 1x1 fill, but particles could be emulated using maybe 20x20 big images where only the visible particles are opaque and everything else is transparent.
Furthermore I am sure you could archive better performance if you would blit less images, but larger one. So if there is any chance to cache e.g. your background in a VolatileImage this would help for sure.

lg Clemens

#10

Do you mean by drawing the rects to small 20x20 images and reusing them or using 20x20 images like on weston’s example?
I don’t understand what you mean. :-\

#11

Because it straight jackets you into using a particular subset of operations which one particular VM might just optimise better. Maybe.

[quote]Its almost as fast as if you would do it in OpenGL yourself (only minimal overhead) but you do not need to care about anything.
[/quote]
Haha. No.

#12

Yes, exactly - this should be a lot faster than drawing 1x1 rects or 1x1 bufferedimages.

#13

Well, for now there is only the Sun-JVM or VMs based on Sun’s classes (ibm, bea, sun, jet-4, hp, sgi, ecom-station, …) and the GNU classpath isn’t really ready for gaming at all at the time of writing this (java2d broken and slow).
However that is/was the same with OpenGL there are cards which are faster at these and other are faster on another thing.

Haha. No.

Both just do a texture-mapped quad operation, its not much more?

lg Clemens

#14

Uh, I think you just proved my point.

Even assuming that everyone who plays your game has the latest and greatest VM (unlikely), and all the magic flags enabled (even more unlikely), and they all work (unlikely*2), then you’ve still got to be very careful to get a properly optimal OpenGL path. You’ve got to rely on implementation-specific details and voodoo, and you’ve got to know every bit of black magic that the Java2d folks let us know about via these forums. Thats very fragile, and all for a feature set thats inferiour to what you’d get if you just went for straight OpenGL yourself.

Much more. I know the structure of my scene far better than Java2d can guess at. I know which sprites can be grouped because they’re using the same texture atlas, I know where I can use the depth buffer for easier sorting. I know where I can use specific blending modes for fancy effects. etc. etc. I can do optimisations that are simple to me but totally impossible for Java2d because it’s got to stick ridgidly to an API which wasn’t written with an OpenGL backend in mind.

Java2d is great for prototypes and non-performance critical drawing, but when it comes to performance critical and high quality then it just doesn’t cut it.

#15

Ok, well - here you’re devinitly right :wink:

Well, that are things no 2d api I know is able to do, but it seems you’re right. In favour of simplicity java2d removes some flexibility of the underlaying API of course - I have to admit that I never used java2d for a “real” game, although I did some projects which required a lot of complex 2d drawing , so to be honest I do not have much gaming experience.

lg Clemes