Als Folge meiner recent question über .NET Compact Framework Debuggen, versuche ich derzeit, OpenGL ES von einem .NET Compact Framework und eine .NET Framework-Anwendung. Ich benutze this wrapper, die für OpenGL ES erstellt wurde und importiert von libGLES_CM.dll.DllImport mit verschiedenen Einstiegspunkten (verschiedene DLLs für den gleichen Import in verschiedenen Projekten)
Um das Debuggen zu erleichtern, erstellte ich eine .NET Framework-Anwendung, erstellte das Importprojekt für OpenGL ES und EGL mit denselben Dateien (nur für Desktop-Framework erstellen), erstellte Konstanten für die DLL-Namen, aus denen sie importieren libGLESv2.dll und libEGL.dll unter Windows und von libGLES_CM.dll auf CF. Die DLLs stammen vom PowerVR OpenGL ES Emulation SDK (das Zielgerät hat einen PowerVR SGX) und sind nur ein OpenGL ES-Wrapper um die echte OpenGL-Implementierung. Und hier kommt das Problem:
In der Wrapper-Bibliothek sind die OpenGL-Funktionen in zwei statischen Klassen (gl und egl) und haben den üblichen Namen, aber ohne das gl/egl-Präfix, so egl.GetDisplay()
statt egl.eglGetDisplay()
. Sie werden folgendermaßen importiert:
[DllImport(DllName, EntryPoint = "eglGetDisplay")]
static extern IntPtr GetDisplay(EGLNativeDisplayType display_id);
Dies funktioniert gut auf dem Compact Framework. Im Desktop-Projekt wird eine EntryPointNotFoundException ausgelöst - weil die Funktionen wie benannt sind (Randnotiz: die WMD fängt Alt-Gr + Q für Blockquotes, das ist das At-Symbol auf deutschen Tastaturlayouts. Ich musste dieses einfügen.) nach Dependency Walker.
Ich habe es geschafft, den Unterstrich zum Funktionsnamen für das Desktop-Projekt hinzuzufügen, aber nicht für den CF, indem ich eine Zeichenkette konstant auf leere Zeichenkette oder "_" setze und sie mit dem Einstiegspunktnamen verkette, so sieht es so aus:
[DllImport(DllName, EntryPoint = FunctionPrefix + "eglGetDisplay")]
Kein Problem hier. Aber die Funktion wird immer noch nicht gefunden, weil das @ 4 (was genau ist das?) Fehlt. Wenn ich das @ 4 hinzufüge, funktioniert das, aber da alle Funktionen hier unterschiedliche Werte haben, musste ich dies per Hand machen und wahrscheinlich wären die Zahlen für die CF-Version nicht korrekt. Hier kommt der seltsame Teil:
Wenn ich nur den Einstiegspunkt nicht angeben und stattdessen die Funktion benennen, wie es benannt werden soll, funktioniert der Import gut! Nun ist das hässlich wegen des Doppelpräfixes (Name der statischen Klasse und Funktionsname), obwohl ich das umgehen könnte, indem ich einfach einen Wrapper für diesen hinzufüge. Da ich mich nicht stark auf diese Funktionen verlassen werde (brauche nur eine ziemlich einfache 2D-Engine), wäre das kein Problem, aber es fühlt sich einfach nicht richtig an.
Warum funktioniert es nicht, wenn der Einstiegspunkt angegeben wird? Was kann ich tun, damit es so funktioniert, wie es sollte?
Ich hoffte, es wäre einfacher. In diesem Fall denke ich, dass ich es vorziehe, sie mit dem richtigen Namen und ohne Angabe des Einstiegspunktes zu importieren, und dann einfach einen Wrapper um sie zu legen, um den Namen schön zu machen. – OregonGhost
@your edit: Ja, ein Kollege schlug eine ähnliche Lösung vor. Aber wie ich bereits sagte, brauche ich nicht so viele Funktionen und werde sie sowieso in meine eigene kleine Bibliothek einpacken müssen (Sie wissen, mit Klassen und Objekten anstelle von freischwebenden Funktionen) ... Wir werden sehen;) – OregonGhost
Noch nie von T4 gehört, habe es jetzt nachgeschlagen. Sieht lustig aus! –