Schlagworte
Empfohlene Artikel- What's going on with php object-relational mappers Giorgio
- Mistakes of a freelancer Giorgio
- Is Scala Not “Functional Enough”? Daniel Spiewak
Tagarchiv: .NET
Der Blog ist umgezogen! Du kannst den Artikel HIER finden.
Möchte man Netzwerkspiele oder sonstige netzwerk-fähige Anwendungen schreiben, findet man eine ganze Menge guter Bibliotheken für C++ im Internet. Im .NET Bereich ist die Auswahl jedoch nicht gerade groß, dafür gibt es eine ausgezeichnete C#-Bibliothek namens Lidgren, die fast keine Wünsche offen lässt.
Lidgren setzt auf das Netzwerkprotokoll UDP (User Datagram Protocol), baut jedoch auch Charakterisken einer TCP-Verbindung nach, was die Bibliothek sehr flexibel macht. Man kann als Programmierer selber entscheiden wie wichtig die Daten sind, die man versendet und ob die Reihenfolge beim Empfänger genau stimmen muss.
Die Besonderheit des UDP-Protokolls besteht ja darin, dass Pakete verloren gehen können, in einer anderen Reihenfolge ankommen können … und zu allem Überfluss natürlich auch kaputt ankommen können. Alle diese Nachteile haben allerdings den Vorteil, dass diese Übertragungsart sehr schnell ist, denn das UDP-Protokoll muss nicht ständig die Reihenfolge der Pakete überprüfen. Auch werden keine Empfangsbestätigungen verschickt und dann ggf. Pakete mehrmals versendet.
Lidgren vereint die Stärken von UDP und TCP. Jede Nachricht, die man versendet, bekommt einen Kanal zugewiesen, der den Nachrichtentyp festlegt. Folgende Kanäle sind möglich:
- „Unreliable unordered“ – Reihenfolge der Nachrichten ist unbestimmt; Nachrichten können verloren gehen.
- „Reliable unordered“ – Alle Nachrichten kommen an; Reihenfolge ist unbestimmt
- „Sequenced“ – Nachrichten können verloren gehen; Reihenfolge wird eingehalten
- „Ordered“ – Alle Nachrichten kommen in der vorgesehenen Reihenfolge an (früher oder später)
Die Netzwerkbibliothek beherrscht darüber hinaus noch weitere Funktionen wie das kontrollierte Drosseln des Netzwerktransfers (Bandwidth Throttling), Verschlüsselung und die Zeitsynchronisation. Auch sehr interessant ist, dass man – speziell zum Testen – einen künstlichen Lag oder eine Wahrscheinlichkeit für verloren gehende Pakete definieren kann.
Viele kennen sicherlich die Codeanalyse von Microsoft, die auch in einige Editionen der Visual Studio Produkte integriert ist … nun gibt es eine Open Source Alternative namens Gendarme, die innerhalb des Mono Projekts entwickelt wird.
Mit Gendarme kann man Probleme in seinem .NET-Code finden und leicht beheben. Neben echten Problemem werden von dem Analyse-Tool aber auch sehr viele Vorschläge und harmlose Warnungen angezeigt, die für ein besseres OOP-Design sorgen sollen. So meckert Gendarme z.B. bei sehr langen Methoden, deckt mögliche Threading-Probleme auf und sorgt allgemein für besseren und stabileren Code.
Aktuell gibt es einen Assistenten, der nach dem Auswählen von .NET-Assemblies einen Report ausgibt. In Zukunft wird es sicherlich auch eine Integration in ausgewählte IDE’s geben, ein Addin für MonoDevelop ist bereits in Arbeit.
Vor einiger Zeit bin ich auf das Open Toolkit gestoßen, einen sehr coolen OpenGL/OpenAL .NET-Wrapper. Anders als z.B. Tao funktioniert das Toolkit bei mir auch problemlos unter Linux/Ubuntu. Außerdem bietet OpenTK zusätzlich zur normalen C-API von OpenGL/OpenAL viele High-Level-Klassen. Besonders interessant ist für mich das einfache Zeichnen von Text, der dann auch noch gut aussieht.
Ein weiterer Pluspunkt: Es gibt ein Winforms-Control, was mit Mono und .NET gleichermaßen funktioniert und so erstmals die Entwicklung von CrossPlattform-OpenGL-Programmen mit .NET möglich macht.
Da es bisher kein Stable-Release gibt, sind jedoch Veränderungen der Schnittstelle an der Tagesordnung. Dafür kann man aber auch noch selber Patches einsenden, um diese zu verändern. So habe ich nun beispielsweise Unterstützung für Bezier-Kurven nachgereicht, sowie die Anbindung von Mathe-Klassen an die OpenGL-API ermöglicht.
Bekanntermaßen muss man bei vielen Matrix-Funktionen in OpenGL einen Zeiger übergeben, der auf das float[]-Array zeigt. OpenTK bringt eine Reihe von nützlichen Strukturen wie Vector3 oder Matrix4 mit, mit denen der sichere Umgang mit OpenGL problemlos möglich ist. Auch in Sprachen, die ohne Zeiger auskommen müssen – wie Visual Basic. Beispiel:
Vector3 start = new Vector3(1.0f, 0.0f, 5.0f);
Vector3 end = new Vector3(5.0f, 3.0f, -6.0f);
Matrix4 projection = Matrix4.LookAt( .);
GL.LoadMatrix(ref projection);
GL.Color4(Color.Green);
GL.Begin(BeginMode.Lines);
GL.Vertex3(start);
GL.Vertex3(end);
GL.End();
So einfach war OpenGL-Programmierung noch nie