Gedanken über unabhängige Grafikdarstellung

[LuckyBlade]

Hi Leute,

ich mache mir momentan ein paar Gedanken über Grafikdarstellung in meinem kleinen 2D Projekt.

Momentan sieht die Klassenstruktur so aus:


Ich habe ein Interface IGraphic, welches von BaseGraphic implementiert wird.
Von dieser Klasse werden wiederrum die konkreten Klassen abgeleitet (Momentan SDL_Graphic und OpenGL_Graphic).

Diese werden mit der Funktion draw() auf das Globale ScreenSurface (SDL_Surface) gemalt.

Da es ja sein kann, dass ich vllt mal in Zukunft eine neue Klasse wie z.b. DirectX_Graphic o.ä. hinzufügen möchte
wird die sache mit dem SDL_Surface als ScreenSurface ja hinfällig.

Deshalb habe ich mir folgenden Entwurf ausgedacht:


Hier läuft alles über die speziellen GraphicManager.
Die Oberklasse dieser Manager hat ein Array mit IGraphic Pointern.

Die Idee dahinter ist, dass jede IGraphic Implementation sich selber beim GraphicManager "einschreiben" muss. Am Ende jedes Frames werden alle IGraphicen im Array auf das Surface des jeweiligen GraphicManagers gemalt (Die müssten dann halt jedesmal die konkreten Klassen casten). Danach wird das Array geleert und jeweils wieder neu befüllt.

Mich würde nun interessieren was gegen so eine Implementierung spricht und ob der eine oder andere von euch vllt eine bessere Idee hat.

[Schrompf]

Wenn Du einen ehrlichen Kommentar haben willst: tu es nicht. Aus folgenden Gründen:

a) Du gewinnst nichts. Wenn Du nur einen OpenGL-Backend schreibst, kommst Du mit sehr viel weniger Arbeit ans Ziel und hast langfristig weniger Pflegeaufwand.
b) Falls Du es doch machst, dann nimm keine Interfaces und Konstruktion zur Laufzeit. Eine ganz banale Unterteilung mittels Präprozessor und #ifdef reicht. Du vermeidest damit aber den Overhead für die virtuellen Funktionsaufrufe, die bei solchen Basisfunktionen mit Abermillionen Aufrufen pro Sekunde potentiel mächtig ins Gewicht fallen.

Einzig der Grafikmanager könnte nützlich werden: alle Zeichenaufrufe sammeln, sortieren und ausführen. Lohnt sich bei 2D-Operationen aber eigentlich nicht, und gelegentlich musst Du absichtlich erst die einen und dann die anderen Zeichenaufrufe ausführen. Auch diese Struktur wird Dir also früher oder später Ärger machen.

[LuckyBlade]

Wenn Du einen ehrlichen Kommentar haben willst: tu es nicht. Aus folgenden Gründen:

a) Du gewinnst nichts. Wenn Du nur einen OpenGL-Backend schreibst, kommst Du mit sehr viel weniger Arbeit ans Ziel und hast langfristig weniger Pflegeaufwand.
b) Falls Du es doch machst, dann nimm keine Interfaces und Konstruktion zur Laufzeit. Eine ganz banale Unterteilung mittels Präprozessor und #ifdef reicht. Du vermeidest damit aber den Overhead für die virtuellen Funktionsaufrufe, die bei solchen Basisfunktionen mit Abermillionen Aufrufen pro Sekunde potentiel mächtig ins Gewicht fallen.

Danke erstmal für die Antwort. :)

zu a) Es geht mir ja nicht darum SDL oder OpenGL zu verwenden sondern die Grafikschnittstellen einfach erweitern zu können. Z.b. später eine zusätzliche Implementierung von IGraphic für Grafiken auf Android Geräten (Wobei da aber so weit ich weiß auch OpenGL benutzt werden kann).

zu b) Den Weg gehe ich bereits. Ich hab eine GraphicsFactory Klasse welche mittels #ifdef "herausfindet" welche Implementation von IGraphic erstellt werden soll. Die Sache mit den Interfaces hab ich mir durch das http://www.amazon.de/Game-Coding-Comple ... 788&sr=8-1 Buch angeeignet. Wusste nich das Virtuelle Funktionsaufrufe so viel Overhead verursachen dass das kritisch werden könnte.

[j.klugmann]

Auf Android läuft OpenGL ES, die Unterschiede sollten sich aber bei einem korrekten Aufbau des Frameworks leicht kompensieren lassen.

[Top-OR]

Du vermeidest damit aber den Overhead für die virtuellen Funktionsaufrufe, die bei solchen Basisfunktionen mit Abermillionen Aufrufen pro Sekunde potentiel mächtig ins Gewicht fallen.

Wobei: das mit den Abermillionen pro Sekunde sehe ich nicht GANZ so kritisch.
Wie ich das so sehe, ist ein Objekt ja dann ein ganzes Bild/Sprite oder dergleichen.

Und die Anzahl der sichtbaren Sprites pro Bild * x FPS wird sicher nicht in die Abermillionen gehen (wenn man denn kein Partikelsystem oder dergleichen on-top draufsetzt). Das sind dann "nur tausende", wenns komplex wird, oder seh ich das zu easy?

Und mit Get-/SetPixel wird man doch nicht ständig auf alle Pixel einzeln losgehen?!?!??? Dann könnte man sich Gedanken über ne Bündelung machen: getPixels()/setPixels() oder sowas...

[Schrompf]

Get/SetPixel braucht man nach meiner Erfahrung nur sehr selten, aber es ist nützlich. Ich würde dann aber eher eine Lock()-Funktion erfinden, die eine Beschreibung des Speicherbereichs zurückgibt. Partikelsysteme dagegen sind eher der Standard als die Ausnahme - wir hatten bei Splatter im Durchschnitt 15k Sprites durch die Gegend fliegen, davon 12k für Partikel und Trümmer. Alles andere kommt nicht auf diese hohen Zahlen, da hast Du Recht. Mit 15k bei 60fps sind wir schon bei einer knappen Million.

Virtuelle Funktionen sind jetzt nicht der Killer an dem ganzen System. Für mich sieht die Skizze nur aus, als hätte jemand gerade UML und Design Patterns für sich entdeckt und sieht jetzt überall Möglichkeiten, die zu benutzen. Die Leute bedenken dabei aber nicht, dass jede Codezeile, die sie schreiben, auch Pflegeaufwand nach sich zieht. Und es ist in diesem Fall einfach nutzlos, da ein abstraktes Interface und noch einen Manager oder eine Factory reinzudrücken, wo eine banale Klasse ausreicht, die intern mit #ifdefs die verschiedenen Implementationen unterscheidet. KISS ist immernoch die Prämisse des Tages.

[Krishty]

Was ist denn IGraphic überhaupt? Kriegt davon am Ende jedes Objekt eins, oder ist jedes Objekt eins, oder werden die getrennt von den Objekten abgelegt und verwaltet?

Ich gehe bei sowas eigentlich immer einen radikalen Weg: Jede Entitiy hat einen void-Zeiger, mit dem der Renderer (und nur er) machen kann, was er will. Wird eine neue Einheit erzeugt, legt er da seine Puffer, Matrizen oder sonstwas ab. Das Programm weiß nicht, dass sowas wie ein Renderer überhaupt existiert; nur er kennt die Strukturen hinter dem Zeiger und ergo ändert sich auch nichts, wenn man ihn wechselt.

Die Daten hinter dem Zeiger sind dann pure Datenstrukturen mit fast keinen Methoden, so gut wie keiner Vererbung und absolut null Schnittstellen – u.a. weil ich finde, dass Rendering ein überwiegend funktionales Problem ist und Objektorientierung da mehr kaputtmacht als sie nützt. Spielobjekte rendern sich nicht, sie werden gerendert. Und eine Klasse, die am Ende nur aus Gettern und Settern von API-Dingen besteht, macht für mich kein Objekt.

In deinem Fall würde ich dann statt zwei Schnittstellen und sechs Klassen nur eine Klasse (Renderer) und drei oder vier Datenstrukturen haben.

Das setzt aber voraus, dass du äußerst generalisierte Datenstrukturen mit anwendungsunabhängigen Objektbeschreibungen hast, aus denen sich alle Programmaspekte ihre Daten rauspicken können ohne, dass sie dabei einen Schritt z.B. auf den Renderer zu machen müssen – also sorgfältige Überlegung, was du brauchst und nicht brauchst, und ein Gefühl dafür, wie Eigenschaften zu kategorisieren sind. Ich persönlich habe das nie zu meiner Zufriedenheit hingekriegt; obwohl ich mir hundertprozentig sicher bin, dass meine Versuche sauberere Strukturen hervorbrachten als alles, was man mit Schnittstellen jemals hätte erreichen können.

[Top-OR]

KISS ist immernoch die Prämisse des Tages.

Ja, da haste Recht. Ich neige auch gern dazu, Dinge nen Tick zu verkomplizieren... :shock:

Mein Chef erinnert mich auch gerne daran. (DER meint mit KISS dann aber eher ein frickeliges Bashscript, weil schon ein Perl-/PHP-Script "der Overkill" ist. :roll: )

[LuckyBlade]

Was ist denn IGraphic überhaupt? Kriegt davon am Ende jedes Objekt eins, oder ist jedes Objekt eins, oder werden die getrennt von den Objekten abgelegt und verwaltet?

IGraphic is einfach nur die Schnittstelle für einfache Grafikobjekte bzw Datenstrukturen (z.b. SDL_Surface). Die Klasse RenderableGameObject hat eine Beziehung zu IGraphic.

In der Tat hatte ich auch erst die Sache mit dem void pointer der dann entsprechend gecastet wird...Aber irgendwie fand ich das "dreckig" , daher hab ich es geändert...Kann damit irgendwie besser leben.

Für mich sieht die Skizze nur aus, als hätte jemand gerade UML und Design Patterns für sich entdeckt

Wie gesagt, ich halte mich dabei nur an dem was ich im o.g. Buch gelernt hab. (Unter anderem steht in so gut wie jedem Design Pattern Buch was ich bis jetzt gelesen hab das man immer am besten auf eine Schnittstelle als auf eine konkrete Klasse programmieren sollte, daher hab ich hier jetzt mal konsequent das Design durchgezogen)

Dass das nicht die performanteste Lösung ist,wusste ich allerdings nicht.Da muss wohl noch etwas umstrukturiert werden.

[kimmi]

Nun ja, per se sind Interfaces nicht per se schlecht. Man kann durchaus Interface benutzen, um eine Schnittstelle zum Generieren des Renderer's zu bauen. Aber man sollte schon abwägen, ob man das auch wirklich braucht. Und die zeitkritischen Teile als Interfaces sind in der Tat riskant. Jedoch wird die Praxis, eine Render-API hinter einem solchen zu verstecken, von recht vielen Engine's umgesetzt. Mir fallen da spontan Ogre und Irrlicht ein.

Gruß Kimmi

[Chromanoid]

Vielleicht als Inspiration: http://code.google.com/p/libgdx/
Ansonsten kann ich bei 2D Projekten eigentlich auch uneingeschränkt Flash empfehlen. Das ist mittlerweile wohl das portabelste Format bezüglich 2D Spiele und AS3 ist als gute leichtgewichtige Mischung aus Java und C# ziemlich angenehm zu programmieren. Für Interfaces kann man auch Data Binding einsetzen, das kann Flex eigentlich genauso gut wie WPF.

[Top-OR]

Ansonsten kann ich bei 2D Projekten eigentlich auch uneingeschränkt Flash empfehlen. Das ist mittlerweile wohl das portabelste Format bezüglich 2D Spiele und AS3 ist als gute leichtgewichtige Mischung aus Java und C# ziemlich angenehm zu programmieren. Für Interfaces kann man auch Data Binding einsetzen, das kann Flex eigentlich genauso gut wie WPF.

Dem MUSS ich uneingeschränkt zustimmen.

Flash ist ne super Sache für sowas (auch wenns Steve nicht wahr haben will) und wenn man ein bissel Disziplin an den Tag legt, kann man mit Actionscript3 auch ganz ordentliche Dinge machen.

Wir haben in der Firma auch einige Projekte, in denen wir inzwischen Flash für Medieninhalte einsetzen [so lässt sich der Content u.U. besser outsourcen ;-)]. Das Ganze läuft dann unter Windows in einem von uns programmierten "Exe-Host" (C++), der über ActiveX das eigentliche Flash-Objekt "laufen" lässt, dort von Zeit zu Zeit ein paar Parameter reinkippt (ExternalInterface) und noch ein paar Monitoring-Aufgaben (Heartbeat, Kommunikation mit weiteren Rechnern/Servern) übernimmt. Wenns denn um „neue“ Inhalte geht, tauschen wir nur das Flashfile (swf) aus und gut is. So haben wir Medieninhalte/Medienlogik vom Verwaltungskram getrennt.

Man muss halt prüfen, obs ne Option für das Projekt ist, was man auf dem Tisch hat. Es ist sicher nicht das Allheilmittel, aber u.U. ne coole Lösung!

[Chromanoid]

Ansonsten gibt es für Flash ja noch AIR und Exe packer (ohne ActiveX Container)... Und selbst für das iPhone kann man ja mittlerweile exportieren, dann halt leider ohne dynamisches Laden von Klassen/SWF Files aus dem Internet... Und die Entwicklung kostet Dank FlashDevelop und FlexSDK ja auch nur noch Zeit...