Hi Philipe, thanks for the suggestion, it does report the core profile version, however it doesn’t behave 100% as expected (eg. same 4.2 code base under Windows/Linux and 4.1 under MacOSX work fine, but Mesa has issues with GL_COMPRESSED_RGBA_BPTC_UNORM_ARB, since it reports it supported but doesn’t). We use BPTC (BC7) for all our resources, and a fallback path for OSX (4.1) which at runtime coverts all BC7 resources to vanilla pixmaps, however it screws up video playback since the CPU cant keep up. Mesa reports that it supports GL_COMPRESSED_RGBA_BPTC_UNORM_ARB, however it doesn’t convert BPTC images, so it’s best for us to define 3.3 profile (and 150 as shading languege) since GL_COMPRESSED_RGBA_BPTC_UNORM_ARB doesn’t exist in this version, and our fallback will convert BC7 images to raw pixmaps. GLSL version 150 is sweet since the fragment shader knows the function texture(), while 140 and older require texture2d() - which would require our OpenGL ES2.0 codepath.
Anyhow, Mesa version 3.3 (150 for GLSL) is as good as we can expect for SW rendering.
Sorry Philipe, I’m not at liberty of showing screenshots of company R&D projects, however a simple google search will show that I work for Atlas Gaming (http://www.atlasgaming.com.au/), and our home page has videos/pictures of some of our products, so just imagine a yellow title tab over our game screens This entire exercise was to port our stack to another platform, since more bugs are discovered this way.