Let's see what's missing in detail:
glActiveTexture, glClientActiveTexture
These functions select the active texture unit for the multitexturing interface in OpenGL 1.3 IIRC (promoted from extension GL_ARB_multitexture). This is not available in any MIPS-based SGI system, you would have to rewrite the rendering to use multiple passes, one for each texture with the appropriate blending modes between the passes, in order to work correctly (if it's not used exclusively with GLSL programs see bellow).
glLockArraysEXT, glUnlockArraysEXT
This comes from GL_EXT_compiled_vertex_array, which isn't there on my VPro octane2, there is a EXT_vertex_arrays, which could be used instead I guess. Personally I haven't used either one of those, the standard these days is ARB_vertex_buffer_object (which isn't supported either).
If EXT_vertex_arrays proved inadequate or not supported on older sgi systems, you could rewrite the relevant parts to use immediate mode (glBegin/glEnd) but expect a significant performance drop. If the arrays are not modified too much your best bet would be to rewrite the code to use display lists which is a standard OpenGL 1.0 feature.
glBindProgramARB, glProgramLocalParameter4fARB, glGenProgramsARB, glProgramStringARB, glGetProgramivARB, glDeleteProgramsARB
All the above are part of the GLSL (OpenGL Shading Language) interface, as defined through the extensions ARB_shader_objects, ARB_fragment_shader, ARB_vertex_shader. (the actual OpenGL 2.0 interface for these is slightly different and does not include the ARB suffixes of course). There is absolutely no way you can approximate the shader-based rendering in a MIPS-based SGI. Only one common usage of shaders (per-pixel lighting with vertex-interpolated normals) can be done with VPro systems using the SGIX_fragment_lighting extension. But most games which use shaders for per-pixel lighting also generally modify the normals inside the shader or derive them from normal maps, neither of which can be approximated without shaders.
Your best bet is to check out if there are compile or run time switches that disable the use of shaders and multitexturing in the aforementioned game, otherwise you have a lot of rewriting to do :)
glActiveTexture, glClientActiveTexture
These functions select the active texture unit for the multitexturing interface in OpenGL 1.3 IIRC (promoted from extension GL_ARB_multitexture). This is not available in any MIPS-based SGI system, you would have to rewrite the rendering to use multiple passes, one for each texture with the appropriate blending modes between the passes, in order to work correctly (if it's not used exclusively with GLSL programs see bellow).
glLockArraysEXT, glUnlockArraysEXT
This comes from GL_EXT_compiled_vertex_array, which isn't there on my VPro octane2, there is a EXT_vertex_arrays, which could be used instead I guess. Personally I haven't used either one of those, the standard these days is ARB_vertex_buffer_object (which isn't supported either).
If EXT_vertex_arrays proved inadequate or not supported on older sgi systems, you could rewrite the relevant parts to use immediate mode (glBegin/glEnd) but expect a significant performance drop. If the arrays are not modified too much your best bet would be to rewrite the code to use display lists which is a standard OpenGL 1.0 feature.
glBindProgramARB, glProgramLocalParameter4fARB, glGenProgramsARB, glProgramStringARB, glGetProgramivARB, glDeleteProgramsARB
All the above are part of the GLSL (OpenGL Shading Language) interface, as defined through the extensions ARB_shader_objects, ARB_fragment_shader, ARB_vertex_shader. (the actual OpenGL 2.0 interface for these is slightly different and does not include the ARB suffixes of course). There is absolutely no way you can approximate the shader-based rendering in a MIPS-based SGI. Only one common usage of shaders (per-pixel lighting with vertex-interpolated normals) can be done with VPro systems using the SGIX_fragment_lighting extension. But most games which use shaders for per-pixel lighting also generally modify the normals inside the shader or derive them from normal maps, neither of which can be approximated without shaders.
Your best bet is to check out if there are compile or run time switches that disable the use of shaders and multitexturing in the aforementioned game, otherwise you have a lot of rewriting to do :)