Peace, Risen !!
As far as we can tell, FP's, TC's and now TFP's 'Hardware Acceleration' call OpenGL 1.0 correctly. The problem lies beyond.
I'm sorry, you will find the 'OpenGL support' boasted by your wondrous graphics card is not necessarily all it claims...
If you down-load and run the utility mentioned in the main OpenGL-issues thread, it will audit your system, report all the missing entry-points, those with non-standard names etc etc.
http://www.realtech-vr.com/glview/And, despite apparent compliance, even those 'good' sub-routines may be tweaked for game usage rather than *strictly* meeting the OpenGL specification.
I lurk on several 3D/graphics forums, and graphics cards are a persistent issue across multiple, unrelated products. I often see reports that, eg 'Confirmed 3S xxx PCI-E cards will *not* work with...' or 'Do NOT try Nvidia Beta xxx with...'
IIRC, the market-leading AutoCAD has compiled a *very* short list of 'fully compliant' graphics cards and drivers, has reached the stage of including internal OpenGL diagnostics, alternative software modules, adaptive code etc etc.
If you're gonna blame anyone, moan at Bill Gates for unleashing a sprawling, sloppy-coded, closed-source monster...
D'uh, I remember when, IIRC, FP_8 and a raft of other programs suddenly stopped working. We traced it to a 'patched' MFC42.dll loaded by Microsoft Office !! That's right, a tiny, un-documented tweak by a code-bunny in the Seattle warren took down a dozen main-stream products that were *strictly* compliant with the library...
Please don't yell at us-- Help us solve the problem.
Are you a 'coder' ? Can you write short programs to call specific OpenGL routines every which way ??
If so, perhaps IMSI could list calls used in 'Render' but not 'Edit', and we could stress-test them one by one...
