2010-12-02 6 views
2

Das wird ziemlich vage Frage sein, aber ich frage mich, wie um das Problem im bekommen mit Blick auf ...Rahmen Agnostiker struct Ausgabe

ich zur Zeit viele verschiedene Projekte, die ich vor einiger Zeit geschrieben haben, dass alle haben einen ähnlichen Rahmen für die räumliche Partitionierung und Sortierung, jedoch wurde für jedes Projekt eine eigene Version dieses Frameworks implementiert. Sie sind alle grafisch basierten Anwendungen haben aber Implementierungen in:

  • Silverlight
  • WinForms (GDI)
  • XNA
  • DirectX
  • OpenGL (TAO)

Obwohl es 5 sind verschiedene Versionen dieses Rahmens sie alle genau das gleiche tun, nur verschiedene Objekte akzeptieren. Ein Beispiel wäre, dass GDI System.Drawing.Point für die meisten seiner zeichnungsbezogenen Aufgaben verwendet, während XNA Vector2 verwendet, jedoch sind sie beide Objekte, die ein X/Y darstellen, dasselbe gilt für die anderen Bibliotheken, einige speichern die x/y-Werte als int. float, double, aber letztlich im Herzen repräsentieren sie die gleichen Daten.

Die Hauptaufgabe des räumlichen Partitionierungs-Frameworks besteht darin, diese 2/3 dimensionalen Werte abzuarbeiten und Bäume zu erzeugen oder andere Sortier-basierte Aufgaben um diese Zahlen herum auszuführen.

Ich versuche derzeit, viele meiner verteilten Frameworks zu einem einzigen zentralisierten zu vereinheitlichen, so dass es ein einziges Projekt mit Tests geben kann, die beweisen, dass alles in Ordnung ist.

Also war mein erster Gedanke, einige agnostische Objekte zu erstellen, um mit diesem X/Y-Problem umzugehen, wie ein benutzerdefiniertes Point2D, Point3D, Quaternion, Rect usw. Allerdings müsste ich sie dann wieder in ihre native Version konvertieren, und wenn ich das für jeden Punkt in jedem Objekt bei jedem Renderzyklus tun würde, dann klingt das wie eine massive Leistungseinbuße (besonders wenn dieses Framework so leistungsfähig wie möglich sein soll).

Ich dachte über Schnittstellen, die dieses Problem lösen würden und nur das native Objekt intern auf den Implementierungsteil wickeln, aber ich bin immer noch nicht sicher, ob dies der beste Weg zu gehen ist, wie ive nie wirklich viel plattformübergreifend getan basierte Entwicklung musste diese Probleme nie lösen.

Wie auch immer, wir werden jetzt aufhören zu waffeln, und jeder Rat wäre großartig!

Antwort

2

Meine Empfehlung wäre, Ihre eigenen mathematischen Typen zu implementieren und all Ihre Berechnungen mit diesen zu machen. Ich würde wahrscheinlich XNAs als Basis verwenden. Nicht nur, weil sie ziemlich gut sind, sondern auch, weil Sie Open-Source-Implementierungen von Mono.XNA, SilverSprite oder XNATouch erhalten können. (Und natürlich das Framework selbst, in XNA.) Das spart Ihnen eine Menge Arbeit.

Das Hauptproblem, das ich sehen kann, ist, dass Ihre verschiedenen Plattformen verschiedene Arten verwenden. GDI verwendet Ganzzahlen, XNA, DirectX und OpenGL verwenden Floats mit einfacher Genauigkeit (allgemein) und Silverlight verwendet Floats mit doppelter Genauigkeit.

Wenn das nicht der Fall wäre, könnten Sie Ihren Typ einfach dem identisch aufgebauten nativen Typ zuordnen und vom JIT abhängig sein, um ihn zu optimieren.

Das Schöne an OpenGL, DirectX und XNA (ausgenommen Dinge wie SpriteBatch) ist, dass Sie der API grundsätzlich Ihr Datenlayout mitteilen - und Sie können intern verwenden, was Sie wollen.

Für GDI und Silverlight werden Sie wahrscheinlich ohnehin Schwierigkeiten haben, Ultra-High-Performance-Grafiken zu erstellen. Also würde ich nur den Treffer der Konvertierung zu Float und zurück nehmen. Schreiben Sie einfach die einfachen Konvertierungsfunktionen, wenn Sie Ihre Daten anzeigen möchten. Converting-Typen sind im Vergleich zum Rendering ein extrem kleiner, winziger Prozentsatz Ihrer CPU-Zeit.

(Ich habe dies tatsächlich getan für Silverlight -. Und es wirklich ist nicht der Mühe wert)

+0

Ja XNA ist so ziemlich die, die ich wiederholen möchte, und Sie haben den Nagel auf den Hit Kopf mit der Mathematik-Bibliothek, als das ist im Wesentlichen, was Bühne im an, als ob das an Ort und Stelle ist alles andere kann sie nutzen und die zugrunde liegenden nativen Methoden abstrahieren ... Die GDI und zu einem gewissen Grad die GDI-Implementierungen sind für Toolkit-basierte Anwendungen, so Sie müssen sowieso nicht so schnell laufen. – Grofit

Verwandte Themen