Init AA when not supported

[ErDetEnAnd?]

Hey. I've read that jPCT should fall back to normal sampling if antialiasing initialization fails. This is not the case with the current beta and a Intel onboard 945GM.

[EgonOlsen]

And what happens instead? Do have a log or stacktrace or something...?

[ErDetEnAnd?]

Nothing in console (verbose logging), and clearing the framebuffer with a color doesn't show.

[EgonOlsen]

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.

[ErDetEnAnd?]

This is what is printed:

Code Select Expand

Java version is: 1.6.0_11
-> support for BufferedImage
Version helper for 1.2+ initialized!
-> using BufferedImage
Software renderer (OpenGL mode) initialized
mode: 1280/800/16/60
mode: 1280/768/16/60
mode: 512/384/32/60
mode: 1024/768/32/60
mode: 800/600/16/60
mode: 320/240/16/60
mode: 640/400/16/60
mode: 400/300/32/60
mode: 1280/720/16/60
mode: 1280/600/16/60
mode: 640/480/32/60
Software renderer disposed

Program blocks here (program doesn't freeze, since it can be closed normally):
AWTGLCanvasInstance.paint(getGraphics());   // AWTGLCanvas.repaint() does not block/freeze but same problem

Running same program on my nVidia I get same text, but with following appended:

Code Select Expand

Driver is: nv4_disp/6.14.11.6921 on NVIDIA Corporation / GeForce 7800 GTX/PCI/SSE2
GL_ARB_texture_env_combine supported and used!
FBO supported and used!
OpenGL renderer initialized (using 4 texture stages)

[EgonOlsen]

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...

[ErDetEnAnd?]

It is widely used, so I'm looking forward to this, thank you.

[EgonOlsen]

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!

[C3R14L.K1L4]

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

[EgonOlsen]

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...

[C3R14L.K1L4]

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:

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...

[C3R14L.K1L4]

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

[EgonOlsen]

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...