More unmanaged OpenGL

Hello, I have another inquiry about running unmanaged OpenGL in .NET, specifically under C#.

I am trying to load up an unmanaged C DLL that contains some OpenGL rendering code, from within my C# application. I’ve installed the Tao framework in hopes that I can initialize OpenGL from within C# and simply call my unmanaged rendering functions from there.

Unfortuately, only the calls to glColor() in my unmanaged rendering routine have any effect, I cannot create any shapes or textures.

Does anyone have any experience with this sort of thing they might relay to me? It seems like a common type of thing to do, there are many unmanaged OpenGL DLLs out there that I’m sure people are trying to load into C#! Thanks -

Would you mind describing your situation in some detail?

Off hand, I don’t see why you should have any trouble with this, at least in principle. .NET’s interop layer can handle traffic across domain boundaries like this with ease. As with any OpenGL app, you need only be sure you have a properly initialized OpenGL render context, and that it’s current (wglMakeCurrent) at the time of your API calls.

I have no clue about the library you’re using, so I can say with total confidence that I’m not quite sure what to tell you, except to say that my experience has been that .NET is extremely forgiving in these matters, and nigh foolproof.

If by chance the library creates a render context or in some way modifies the one in use, you should check to see that your states are what you think they should be on return from all calls into it.

If multiple render contexts are in play, a wglShareLists call may be necessary to insure list spaces are available to all RCs involved (e.g., so texture names become global among the shared contexts). And, as always, make sure your OpenGL operation is squeaky clean (i.e., glGetError should always return GL_NO_ERROR).

Lastly, I hope you (or your library) is not inadvertently trapping and ignoring an important exception.

In a nutshell, this should most certainly work, so it’s probably a simple oversight somewhere. But without more particulars, it’s difficult to say for sure.

I made some tests and found no problems…


extern "C"
  __declspec(dllexport) int fnGLTest();


#include <gl/gl.h>

__declspec(dllexport_API int fnGLTest()
  glColor3ub(0, 255, 255);

  glVertex2d(0.5, 0.1);
  glVertex2d(0.9, 0.6);
  glVertex2d(0.1, 0.6);

  return 42;


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;

using OpenGL;

namespace WindowsApplication1
  public partial class Form1 : Form
    [DllImport("GLTest.dll", SetLastError=true)]
    public static extern int fnGLTest();

    public Form1()
      openGLControl1.OpenGLSetup(32, 24, 0);

    void Renderer()
      if(openGLControl1.Size.Height==0) return;
      if(openGLControl1.Size.Width==0) return;

      gl.Ortho(0, 1, 0, 1, -100, 100);




      fnGLTest(); // Changes the color and draws a triangle

      string msg="Test123";

      gl.RasterPos2d(0.3, 0.9);
      gl.CallLists(msg.Length, gl.UNSIGNED_BYTE, msg);

    private void openGLControl1_Paint(object sender, PaintEventArgs e)

Anyway, in first place I thought that it is possible that the managed code and the ummanaged code are running in different threads (OpenGL-Contexts are thread local), but then glColor() couldn’t have worked, too.

So I guess, it’s something within the library you tried to use.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.