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 , 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.
GLIntercept seems to be what I want, but it hasn’t helped much. 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.
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.
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.
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
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.
, and missing a stronger feeling of the bonus or malus effect) worked nicely though.
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.
