Determining whether a system has integrated graphics

Java 2D
#1

I have a game that runs really slow on machines with integrated graphics, even though it’s just a 2d game. I’m working on creating options that will turn off some features to allow the game to run faster. It’s not worth it to me to switch to JOgl for a game that’s already supposed to be finished.

How do I tell whether the system has integrated graphics? I want the program to set the default options based upon how fast the computer is. I tried the following code:

GraphicsDevice graphicsDevice = GraphicsEnvironment.getLocalGraphicsEnvironment().
	getDefaultScreenDevice();       
System.out.println("Video Memory: " + graphicsDevice.getAvailableAcceleratedMemory());

This prints out -1 on my Mac Mini, which has integrated graphics. However, referring to the API, -1 means “unlimited” available accelerated memory. Clearly that isn’t the case.

Will machines with integrated graphics always output -1? Will machines with discrete graphics always output a real value? Or is there something else that I have to do?

Should I have some kind of test sequence that renders a bunch of stuff quickly, times it, and then decides what options to use? I’ve seen this in older Sierra games, but I don’t know how well it works. It seems like I’d actually have to display stuff to the screen to get an accurate reading. Even then, this test sequence would most likely be done before the JVM warms up and thus not really be accurate.

#2

Why not just let the user choose the quality manually?

#3

Try using System.getProperty(“sun.java2d.d3d”) and see if it returns “true”. That tells you if the d3d pipeline is on. If the system has an intel graphics card, it won’t be on.

#4

They’ll be able to change the quality from the options screen, but I want it to be set to a reasonable default. 3d games do this. They figure out what the options should be without the player doing anything. I figure my game can do the same even though it shouldn’t have particularly high requirements.

I’ll try that. I’ve never tried a system with non-Intel integrated graphics, but the Intel integrated graphics are going to be the primary problem anyways.

In fact, if it weren’t that Intel integrated graphics were in most computers, I probably wouldn’t have this problem.

#5

Instead of using amount of video memory as your criteria, you might want to use the capabilities of VolatileImage. (VI.getCapabilities().isAccelerated())

  1. if translucent VI is accelerated, that means you’ll have full hw acceleration (you’re on windows on 6u10+ on nvidia or ati board)
  2. if opaque VI is accelerated, but translucent is not, you won’t have alpha compositing or AA or transforms hw accelerated (no d3d pipeline) - 6uN N<10 (note that in pre-u10 you could enable the d3d pipeline if you want with -Dsun.java2d.d3d=true)
  3. on macs you’re pretty much out of luck since they mostly don’t have a hw accelerated java2d pipeline

Of course, you could also try using your fps (the only real measurement of how something is accelerated) to adjust your quality…

Dmitri

#6

Not sure it will work under Linux…

#7

I’ll try that. My program doesn’t use any VolatileImages, but I can always create a small one and throw it away.

I would much rather get a good guess at start up. I have people saying that the game is too slow, and I don’t want them to quit before the options are adjusted to match the fps.

#8

Integrated graphics aren’t necessarily too slow. In this case it probably boils down to a driver bug or a workaround (on the Java2D side) which works around this bug. Well, if it’s an old Intel integrated chipset it probably is too slow.

However, I think it’s bad to address this kind of issues this way. It’s a moving target. Using one unrelated property (integrated or not) won’t do you any good. Even more so in the long run.

#9

Latest drivers for intel graphics are fine.
Intel even have this now: http://software.intel.com/en-us/articles/intel-gpa/

#10

I used this. I got false both for a computer with integrated graphics and for a computer with an old 32 MB ATI Radeon card. The former computer had problems running the game, while the latter didn’t.

In any case, it seemed to be fine. However, yesterday I realized that this code causes a problem where the game doesn’t get displayed when I switch from my start frame to full-screen mode. I hadn’t initially noticed because only the demo version displays the start frame. (I was testing in a hurry, and the problem only happens about 2/3 of the time.)

My code is as follows:

/**Determines whether bitmask images are accelerated.
 * @return whether bitmask images are accelerated
 */
public static boolean areBitmaskImagesAccelerated() {
	return areImagesAccelerated(Transparency.BITMASK);
} //end areBitmaskImagesAccelerated

//similar methods for opaque and translucent images that I don't use

//PRIVATE METHODS
/**Determines whether the specified kind of images are accelerated.
 * @param transparency the type of transparency used by the images to check
 * @return whether images with transparency of type [transparency] are accelerated
 */
private static boolean areImagesAccelerated(final int transparency) {
	GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment().
		getDefaultScreenDevice().getDefaultConfiguration();
	VolatileImage vi = gc.createCompatibleVolatileImage(tempImageSize, tempImageSize,
		transparency);
	return vi.getCapabilities().isAccelerated();
} //end areImagesAccelerated

//PRIVATE CONSTANTS
private static final int tempImageSize = 10;

Honestly, I don’t think the problem is with this code. I think it’s somewhere else, but this code just happens to trigger the problem somehow. The problem is that there’s no way I can track it down.

I’m just going to make the options that cause the game to run slow for some people to default to off, even though one of them makes the game look much better. I’m tired of hearing from people with old computers who have the game run slow. Since the game is already released, that’s the most I can do about it.

I’m posting this message only so that people who try the same thing can be wary of similar bugs, not that I know where the bug actually is in my code.