Moinsen,

ich werd mich bald mal an .NET und OpenGL versuchen und bin auf der suche nach einer vernünftigen Implementation... ich weiß DX wird hier besser supportet doch ich will bei GL bleiben. Ich hab kurz mal einen Blick auf OpenTK geworfen und gesehen das da die ganzen Funktionen alle anders heißen.. total verwirrend. Hat jemand damit schon erfahren (hab gesehen viele arbeiten mit C#)

Grüße
Thomas

Ja das hat auch Sinn das die anders heißen. Man will ja schließlich z.B. GL.DeleteTextures anstatt GL.glDeleteTextures schreiben
Der Rest sind spezielle Überladungen/Helper/Anpassungen für .NET, die Intellisense von VS hilft einen hier aber sehr gut aus.
Allerdings muss auch mal gesagt werden das OpenTK vergleichsweise schlampig implementiert wurde. Die schwerwiegensten
Probleme sind wohl die extrem fehlerhafte Integration Linq (-> F# kann man total vergessen) und einige Standartklassen die einfach
mal "versteckt" werden. Wenn ich jetzt allerdings mal an die Probleme mit XNA denke, dann sind die beiden wohl in etwa auf
gleicher Höhe ^^

Zum Glück gibt es aber genug andere Möglichkeiten. Nehe hat z.B. ein Tutorial das zeigt wie du dir die Funktionen selber laden kannst
und SDL ist wohl auch schon auf dem Weg. An sich bleibt aber VC++ der sauberste Weg. (und auch der einfachste wenn man bestehende Libs
laden will)

btw. Schau mal auf meine Homepage in meine VS Plugin "Toplist", dort gibts ein paar tolle Links

_________________
Meine Homepage

Also ich hab das OpenTK in Vergangenheit eine Zeit lang verwendet und hatte keine Probleme damit.
Kann das mit dem "Schlampig implementiert" nicht nachvollziehen.
Selbst im zusammenhand mit PhysX lief das ganz sauber, aber der Update-Zyklus ist sehr sehr langsam.
Toll ist dass auch die Vector und Matrix Klassen mitgeliefert werden.

Was du dir auch mal ankucken kannst, ist SharpGl.(Edit. Natürlich mein ich SharpGl )
Erfahrungen damit, habe ich allerdings keine.

Jonathan

_________________
Das mit dem Dx tut mir leid.

Oh nochn bissl offtopic zum Thema miese Fallen:
in .NET hat der finalizer Thread keinen Zugriff auf den GL Context ^^

_________________
Meine Homepage

Das ist in allen anderen Sprachen aber genauso. Nur, dass da in der Regel die Sachen aus dem gleichen Thread wieder freigegeben werden.

Mhh interessant, noch nie aufgefallen lol
naja werd demnächst wahrscheinlich eh alles auf JS umrüsten da ists dann auch egal ^^

_________________
Meine Homepage

Also ich hab es nun geschafft meine erste kleine OpenGL Anwendung mit VB.NET zu erstellen. VB ist ja eigentlich garnicht so schlecht und rel. Delphi ähnlich. Halt ein wenig ungewohnt...

Ist es denn überhaupt ratsam große 3D Projekte mit .NET zu realisieren? Oder holt einen vielleicht später irgendein riesen Nachteil ein? Warum sind die ganzen "großen" Engines alle in C++ geschreiben wenn .NET so toll ist?

1. Das ganze Framework muss erst mal geladen werden. Das Programm muss dann "gejitet"(Von MSIL in Maschinencode übersetzt) werden.(Ist aber kein Performancenachteil wärend der Laufzeit)
2. Das Framework verbraucht wertvollen Speicher (Der in einer normalen Anwendung fast egal ist, aber in einer Engine gehts um jedes MB(Naja fast ))
3. OGL oder DX können nicht direkt angesprochen werden, es müssen sogenannte Wrapper zwischengeschaltet werden, die dann zb. .Net String in Nullterminirte strings umwandeln (WAS ZEIT KOSTET)

Und so weiter.

In einer normalen Anwendung ist das noch gut zu verkraften, aber in einer Highend Gameengine?

Für dich wird das wohl kein alsogroßer Nachteil sein, denn in VB zb. C# hast du die Sachen viel schneller gecoded, als C++ und bis es sich lohnt, steigt unsereins (also wir Hobbyprogrammier ) sowieso aus.

Jonathan

_________________
Das mit dem Dx tut mir leid.

Nun eigentlich programmiere ich in Delphi (ich hasse C++).. und bin damit eigentlich sehr zufrieden. Problem ist allerdings das ich mit einem Kollegen zusammenarbeite der in .NET entwickelt. Also machen wir meistens immer doppelte Arbeit und müssen dann komplizierte IPCs programmieren damit unsere Progs zusammenarbeiten.. Da ist .NET natürlich viel einfacher, da man hier recht einfach Klassen mal schnell austauschen kann. Ich hab auch schon viel Zeit investiert zu versuchen .NET Klassen DLLs in Delphi einzubinden, habs aber nie hinbekommen. Wenn das ginge wären die größten Probleme der Welt gelöst

gabs da nicht mal irgendwie .NET für Delphi von Borland?????

_________________
Meine Homepage

jaien .. das war früher, ich glaube bis delphi 6 oder so.. Da hatte Borland nochmal das ganze Framework abgeschrieben... war aber großer Murks... Jetzt gibts nur Delphi Prism, was aber nur wie ein Plugin im VisualStudio funktioniert. Also nur bisschen Delphi Syntax im VS. Ändert aber nix daran das es .NET ist

naja haste halt nachher ne Sprache mehr im Portfolio

_________________
Meine Homepage

.NET ist doch popel easy... aber ich würde dir nicht empfehlen VB.NET zu nehmen.
Allein schon die tatsache das es keine program.cs gibt, bzw. Einstiegspunkt... und keine app.config etc.
Muss man alles irgendwie anderst machen... Achja und Array-Längen werden mit dem Index definiert *haha*.

Im ernst .NET hat man als Delphi Coder in 1-2 Tagen inne. Das Framework lernst du kennen während du Programmierst, man muss ja am anfang nicht alles auswendig wissen.

kannste eine Sprache kannste alle (es sei denn du kannst C oder hast studiert, dann kannste nix), der Teufel liegt aber immer im Detail. Ich sag nur Dynamics... yeeee in 99.9999% der Fälle funzt kein Where() weil Trolle net Updaten komm wir machen nen Addon....
Oder noch besseres Beispiel die ??? ^^
aber BTT habn paar lustige Klassen für OpenTK wennde interesse hast, kann ichse gern hochladen.

_________________
Meine Homepage