Also sicher wisst ihr bei dem Titel schon worum es geht, das hoffe ich zumindest, aber ich muss das Problem etwas erläutern, denn ich weiß sehr wohl, warum es nicht geht, und ich suche eher nach einer Lösung fuer das Dilemma

Ich habe eine Engine TEngine.

Bisher gab es neben dieser Engine noch einige Manager, die Global in einer seperaten Unit (Globals.pas) deklariert wurden und dann von jeder Datei aus verwendet werden konnten, solange die Globals.pas eingebunden wurde. Das heisst, in der Globals wurden alle Manager (zb. TFontManager, TTextureManager, TSceneManager, usw) erstellt und dann konnte man sie ueberall verwenden. Allerdings war das eher eine provisorische Lösung, weil globale Deklarationen ja immer nicht so elegant sind. Da die Manager eh zur Engine gehoeren, will ich sie nun zu Bestandteilen eben jener machen.

Ich lasse also in meiner Engine alle Manager erstellen. Soweit so gut.

Das Problem, das sich nun auftut, ist dass ich in einigen erschreckend oft auftretenden Situationen von einem Manager zugreifen muss. Ich kann zwar von der Engine runter auf den Texturenmanager gehen, aber ich kann zum Beispiel nicht vom TexturenManager hoch auf die Engine und dann runter zum Fontmanager, denn der TexturenManager kennt die Engine ja im Grunde gar nicht.

Also was ist die Lösung? Ein Zeiger auf die Engine in jedem Manager.

Ich übergebe also im Create eines jeden Managers einen Zeiger und speichere diesen als private Variable ab:


Das Problem ist nun aber, dass in der Texturemanager.pas die Klasse TEngine bekannt sein muss. Und zwar muss diese Klasse schon vor der zweiten Uses-Klausel im Implementation-Bereich bekannt sein, da dort oben die Klasse definiert wird:


Ich kann hier aber drueber die Datei Engine nicht einbinden, da in Engine bereits die Datei TextureManager eingebunden wurde. Daher würde dann dieser Zirkuläre Aufruf rühren.

Ich überlege also nun schon eine Weile, wie ich das möglichst elegant lösen kann.


Eine Idee kam mir vorhin: Ich über die Engine nicht als Typ TEngine sondern als Pointer also:


Leider funktioniert dann später kein Aufruf der Engine, es sei denn ich führe einen Typecast durch:


Um TEngine() aufrufen zu können, muss Engine aber wieder eingebunden sein. Das ist nun aber auch kein Problem mehr, denn alle Methoden der Manager werden zwar über der Uses-Klauses des Implementationbereiches deklariert, aber erst drunter mit Inhalt versehen, ich kann die Engine also dann lokal in der Unit nochmal einbinden.

Allerdings scheint mir dieser Weg, der mich zwar zum Ziel bringt, doch sehr umständlich und deswegen frage ich mal ganz dezent in die Runde, ob da wer "das Ei des Kolumbus" parat hat
Danke schonmal

eine möglichkeit sind include-dateien. Das ist vielleicht nicht die beste, aber immernoch eine Lösung.

Anders ginge es, indem du überlegst, ob nicht vielleicht alle Manager auf den gleichen teil von TEngine zugreifen müssen. Dann wäre es vielleicht den Aufwand wert, diesen Teil zu extrahieren und in eine eigene Unit zu packen, vorrausgesetzt, dass der ohne den rest von TEngine klarkommt.

Sonst bleibt dir nur, alles in eine Unit zu packen, was aber im prinzip der Includefile-Lösung entspricht, nur dass du das ganze nicht auslagerst sondern direkt in die Unit schreibst.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Hi,

eine andere möglichkeit wäre noch, wenn du in den Manangern einfach links zu den anderen Manangern erstellst, die du beim initialisieren von der Engine setzen lässt.




Bei meiner engine hab ich das gleiche problem übrigens auch... im moment löse ich es so, das ich einfach die TEngine als globale variable deklariere, da sie sowieso nur einmal existieren kann... also ähnlich wie du mit deinen Manangern, nur andersrum

Aya~

Jo an diese Sache mit den Zeigern auf alle anderen Manager dacht ich auch schon, das war mir aber schlicht zuviel arbeit

DIe Engine als globale deklarieren ging bei mir nich, weil TEngine nich direkt benutzt werden kann, sondern vorher eine klasse abgeleitet werden muss, und von der wird dann vom user ein objekt erstellt, und deshalb kann ich das nicht global machen. Aber wie gesagt, so global wollt ichs ja eigentlich eh nicht.

Wenns wirklich nicht anders geht, wird mir nix anderes uebrig bleiben, als die Pointer auf die Engine zu uebergeben und dann Typezucasten, find ich aber nicht schön. Weitere ideen?^^

Als erstes etwas. Klassen bitte nur in wirklichen Notfällen als Pointer benutzen. Alles Klassen sind von TObject abgelitten und somit sollte das der kleinste Typ sein den du für eine Klasse benutzt. Denn mit einem Pointer hebelst du die Klassentechnik aus.

Includedateien benutzt ich bei mir zwar auch aber nur weil da ein paar skriptgenerierte Konstanten enthalten sind. Ansonsten mag ich persönlich includes nicht, da es sich schlecht programmieren lässt, da in einem include keine Klassen bekannt sind, denn das Include wird nur später in anderen Code eingebunden. Und für jemanden wie mich der extrem häufig die Codeverfolständigung benutzt ist echter großer Code in einem Include eine Strafe.

Da ich manchmal auch mehr kann als moppern hier mal ein paar Vorschläge.

1. Wie wäre es das ganze über ein Klassenkonzept zu lösen. Leider weiß ich nicht wie die einzelnen Manager genau aussehen. Aber für mich sind ein Texturmanager und ein Fontmanager nicht so sonderlich verschieden. Nur, dass der eine Fonts und der andere Texturen verwaltet. Wenn die Klassen jetzt so gehalten sind, dass sie nur Textur oder Font Objekte verwalten dann könntest du ja auch eine Basismanagerklasse benutzen von der beide Manager abgelitten sind. Das würde dann aber auch verlangen, dass die Objekte die sie verwalten auch eine eigene Basisklasse benötigen würden. Mit Virtuellen bzw. Abstrakten Methoden kannst du dann dafür sorgen, dass der jeweilige Manager seine eigene Funktionalität hinzufügt. Allerdings vermute ich mal stark, dass dieser Vorschlag für dich eher nicht in Frage kommt. Der setzt eine sehr strikte und verwirende Objektstruktur vorraus.

2. Die andere Möglichkeit wäre so etwas ähnliches mit der Engine zu machen. Also eine abstrakte Basisklasse erstellen die nichts weiter als die Funktionen definiert die in den Managern benutzt werden müssen. Dadurch würdest du dich auch zwingen die Struktur etwas sauberer zu halten und dir genau zu überlegen was du in den Managern wirklich brauchst. Deine eigentliche Engine würdest du dann von dieser Klasse ableiten und die Funktionen implementieren. Diese Basisklasse kannst du in eine Unit packen in der du auch so standardtypen definiert hast (falls). Oder irgendwas anderes was du in jeder Unit einbinden müsstest. Deine Manager würden nur die abstrakte Klasse verlangen und würden nur über die definierten Methoden arbeiten.

3. Lord Horazont hatte das schon gesagt. Wenn diese Klassen nicht zu extrem groß sind, dann tut es nicht weh alles in eine Unit zu packen. Die Hauptklassen bei meinen Fonts sind auch alle in einer Unit. Mir war es da auch recht wichtig nicht alles zu zerhacken. Nur ein bisschen.

PS: Ich hoffe so ganz ohne Code ist es trotzdem halbwegs verständlich gewesen. Ansonst ließe sich das durchaus ändern.

Da lob ich mir Lazarus, das kommt damit klar, da parst die Codecompletion die Includes richtig mit

Sonst würde ich dir bei dem Vorschlag mit einer abstrakten Basisklasse für die Engine zustimmen, aber das mit den abstrakten managern wird so wie ich mir das denken kann nicht klappen. Fonts und Texturen dürften in dem falle zwei unterschiedliche paar schuhe sein. Was man aber überlegen könnte wäre, sowas wie TCollection zu bauen.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Vorschlag 1: Ich denke, es passt wirklich besser die Manager nicht auf Teufel-komm-raus in ein uniformes Gesamtbild pressen zu wollen, deswegen lass ich sie lieber getrennt.
Vorschlag 2: Da ich meine Engine bereits einmal ableite, wollt ich das eigentlich nicht, aber wie ich gleich erklaeren werde, bleibt mir wohl nichts anderes übrig.
Vorschlag 3: In eine Unit? Um gottes Willen nein ^^

Alos ich hatte noch das Folgende Versucht:
Ich habe in meiner Globals.pas, die von jeder Unit eingebunden wird, einfach mal

deklariert.
Soweit so gut, ich kann die Globals im erste Uses einbinden und dann in der Managerdeklaration auch TEngine benutzen. Damit TEngine dann aber alle Klassen und Eigenschaften bekommt, muss ich in der zweiten Uses Engine.pas einbinden, wo die eigentliche TEngine drinliegt. Da die aber nicht voneinander abgeleitet sind, funktioniert das nicht, weil der Compiler es scheinbar als zwei unterschiedliche Klassen darstellt.

Deswegen werd ich mich mal an Vorschlag zwei setzen

Okay also diese Variante hat auch nicht (zumindest so, wie ich es versucht habe) gefruchtet:

Wenn ich eine Basisklasse zb TEngine_Template erstelle und von ihr dann meine TEngine ableite, dann würde das folgendermaßen aussehen.
In der TEngine_Template dürften die Manager noch nicht drin sein, denn die Manager müssen die Datei, in der TEngine_Template (Datei: Tools.pas) deklariert ist, in der Usesklausel mit einbeziehen, sonst funktioniert ja diese Aufwärtsgeschichte nicht.
Also hiesse das, ich konzipiere meine TEngine_Template so weit es geht, und in der abgeleiteten Version TEngine kommen dann die Manager rein. Das Problem, das entsteht, ist das folgende: Wenn alle meine Manager nur die Deklaration aus TEngine_Template kennen, weiss auch kein Manager, dass in meiner abgeleiteten Engine überhaupt Manager drin sind, also kann ich sie trotz aller Bemuehungen nicht nutzen *seufzt*

Muss denn der FontManager überhaupt wissen, dass es einen TexturManager oder andersrum gibt? Also das der Fontmanager einen TexturManager kennt könnte ich gerade so noch verstehen aber sonst? Mich würde da mal interessieren was genau du gemacht hattest?

Eventuell solltest du dir auch mal ein UML Tool schnappen und die Beziehungen zwischen den einzelnen Klassen mal grafisch darstellen. Mir hilft so etwas immer ganz gut, wenn es komplizierte Klassenmodelle werden. Denn du hast das Problem, dass du extrem flache hirarchien hast (fast jede Klasse hat keinen Vorfahren) und es ist extrem weit verzweigt (jede Klasse muss in jeder anderen bekannt sein).

Ich seh das wie Lossy.
Lass mal bissl Faulheitscode (Sachen die nur der bequemlichkeit halber da sind) weg und überleg dir das Design nochmal.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also mal weg von FOnts und Texturen geb ich Euch ein einfaches Beispiel:

Mein Effektmanager möchte einen Effekt darstellen und muss dazu den Texturenmanager kennen, weils sonst nix mit dem huebschen Feuer und Rauch und sonstwas wird. Deshalb muss er da bekannt sein.
Mein Scenenmanager möchte eine Szeneninterne Prozedur an ein OnKeyDownevent koppeln, aber muss dazu den Eventmanager kennen.

Sowas sind eben die Probleme, die auftreten, die mich zu diesen Fragen bringen. Ich wuesste nicht, wie ich meine Klassen gewinnbringend voneinander ableiten sollte, ohne in alle Sachen reinzuschreiben, die sie eigentlich nicht brauchen.

Okay. Das sind ja schon Beispiele die etwas mehr einleuchten. Was ich evtl schon mal angedeutet habe aber das möchte ich noch mal deutlicher sagen. Das Design deiner Klassen richtet sich danach was du haben möchtest und was du damit bezweckst. Wir können dir zwar ein paar vereinzelte Tipps geben aber ob das immer so passt können wir nicht abschätzen. Denn jeder hat seinen eigenen Stil und es gibt kein Patent Design für so etwas. Denn jeder hat andere Vorstellungen von dem Ganzen. Von daher können wir auch nicht so 100%tig genau sagen wie du das machen musst, denn wir wissen nicht wie genau du das machen willst und ob das dann genau deinen Vorstellungen entspricht steht auch noch auf einem anderen Blatt.

Aber nichts desto trotz solltest du dich mal hinsetzen und die Objektstruktur in irgendeiner Form grafisch darstellen um zu sehen welche Klassen was wie wo benötigen. UML ist dafür konzipiert worden. Und am Bildschirm kann man die Klassen einfacher verschieben etc. Was ich dir sogar generell empfehlen würde, denn eine Engine ist schon etwas sehr komplexes. Und da kann man sich generell schon mal ziemlich schnell ins Aus befördern. Für meine "einfachen" Fonts habe ich so etwas auch gemacht. Wobei ich aber auch OOP Fanatiker bin.

Typischerweise ist es bei Objekt Orientung aber so, dass sich die einzelnen Objekte aber eher nur um Ihre eigenen Sachen kümmern. Bzw um die Dinge die Unterhalb der Klasse passieren. Denn sonst kann es schon recht schnell mal passieren, dass die Klasse das braucht und eine andere wiederrum was ganz anderes. Und dann hängen alle Klassen irgendwie miteinander zusammen. Was aber in gewisser Weise dem modalem Gedanken von OOP wiederspricht.

Der SzenenManager sieht für mich so aus als ob dieser sich um einiges in der gesammten Szene kümmert. Was ihm eigentlich fast zum gleichberechtigten Partner der Engine macht. Das er Events irgendwo registriert mag ja okay sein. Da würde ich es aber wohl eher so machen, dass der SzenenManager an der Engine sagen kann gib mir mal ein Event. Die würde das an den Eventmanager weiter leiten und der SzenenManager hätte dann eine EventID oder eine kleine Klasse etc. Die braucht er aber auch nur um sie dann wieder zu löschen. So könnte dann prinzipiell jeder ein Event anfordern aber nur die Engine würde direkt den EventManager kennen.

Ich weiß nicht wie du das derzeit handhabst. Der Effektmanager verwaltet Effekte und genau genommen würden nur die Effekte wirklich Texturen benötigen. Also müssten noch nicht einmal die den TexturManager kennen sondern lediglich einzelne Texturen.

Also mir ist schon klar, dass ich alles etwas reduzieren könnte, und meinen Managern das, was sie wirklich brauchen, über irgendwelche Schnittstellen geben könnte, aber das erscheint mir mehr als umstaendlich, weil ich dann, sobald mir später auffällt, dass ich doch noch was anderes brauch, sofort wieder alles umbauen muss und neue Schnittstellen einfuegen muss. Klar jetz kann man sagen, ich muss mir einfach vorher alles genau überlegen, aber ich hab bisher sowas großes noch nie programmiert und deshalb bin ich nicht so der jenige, der sofort alle Notwenigkeiten auf Anhieb erkennt.

Ich habe jetzt mal in jedem Manager die Engine als TObject speichern lassen. Funktioniert auch alles, nur muss ich vor jedem aufruf der Engine einen typecaste auf TEngine durchführen lassen, was mir auch etwas umstaendlich erscheint. Bisher weiss ich eigentlich immernoch nicht so recht weiter^^

Na ja. Es geht ja auch nicht darum, dass du alles von anfang an komplett durchplannst. So etwas gelingt mir auch nicht und ich mache das schon etwas länger. Bei mir passiert es auch häufiger, dass ich ein bestehendes Design noch mal ändern muss, weil ich etwas nicht berücksichtigt habe.

Ich versuche aber normal in jedem Fall eine gewisse Modularität aufrecht zu erhalten. Also so, dass einzelne Teile nur für ihr eigenes Gebiet zuständig sind und auch nur Code enthalten der für sie wichtig ist.

Wie ich oben aber schon mal gesagt habe. Ich für meinen Teil kann dir nicht weiter helfen, da ich den Gesamtaufbau nicht kenne und nicht weiß was du bezweckst.

okay dann mal schematisch:
Die Engine umfasst alle Manager, hat ein Create und eine Loopprozedur, eine Screenshotprozedur und noch so ein paar Spielereien.

Meine Camera beschäftigt sich mit der Einstellung des Viewports und der Ausrichtung des Blicks
Der Effektmanager beherrbergt alle Partikeleeffekte
Der Eventmanager speichert in Listen Pointer auf alle abzuarbeitenden Prozeduren, die bei verschiedenen Event auslösen
Der Fontmanager beherrbergt alle Fonts und mit der Prozedure Fontmanager.draw kann man dann schreiben
Der GUIManager beherrbergt alle GUI Elemente. Nach seiner Erstellung muessen alle seine Events an den Eventmanager gekoppelt werden. Jedes weitere Element innerhalb der Gui muss nicht neu an den Eventmanager gekoppelt werden, da der GUIManager den Eventaufruf an alle Childelemente weitergibt.
Der Renderer bereitet die Szene vor, stellt Orthoprozduren bereit und hat letztlich auch den Swapbufferbefehl drin. Ausserdem zeichnet er das Koordinatensystem und den FPSGraphen
Der Szenenmanager beinhaltet eine abstrakte Klasse TScene, von der jede neue Szene abgeleitet wird. Ausserdem speichert er jede Szene in einer Liste, kann neue Szenen hinzufügen, bestehende herauslöschen, initalisieren, releasen, aufrufen, Szenen wechseln und die aktuelle Szene rendern und "advancen".
Der Texturenmanager lädt alle Texturen und erlaubt einen Zugriff ueber einen Namen.
In den Tools stehen alle Typen, Constanten und prozeduren, die an vielen Stellen benoetigt werden.
In der Datei Window wird das Fenster per sdl mit icon und caption erzeugt, die groesse kann angepasst werden, die visibility geändert, auf fullscreen gesetzt, das surface abgefragt werden usw.


So das wären jetzt mal meine wichtigsten Bestandteile. Also ich hab wie gesagt keine ahnung, wie ich da etwas zusammen bringen kann, deswegen wuerd ich mich ueber eine art schematischen Aufbau einer neukonzeption ueber vererbung schonmal sehr freuen