But something has to be printed...at least a message which mode has been selected or something?! I don't have access to a 945...maybe it claims to support AA but actually fails? I've tried it on a 915 under Linux and it works as it should, i.e. jPCT tries to enable AA, fails and reverts to normal sampling mode instead.

I can verify that there is a problem with this when using the AWTGLRenderer on my EEEPC with Intel onboard crap. However, for me it throws an Exception (where none should be) and doesn't stop the application, but i'll look into it...

Damn, this isn't as easy as i thought it would be. In fact, i have no idea how to solve this correctly. The problem is this:

When creating the AWTJPCTCanvas (a package public class used by the AWTGLRenderer), you can specify a Lwjgl PixelFormat. That PixelFormat contains the number of samples, i.e. the level of AA. I can't change that, because that class extends Lwjgl's AWTCanvas...it has to. So, you can set a PixelFormat here, but the actual initializing has to happen in the paint-method of the canvas...which is where the problem occurs that the PixelFormat may not work on some hardware (like Intel with AA). But that's too late already. I can't replace the PixelFormat with another one or something. So you are stuck with a canvas that tries to use a PixelFormat that doesn't work.I've uploaded a "fixed" version of jPCT here: http://www.jpct.net/download/beta/jpct.jar...it doesn't really fix the actual problem, but it logs an error (and depending on the settings in Logger, this means that it throws an exception), if the PixelFormat doesn't work. Maybe you can catch this error and try to replace your canvas with another one without AA...i've no idea if this will work, i haven't tried it yet. But don't know what else to do...i'm open to ideas!

Can't the coder ask the available pixel formats, choose one of them and initialize the canvas with it?

I haven't found such thing. Problem is, that you need a GL-context for this, even if it would be possible. But you don't have one at the stage where you create the canvas. One may do something like i'm doing in Robombs, i.e. open a small native GL window behind a JFrame, do you queries, close both. But still i would have to find a way to ask for the PixelFormat...i'm not sure if there is such thing...

One may do something like i'm doing in Robombs, i.e. open a small native GL window behind a JFrame, do you queries, close both([...)

You have one possible solution... I've never used lwjgl (but I've used OpenGL) so I don't know how it creates windows and sets up pixel formats but for what I've seen in <native> OpenGL there are extensions and ways to get this information (like hardware mapping units, maximum texture size, number of lights, etc.)

However, I've found this in NeHe's tutorials, which I quote:

Quote from: Colt "MainRoach" McAnlis

This next bit needs to be added inside the CreateWindowGL function, the original code is left, with where you need to make modifications. Basically, we're doing a bit of overkill to get the job done. We can't request the pixel format (to query the multisampling) until we've created a window. But we can't create a FSAA screen, unless we know the pixel format will support it. Kinda the chicken and the egg thing. So, what I've done, is a little 2 pass system; We create the window, query the pixelFormat, then destroy/remake the window if multisampling is supported. Kinda nifty...

This is for the win32 case, but I'll bet there is a better way to do things...

There is the extension WGL_ARB_pixel_format, now the problem is that if lwjgl has it (or similar).

It has, that's not the problem. But you still need a valid OGL context to query this, i.e. you need something like Robombs hardware detection stuff. This is nothing that i want to build into the library itself...