TrumEngine: Entwurf

[TrommlBomml]

So, wie versprochen hier mein erster entwurf der 2D-Engine. Dazu hab ich mit paint ein Klassendiagramm entworfen, es ist nur ein Grober entwurf, die genaue ausarbeitung erfolgt später, es wird aber (wenn ihr nicht bessere vorschläge habt), genau diese Klassen beinhalten:



Kurze erklärung zu den einzelnen Klassen:

CGraphicDevice:

Kümmert sich um die erzeugung / freigabe von direct3D und den rendervorgang von sprites und schrift. Dient auch zum Einstellen von den rendervorgängen, von denen mir z. B. Auto-Sorting mit Hilfe des Z-Buffers vorschwebt und Texturfilter, sowie multisampling und Alphablendingoperationen.

CViewport:

verwaltet einen Sichtbaren Viewport. in direct3d hat man immer einen "aktiven" viewport. im normalfall ist das der gesamte bildschirm bzw. fensterinhalt. da es ja eventuell nötig ist, dass man mehrere ausschnitte auf dem Bidlschirm braucht, bietet die engine multiple viewports an, die automatisch verwaltet werden. auch koordinatenvergabe soll unterschiedlich möglich sein (alle viewports dassselbe globale, oder jedes ein lokales). die umrechnungen sollen implizit passieren, das ihr da wenig arbeit habt und euch lästige überlegungen erspart bleiben

CRessourceManager:

diese klasse verwaltet die gesamten geladenen resourcen (werden Sprites, Animated Sprites und Fonts sein) und kümmert sich um automatische freigabe. wird als singleton im hintergrudn arbeiten, d. h. man muss sich ähnlich wie bei c#/java mit dem garbage-collector um die freigabe der ressourcenobjekte keine gedanken machen.

CRessource:

abstrakte basisklasse, von denen alle ressourcen abgeleitet werden, die der ressourcemanager verwalten soll.

CSprite:

CSprite dient zum darstellen von Bildern, mit alphablending, farbveränderungen, echtzeit skalierung und rotation. auich farbverfremdungseffekte sind damit möglich. wird auf basis von vortransformierten Rechtecken (zwei dreicke, als trianglestrip) berechnet. natürlich sind auch ausschnitte der Textur mit CSprite zu rendern!

CAnimSprite:

Bietet möglichkeiten zum anzeigen von animierten bildern, die als textur nacheinander in frames gespeichert sind. es werden verschiedene arten der animation möglich sein (vorwärts, rückwärts, jojo), unter stagnierender oder veränderlicher zeit pro frame verarbeitung. wird ohne probleme mit alphablending, farbverfremdungen skalierung und rotation kombinierbar sein.

CFont:

dioent zum darstellen von Schrift. wird vorerst auf basis von Texturen mit dem Schriftzeichen im ascii-zeichensatz erfolgeb, später wenn ich es hinbekomme werden die texturen mit hilfe von gdi generiert (spart nen bissle aufwandt )

das sind so die ideen die ich zurzeit dafür habe. mögliche erweiterungen, die ich aber erst bei abarbeitung der grundfeatures adden würde:

- Shadersupport (ermöglicht weitere effekte, da wäre eine art plugin-funktion möglich, also das leichte integrieren neuer effekte unter gelcihen bedingung der nutzung durch den user des effekts!)

Aktueller Stand:

CGraphics: Grundgerüst fertig (erzeugen, Viewports erzeugen, setzen und TeilViews farbe setzen -> bildschirmlöschen)
CViewport: Grundgerüst fertig (einfache erzeugung von Viewports)
CSprite: 100% Fertig (Rendern, gesamt, Ausschnitte, Alphablending, Color-Manipulating)
CAnimSprite: 100% Fertig
CFont: 100% Fertig
CPlanetMesh: Planeten erzeugen + Textur laden, zwei effekte, Rendern

Aktuelles SDK (Stand 14.08.2008):

download

bitte readme lesen!

[Sir Pustekuchen]

Okay... klingt so schonmal ganz gut.

Zur Klassenbezeichnung:

CResourceManager gibt es bei mir schon Die abstrakte Klasse kümmert sich um das Laden von Texten aus der StringTable. Ich schlage daher vor deine Klasse in CD3DResourceManager umzubenennen. Dann könnte man auch noch die CResource Klasse in CD3DResource umbenennen. Anonsten sieht die übersicht aber schön übersichtlich aus.

Zu deinen restlichen Fragen:

Soll das ganze in einer dll landen?

Von mir aus kann es das. Der einzige Nachteil wäre eigentlich, dass nur du an die Implementierung herankommst. Falls da mal ein paar kleine Änderungen von Nöten sein sollten, hätten wir ein Problem. Von mir aus könntest du es auch in eine Lib packen. Prinzipiell ist mir die Weitergabeform egal: also entweder Klassen, Libs oder dll. Klassen mit eigenem Namespace sind aber wahrscheinlich am flexibelsten. Dann lerne ich auch gleich noch was

Reicht es für den fenstermodus (spart mir nen bissle arbeit)?

Fenstermodus reicht aus. BotE wird per SplitterView in 4 Teilfenster zerlegt. Jedes Fenster hat seine eigenen Methoden und arbeitet unabhängig von den anderen. Somit könnte man auch unabhängig D3D oder etwas anderes in den Fenstern nutzen.

könnt ihr mit der einschränkung leben, dass die geladenen bilder auf 2^n-basis sind (muss nicht sein, ist aber 1. schneller und 2. NOPOW2 wird nicht von jeder graka unterstützt!)?

2^n ???

[TrommlBomml]

CResourceManager gibt es bei mir schon Die abstrakte Klasse kümmert sich um das Laden von Texten aus der StringTable. Ich schlage daher vor deine Klasse in CD3DResourceManager umzubenennen. Dann könnte man auch noch die CResource Klasse in CD3DResource umbenennen.

k, das werd ich dann mal ändern.

also entweder Klassen, Libs oder dll. Klassen mit eigenem Namespace sind aber wahrscheinlich am flexibelsten. Dann lerne ich auch gleich noch was

dann werd ichs einfach als klassen unter einem namespace machen, wie ich den nenn überleg ich mir noch. denn warum sollte ich euch src vorenthalten^^.

2^n ???

2 hoch n wollt ich damit ausdrücken . falls du das nicht weisst, was das genau bedeutet, erklär ich dir das gern^^.
texturen werden am liebsten in einer größe von potenzen zur basis 2 gespeichert (also z. b. 64x64, 128x128 usw.), diese können besonders schnell verarbeitet werden. deswegen empfiehlt man auch, dass man sie so in diesem formaten laden soll, um größtmögliche performance rauszuholen. man kann aber einstellen, dass man auch andere größen (das meint ich auch mit NOPOW2 = no power of 2) laden kann. sonst, wenn man andere größen lädt, wird die textur auf das nächste 2^n angepasst (wenn du z. b. 513 x 219 bild hast, wird das auf 1024 x 1024 aufgebläht , viel ungenutzter platz).

[Sir Pustekuchen]

Danke für deine Erklärung. Wenn die 2^n Sache ansonsten keine Nachteile für uns bringt, dann können wir diese nutzen. Er sollte natürlich nicht die Grafiken vergrößern oder anderweitig verändern. Ein Grafik von 200x150px sollte ingame dann immernoch so aussehen und nicht plötzlich quadtratisch sein. Ich kenne die Auswirkungen dieser 2^n und NOPOW2 nicht. Ich kann jedenfalls nur soviel sagen, dass wir Grafiken mit verschiedensten Auflösungen benutzen.

[TrommlBomml]

nein, also skaliert wird da nix. ich hab ma nen beispiel was directx macht, wenn die textur eine 2^n auflösung haben muss und diese bilddatei das nicht bietet:



das wäre also NUR ein speicherverlust, es würde keine qualitätseibußungen geben. das einzige, was sein kann sind performanceinbußungen, wenn man alle größen zulässt. leider kann ich das nicht genau einschätzen, wie stark diese sind. wenn euch das bissle overhead nicht stört bei den texturen, dann würde ich empfehlen, diese standardeinstellung zu lassen. später können wir das immer noch umstellen. und auch nochmal zur erinnerung: ältere grafikkarten unterstützen das manchmal nicht, und das kann zu darstellungsfehlern kommen^^.

[Sir Pustekuchen]

Okay, dann lassen wir es bei 2^n, wenn beim Anzeigen der Textur nur das echte Bild angezeigt wird. Ich weiß ja nicht wie du es in der Engine implementieren magst. Schlussendlich sollte nur der Affe angezeigt werden und nicht der schwarze Bereich andere Teile des Bildes überdecken. Wie der die Grafik im Speicher der Karte hält ist mir eigentlich egal. So viel Platz wird diese nicht verbrauchen.

[TrommlBomml]

wenn dann stell ich das natürlich so ein, dass man nur den affen sehen würde. da muss ich dann halt vor dem laden überprüfen, wie groß die bilder sind. per hand datei öffnen und an der stelle auslesen, wo die größe gespeichert ist, für bitmaps weiss ich das ausm kopp, den rest müsste man mal nachschauen, dazu wäre hilfreich zu wissen, welche dateiformate für bilder ihr verwendet.

direct3d beherrscht folgende (welche die auch eventuell in frage kämen davon, den rest hab ich mal rausgenommen):

windows bitmap (*.bmp)
directdraw-surface(*.dds)
windows device independent bitmap (*.dib)
jpgs, png, tga

[Sir Pustekuchen]

Wir nutzen z.Z. eine Mischung aus JPG und PNG. Unser Ziel ist es aber, die Grafiken komplett auf PNG umzustellen. Dies ist ein verlustfreies Format (im Gegenteil JPG) und trotzdem komprimiert (im Gegenteil zu BMP). Außerdem bietet es eine Transparenzebene an. Von daher denke ich wird dies unser Favorit sein. Außerdem bekomme ich es mit der GDI+ zur Not auch noch geöffnet. Daher brauchst du die eigentlich nur um die PNG Unterstützung mittels D3D zu kümmern. Der Rest wird nicht benötigt.

Für Raumschifftexturen, falls Schiffsmodelle irgendwann einmal ins Spiel kommen, kann es passieren, dass das Format ein anderes ist. Dazu kann ich z.Z. aber nix genaueres sagen.

[TrommlBomml]

na das is auch wieder ne andere geschichte, da werden meistens nur 2^n artige textturen geladen, und dann isset egal. aba wenn es nur pngs werden, dann ist das schonmal ein wort, jpg kann ich ja trotzdem noch mit reinfrickeln. k, dann mach ich mich erstmal ans werk.

da ich nur vs 08 express hab, werd ich eine winapi-dlg basteln, um die engine zu testen. wenn es funktioniert, post ich ne demo mit kompletten code + binaries.

weitere anregungen fragen werden dann gleich mit eingearbeitet. nen bissle projektorintiertes material an bildern wäre blos nett wenn ich die bekomme, damit ich mich da gleich drauf einstellen kann.

@pngs:

man kann entweder die alphaschicht direkt nutzen, oder eine beim laden generieren, indem man eine bestimmte farbe als transparent, alphawert 0, definiert. ich werde beides einrichten, sodass es kompatibel bleibt.

und was ich vergessen hatte:

wie soll die fehlermeldung vor sich gehen?

- dateilog (ohne meldung)
- dateilog (mit meldung)
- asserts (eleganteste eigentlich)
- allein über rückgabewerte von funktionen -> andere klassen handlen den weiteren verlauf
- exceptions (die ich persönlich nicht mag, aber wenn ihr die ham, wollt mach ichs)

[Sir Pustekuchen]

Fehlerbehandlung habe ich bis jetzt ausschließlich über ASSERTS geregelt. In der Release sind diese natürlich nicht an, da gibts an kritischen Stellen nen VERIFY. Von daher reicht es wahrscheinlich aus, wenn du ebenfalls ASSERTS einbaust. Alternativ wäre ein Dateilog vorstellbar. Dies könnte vielleicht helfen, wenn Nutzer Abstürze haben und uns anschließend in einer Bugmeldung ein Error.log zuschicken können.

Wenn du Bilder und Grafiken aus BotE zum rumspielen schonmal benutzen magst, dann kannst du dir BotE hier im Forum runterladen. Wenn du es installiert hast, kannst du im BotE Verzeichnis/Graphics/... alle unsere Grafiken sehen. Alternativ könntest du diese auch in den entsprechenden Forenbereichen dir raussuchen. Aber mit einem installierten BotE hast du alles zentral an einem Ort.

[Malle]

Alternativ lohnt auch ein Blick auf unsere kommende Homepage zwecks Bilder: http://web9.delta442.server4you.de/joomla15/

[TrommlBomml]

so mal zum derzeigiten stand:

zurzeit lassen sich viewports setzen ( so viele man will) und zurzeit den Bildschirm löschen, sodass ich das ganze schonmal testen konnte, klappt auch wunderbar.

d. h. erstmal ist die entwicklung von CGraphicDevice und CViewport fertig (Grundgerüst). als nächstes werde ich ne Sprite-Klasse basteln

[Malle]

Zwischenfrage: Wir bräuchten zusätzlich noch eine Klasse zur Darstellung rotierender Planeten und drehbarer Schiffe, wobei hier 3D und 2D engine sich etwas vermischen. Passende Texturen hätte ich en mas anzubieten (Schiffsmodelle nur ein paar freie von turbosquid, die anderen kriegen wir erst wenn die komplette 3D Engine steht vom Ersteller), alle frei von http://www.celestiamotherlode.net runterlad- und verwendbar. Denke aber das wär eher was für den Schluss, um das ganze dann noch abzurunden .

[Sir Pustekuchen]

Ich hätte mal ne Frage zu ToolTips. Sind die mit D3D einfach anzuzeigen, oder müssen wir dafür weiterhin die MFC verwenden? Weil wenn dies mit D3D umzusetzen ist und danach besser ausschaut, brauch ich keine Energie darin verschwenden diese mit MFC einzubauen.

[TrommlBomml]

Zwischenfrage: Wir bräuchten zusätzlich noch eine Klasse zur Darstellung rotierender Planeten und drehbarer Schiffe, wobei hier 3D und 2D engine sich etwas vermischen.

ja, das sollte möglich sein, jedoch ist das ein wenig komplzierter in bezug auf die ganzen Viewports,a ber ist machbar und würde ich auch ganz zum schluss machen.

dafür brauche ich auch noch folgendes:

- Modelformat, am besten ladefunktion bereitstellen, oder formataufbau, dann bastel ich das selber^^

auch wäre mit 3d sehr viel in bezug auf lichteffekte möglich, die einfachen per-pixel reflection modelle bietet da schon geiles an^^.

Ich hätte mal ne Frage zu ToolTips. Sind die mit D3D einfach anzuzeigen, oder müssen wir dafür weiterhin die MFC verwenden? Weil wenn dies mit D3D umzusetzen ist und danach besser ausschaut, brauch ich keine Energie darin verschwenden diese mit MFC einzubauen.

hm naja, ganz einfach nicht. mit der schriftklasse ist das dann kein Problem, würde ich aber auch erstmal hintenan schieben. das das einwandtfrei klappt, setzt einige sachen voraus, und die kann ich jetzt aber noch nicht einschätzen, da musst du dich noch ein wenig gedulden

bedenkt auch, dass es sehr günstig ist (bzw. für d3d immer auch besser), dass ständig das bild neu aufgebaut wird, nicht nur dann, wenn sich was verändert.