I tried to check the capabilities of the renderer (for thing such as VBOs and shaders) by checking the extension screen. However, it seems to not be working, as people who have used my Monkey3D demo application who don't have the capabilities to use certain features didn't have the options grayed out. (I specifically checked the extension string to have it gray out the options if the extension isn't present) This was from a standard OpenGL view (subclassed for my specific rendering, of course), but I had the same problem earlier with a custom pixel format that had no software fallback. How can I accurately check for the renderer capabilities if extension checking doesn't work?

Extension-checking does work. You have a bug in your code.

I tested it with Unknown, and his extension string does indeed show those extensions. I printed out the extension string as well as the results from the search. His renderer claims to have GL_ARB_vertex_program and GL_ARB_vertex_buffer_object, but whenever he enables vertex shaders or VBOs he gets garbage. (he's using a GeForce 2 MX) From what I've seen, it shouldn't really support either. In fact, according to arekkusu's page, the Rage 128 even has GL_ARB_vertex_program in its extension string. Is there any way to get a little more restrictive string? I currently use glGetString(GL_EXTENSIONS) to get the extension string.

(BTW, while you're looking at this OSC, can you by any chance check if my program works on your Intel Mac? Download. Also, here's the thread on it)

The GeForce 2MX supports ARB_vertex_buffer_object natively, and ARB_vertex_program in software. Enabling both at once might be bad for performance... I haven't benchmarked since they enabled ARB_vbo for all renderers.

If you're getting garbage by using the extensions on hardware that exports them, that's a bug. Sucks, but they happen. Report it.

Apple seems to consider the extensions string to be a list of things that the hardware can support at "reasonable" speed. ARB_vbo is always doable at speed no worse than normal vertex arrays, so that's available everywhere. Software vertex programs are usually plenty fast enough, so they're available everywhere. Fragment programming is generally far too slow unless it's supported by hardware, so it only shows up on capable machines.

Your app seems to run OK on my Intel iMac, but I'm not sure the cube map thing is working. You need to be careful with vertex positions, too -- even a miniscule difference between two vertices can cause seams between polygons.

You can do:


if maxInstructions == 0 then the card doesn't have hardware vertex program support. May not be the *best* way to do it, but has worked with all the computers I've tested on. I also recommend requiring X.3.8 or higher, as shaders are notoriously buggy beneath that.

Watch out for the integrated video in the Minis. They *don't* have hardware vertex programs but *do* have hardware fragment programs. I believe they're the only Mac cards where this is true.

Thank you for help, both of you. I added the instructions check, but I'll have to work a bit more with the VBOs to see what the problem is.

OSC: I didn't make any of the models, all were downloaded off the internet. I'm assuming you're talking about the coat of the model of the girl for the seams: the coat seems to be made by having sort of "fins" on it, which makes it look like it has seams. Can you give me a screencap of the cube map? I have 1 side have the Earth and sun picture, 1 side have Mars, and the rest as sides of stars. Also, does it change much when you enable shaders? At least on my computer, there's only a very slight shift. Here's a screencap of what it looks like on my computer.