The Big Graphics Performance Challenge
Your goals:
60fps
800x600x16
A full screen of scrolling tiles of any size
32 bouncing sprites of 32x32 pixels. Alpha blended.
Must work on Win32, Linux, OSX.
You can have the fastest computer you like to achieve this.
Post your demos as a JNLP link reply to this thread… even if you can’t manage it, let’s see the best you can do.
Cas 
isn’t there abit of sample code in jbanes’ GAGE lib, that does pretty much exactly that?
It doesn’t have the bouncing Alpha blended sprites… but that isn’t such a problem… um… actually it is LOL
To get the needed render speed on the tiles, you will want the tiles to be managed Images, and be drawn onto a vram surface (BufferStrategy).
Alpha blending being unsupported in hardware, will need to read back from the BufferStrategies vram surface, do the blend, and then copy back.
This will absolutely kill performance.
3 solutions :-
This way, the readback from vram will be avoided, so the alpha blending wont kill the speed.
However, software blitting the tiles will be quite slow, and may prevent you reaching 60fps. (esp. @ 800x600)
Relax the requirements, and allow just bitmask transparency on the sprites.
Use the experimental D3D full alpha acceleration flags.
Specific to Windows, and even then it won’t work on older gfx cards.
I agree though, Java2D is a mess atm :-/
It is impossible to write an app. that will run at optimal speed on all 3 platforms, with the same code
The hoops you have to jump through to get acceptable performance is crazy IMO.
Hardee Har Har, - talk about stacking the deck in your favor; Fullscreen on Linux? Well, I’ll just pretend its 800x600 windowed :
EDIT; Yeah, its tough, unless you use lwjgl wich is what he’s getting at.
EDIT 2: Here’s my entry; arrows to walk around:
http://www.geocities.com/nonnus29/javademo2/demo.htm
I couldn’t get the jar file to be executable, played with the manifest a couple of ways but no go. Don’t think I can do webstart from geocities, really don’t want to try.
This is really odd; running from the jar its 10 fps slower on my comp; max fps is about 30. There’s no timing, it runs flat out. 800x600 windowed using BufferedImage (its not even a compatible BufferedImage, I had to have int rgb to do the blending :P)and BufferStrategy - probably some wasted effort there. I’ve only tried it on windows, although there is nothing esoteric about the code.
Next?
;D
works at 70-75fps on a p4 2.2ghz/radeon9000 on XP jre1.5.0beta1.
55fps under linux, same jre, same machine. unfortunatly, the opengl flag did not change anything… (note to self… will have to rant about that) Saw some flashes, there.
Not fullscreen, but has nothing to do for the test and the jar is runnable.
I see this post as related to Cas’s rant about awt, thus fullscreen is there imho to help plugging LWJGL, and not to be related to any perf improvement. Let’s take fullscreen out of that…
38fps on Gentoo Linux running on a 1.4Ghz laptop
Nonnus’ Jar is double-clickable.
AMD with 1.8 GHz & Ati 9600pro:
Win2000:
° Java 1.42 client: ~110 fps.
° Java 1.42 server: ~120 fps.
(Using -Dsun.java2d.ddoffscreen=false or -Dsun.java2d.noddraw=true halves the framerate.)
Linux:
° Java 1.41 Blackdown: ~50 fps.
(Knoppix without HW accelerated graphics driver - so software rendering I suppose)
An impressive demo, marred only by using all of my CPU (2Ghz and 60fps, GeForce4) Those squares… are they actually sprites with alpha channels? Or just blitted rectangles?
Cas
ps. By full screen I didn’t mean fullscreen mode, I just meant that the entire background had to be drawn each frame (ie. a tile on every square).
Win98, P4 2.8, GF4 Ti4200 => 150 FPS
There is just one little bug : when maximizing the window I only get a white screen.
They are filled rectangles, I don’t have a good particle image that isn’t already blended with the backround, so my particles looked like crap :-[ but they did give the same fps.
Hmm, now I wonder if it works on Mac osX?
WinXP, 2.2 GHz M-Pentium, GeForce4 4200 Go - ~50 fps
using JDK 1.5 ßeta
And what about with 300 sprites?
Cas
What exactly are you trying to prove cas?
We all know atm the Java2D pipeline doesn’t hardware accelerate all that is necessary for a workable 2d game engine.
Until it does, Java2D will always be crap.
Well, there was a chance I was wrong and I wanted to be shown how to do it But it looks like I might be right in thinking that it’s not going to get any faster until someone rips out the DDraw code in Windows and replaces it with modern D3D code.
In the meantime I might continue with Lunar Lander and use bitmask transparency instead.
Cas
mhhh.
anyway, i’d be curious to see the GL pipeline working. if it does as correctly as it should this thread and all hidden meanings will be pointless.
About java2D. i don’t agree it is crap. java2d is a wonderfully designed 2d API. It’s just too slow for some of you… (while by the way is not really what i thought when i tried the jar nonnus posted)
Anyway, it’s still the problematic of the right tool for the right job.
By the way, there is a gl implementation of java2D that you might plug in. anyone tried it?
http://www.cs.umd.edu/hcil/agile2d/
IMO What we realy realy need (after the D3D acceleration has been fully implemented) is some kind of way to query the capabilities of a given GraphicsDevice.
graphicsDevice.isAccelerated(operation, source, destination);
If a required part of the pipeline isn’t hardware accelerated (a particuler AlphaComposite/AffineTransform op for instance), we can detect it, and either use a different op (precalc. rotations, bitmask instead of full alpha etc), or fall back entirely to software rendering.
Ah, now, there’s been many a heated debate on this in the OpenGL world. You have noticed that OpenGL does not give you any caps bits to say what is and isn’t HW accelerated - and with good reason; it makes programming a total nightmare. GL only advertises capability, not performance.
I’d like Java2D to work like this. After all, it’s meant to be easy to program, like GL. What’s obvious here is that what Java2D is being used for is being seriously affected by its performance. You can’t go writing tons of different renderers for all different permutations of hardware acceleration or you’d just lose all the advantage of an abstract toolkit in the first place, so you instead have to rely on the underlying technology to run the capabilities it has at the maximum performance achievable on common hardware. This means D3D on Windows. Or even OpenGL. I’d prefer GL, even on Windows.
So when I ask for 32 bit RGBA sprites, I get them no matter what; and most of the time they will be in a hardware accelerated pipeline because most computers have hardware accelerated 3D accelerators these days. But if not, then at least it could fall back to software. This is very similar to how GL is implemented. Successfully, I might add.
Cas
hmm, I see the truth in GLs philosophy.
However, J2D doesn’t seem to have decided which path they want to follow.
Consequently, we have an API that offers some performance querying functionality, but not enough for it to be of any use (+ive or -ive :/)
ImageCapabilities class
BufferCapabilities class
VolatileImage.getCapabilities();
BufferStrategy.getBufferCapabilities();
BufferCapabilities.getBackBufferCapabilities();
tbh, the J2D seems to have lost its way :-/
On Windows :-
At the moment, new BufferedImage(…) will get you an image stored in main memory only; (unmanaged)
graphicsConfiguration.createCompatibleImage(…) on the other hand will get you a BufferedImage stored in main memory, and eligable for caching in vram. (managed)
But, once created, there is no way(accessable to a user of the API) to distinguish between a managed and unmanaged image.
The 2 can behave very differently(from a performance perspective), under many circumstances.
Under 1.5, all images will be placed in accelerated memory if possible. But unfortunately it’s the “if possible” bit that’s the sticking point; as soon as you’re using alpha channels, it’s no longer possible (by default, at any rate). Bah.
Cas
Hmm, im gonna have to take a look at the 1.5 beta…
I wonder how it will handle calls to bufferedImage.getData() though, as it makes an image unmanagable… which in turn raises the old issue of how to determine if a bufferedImage is managed or not :-/
is a runnable jar too much work zparticle?
/ / / / (or am i just lazy :P)
MY entry:
http://www.scottshaver2000.com/files/scroller.zip
Unzip it and use the run.bat file under Windows. Cursor keys to move, q to quit.
Copy the com\sas\planetation\examples\resources\maps\non_alpha_tile_29.png file to com\sas\planetation\examples\resources\maps\tile_29.png
to run it without alpha blending. The alpha blending costs me 30 FPS on my work machine and makes the CPU go from 7% to 56% usage.
I have a few issues in that code that make it not able to run in a jar.