Emulating older hardware / testing fallback paths

So I’ve got my game pretty much finished, and one of the things I’ve just added was a reflection effect. This effect uses GLSL and multitexturing, but the rest of the game is basic GL1.1 territory. At startup I check the extensions and enable/disable the the reflection effect as appropriate.

However I have no good way of testing that the fallback path actually works. I can force the GL1.1 path and see that it draws ok, but I have no idea if it’s silently using some extension that I hadn’t planned (I’ve got a lot of shared library code used in the rendering, so it’s non-trivial to manually eyeball it).

Ideally I’d like some way of running my app, then logging/reporting what extensions I’m using. I can’t find anything available though. Has anyone got any suggestions?


Did not work here, neither JWS nor windows native versions. Loads, then a black window that quickly disappears.
Your 2 other games Growth Spurt (nice one) and Plasma Zone (really too hard :stuck_out_tongue: , and missing a stronger feeling of the bonus or malus effect) worked nicely though.

To test with basic GL, you can simply uninstall your video drivers.

Thanks for trying it, it should write a log to SnowmanVillageLog.txt (should be found somewhere like C:\Documents and Settings\YourUserName.SnowmanVillage), if you could post that it’d be helpful.

Ahahaha, I’m an idiot. That version was broken, I’ve uploaded a new one now which should work.


lets you disable gl extensions of the driver.

Fun and relaxing game :slight_smile:
Keep up the good work !

What do you use for opengl on java ?

Thanks! I use LWJGL ( http://lwjgl.org/ ) for OpenGL.

GLIntercept seems to be what I want, but it hasn’t helped much. :frowning: My app seems to fail on one person’s GF4, but I have no idea why. I’ve logged all the gl functions being called when running the fallback paths (no fbo, no glsl), but I can’t see anything that wouldn’t be available. I suspect my only option is to throw in lots of logging info and get them to send me the log back so I can narrow down the bit thats failing.

FYI Adding
FunctionStats = (“GLFuncStats\GLFuncStats.dll”);
to the plugins section of gliConfig.ini will give you a listing of the functions used.

I ran with OpenGl1.2 and no FBO
ExtensionOverride = (“GLExtOverride/GLExtOverride.dll”)
VersionString = “1.2.0 - Custom version string”;

   RemoveExtensions = (GL_EXT_framebuffer_object);

and got this as the listing:
======= OpenGL function calls by call count ==========
glTexCoord2f … 237160
glVertex2f … 189228
glColor4f … 50011
glVertex2i … 48584
glColor3f … 19699
glEnd … 17352
glBegin … 17352
glEnable … 13904
glMatrixMode … 1218
glLoadIdentity … 1055
glTranslatef … 727
glOrtho … 609
wglGetProcAddress … 581
glBlendFunc … 564
glPushMatrix … 445
glPopMatrix … 445
glClearColor … 397
glClear … 397
glGetIntegerv … 328
glDisable … 326
glGetError … 292
glScalef … 282
wglSwapBuffers … 282
glViewport … 164
glPixelStorei … 155
glTexImage2D … 38
glTexParameteri … 28
wglGetCurrentDC … 12
wglGetExtensionsStringARB … 11
glGetString … 6
wglMakeCurrent … 5
wglGetCurrentContext … 4
wglDescribePixelFormat … 3
wglSetPixelFormat … 2
wglSwapIntervalEXT … 2
wglDeleteContext … 1
wglGetPixelFormat … 1
wglCreateContext … 1
wglChoosePixelFormat … 1

Arr drat. I just realeased you are also hitting a bug in GLIntercept that I though no-one would encounter. If you look in the log you will see lots of:
ExtensionFunction::AddFunction - Function glBindTexture does not match previous lookup (multiple OpenGL devices?)

which happens as I though no-one on Windows would be loading the OpenGL1.1 entry points manually through wglGetProcAddress.

Oh well, something to fix for GLIntercept 1.0.

Thanks, I got pretty much the same results using a trial of geDebugger in the end. However after looking through both those results and yours, I can’t see anything that wouldn’t be available on a GF4.

Hopefully the person who’s system it crashes on will try it again and give me the detailed log back, because at the moment I’m out of ideas. :frowning:

Rolling snowballs is not as easy as it first seems!

No problems here, very nice :slight_smile:


Originally posted by sqrt[-1]:
which happens as I though no-one on Windows would be loading the OpenGL1.1 entry points manually through wglGetProcAddress.
This is kind of amusing to me, as every OpenGL game/utility I’ve ever written fetches the function pointers, even simple model viewers and things :slight_smile:

This mattered a lot more back in the days of 3Dfx Voodoo1/2 cards which required a special 3dfxvgl.dll be loaded instead of opengl32.dll (however simply copying it into the game’s directory as opengl32.dll worked too).

However I’ve found that compiling Linux binaries linked to libGL is a bad idea if one is using NVIDIA drivers on the build machine, as it links to NVIDIA-specific libGLcore stuff, otherwise I would go back to the conventional library linking as it’s less of a headache in other ways.

I finally got this solved - the program was choosing the GLSL path when run on a GF4. Seems I was checking for GL_ARB_shader_objects and GL_ARB_shading_language_100 (both of which the GF4 apparently supports) but I forgot to check for GL_ARB_fragment_shader as well, so it’d die when compiling my fragment shader.

I can only guess that newer GF4 drivers emulate GLSL vertex programs, and so support GL_ARB_shading_language_100.

Yes, I think they support the vertex shader part.
Just detect the GL version and use the GL 2.0 built-in functions.