Archiv verlassen und diese Seite im Standarddesign anzeigen : Grafische Benutzerschnittstelle
Hi,
Zwei Dinge vorweg:
Ersten: Ich weiß, wir wollten dieses Thema erst relativ spät angehen, aber irgendwie ist die Motivation, die INTs zu implementieren doch viel größer, wenn man dann gleich sieht ob sich die LFen auch wirklich bewegen etc.
Zweitens: Die Themenüberschrift ist vielleicht ein bisschen irreführend, denn eigentlich wird das hier wohl viel eher eine Schnittstelle von der Maschine zum Menschen werden als umgekehrt.
Also wie gesagt, meine Motivation das Thema jetzt und hier zu starten, ist die, dass ich gerne schon während der Implementierung des Bewegungs INTs schon sehen würde, wo jetzt die LFen sind und ob sie sich dann bewegen.
Dazu hab ich mir gedacht, um das ganze hier möglichst Plattformunabhängig zu gestalten, dass wir diese Visualisierung vielleicht in OpenGL machen könnten. Dabei würden wir mal nur die 2D Fähigkeiten dieses Grafik Layers verwenden, aber wir hätten dann eine ausbaufähige Schnittstelle und auch eine die auf den wichtigsten Systemen läuft. Dh wir kommen realtiv gut ohne Betriebssystemroutinen durch.
Das wäre dann auch wesentlich eleganter als irgendwelche Konsolenplots..
mfg spirit
hi,
Habe mal eine erste Implementation mit OpenGL gemacht. Allerdings weiß ich nicht ob es gut wäre das in den CVS Zweig einzufügen. vielleicht schreibt ihr mal eure Meinung dazu?!
Um euch eine entscheidung zu ermöglichen hab ich die Sources mit OpenGL hier angehängt. Der EVO Kern ist der von 14.05.03 um 01:00 Uhr wie er am CVS war.
mfg spirit
PS: Ist mit Dev C++ 4.9.8 kompiliert. Wenn ihr auch diese IDE verwendet sollte sofort alles laufen nach dem Öffnen der Projekt datei.
Ihr solltet beim kompilieren die Linkereinstellungen übernehmen, wenn ihr nicht die mitgelieferte Projektdatei ladet. Ich glaub die richtige Linker einstellung ist
-lopengl32 -lglu32 -lglaux -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32
Hier die aktuelle Version. Jetzt werden die LFen mitgerendert. Bei der beiliegenden start.life existiert aber immer nur eine LF. Das Herumspringen erklärt sich durch die zufällige Positionierung bei INT4 (Vermehrung)
have lots of fun..
mfg
Assimilator
17.05.2003, 14:29
OpenGL ist wohl keine schlechte Lösung...
aber ich denke es wäre besser, die Visualisierung klar vom Rest zu trennen. Ich stelle mir den optimalen Aufbau der Engine eigentlich folgendermassen vor:
Es gibt 2 Basisklassen: Life und Population.
Diese Basisklassen bieten nur die grundlegende Funktionalität, die für jedes Lebewesen, bzw. jede Population erforlderlich sind. Das ist im wesentlichen die Ausführung der Grundbefehle (keine Interrupts, ausser evtl. einer vereinfachten Fortpflanzung).
Von diesen 2 Klassen wird dann je eine weitere Klasse abgeleitet, die die für das aktuelle experiment erforderlichen erweiterungen mit sich bringt. Für unser Beispiel wäre das die Implementierung des Lifespace (eine Ableitung von Population), der zusatzfunktionen zur Koordinatenverwaltung und -überprüfung bietet und eine Klasse LF (abgeleitet von Life), welche z.B. zusätzlich die Interrupts implementiert und Koordinaten für die LFen zur verfügung stellt.
Von diesen Beiden Klassen könnte dann auf einer dritten Abstraktionsebene ein GUI abgeleitet werden. Dazu könnten einfach die jenigen Funktionen, die zur Darstellung benötigt werden abgeleitet werden (aber ansonsten die gleiche Funktionalität beibehalten). Diese Klassen könnte man dann optional machen.
Durch diese Aufteilung bleibt das ganze Projekt sehr übersichtlich und einfach zu handhaben.
mfG Assimil8or
Ja, ich muss sagen dieses Modell gefällt mir.
Dann werde ich mein visuals Objekt in das CVS aufnehmen. Dieses Objekt wird dann optional (Kommandozeilenparameter) geladen und stellt eine fertig initialisierte OpenGL Umgebung für diese dritte Abstraktionsebene bereit.
Denn wie die Visualisierung dann tatsächlich aussieht ist ja sehr stark problemabhängig :)
mfg spirit
Aloa
Wenn es geht, wäre es wohl besser, die GUI derzeit nur per bedingter Kompilierung einzubauen, da ich z.b. unter Linux entwickle und die Windowsroutinen in main.cpp da eher sehr hinderlich sind..
Ausserdem fände ich es SEHR sinnvoll, keine GUI Methoden / Variablen in die allgemeinen Klassen (wie Population) aufzunehmen, da dann eine Portierung ziemlich aufwendig und bug-anfällig wird.
Also besser eine reine Klasse/Klassenstruktur für die Visualisierung, aber diese bitte nicht in die vorhandene einbauen, da sie dort rein von der Konzeption her auch - IMHO - nichts verloren hat.
balk0th
Hi,
Also für die GUI habe ich in der Klasse Population insgesamt 5 neue Zeilen Code eingefügt. Mit viel weniger werden wir nicht durchkommen, da der Hauptprozess nunmal in pop.life passiert und wir irgendwie der Grafik eine chance auf Prozessorzeit geben müssen.
Aber ich habe jetzt das komplette Grafikpaket als optionale Kompilierung geklammert. Wenn du in globals.h das define compile_opengl_win löschst, kannst du wahrscheinlich alles auch auf Linux kompilieren. Bitte schreib wieder wenn dem nicht so ist.
Die Klassenstruktur streng nach dem obigen Vorschlag zu korrigieren habe ich in der kurzen Zeit nicht geschafft, kommt aber noch die Woche.
mfg
delphi_progger
19.05.2003, 12:39
Wenn es geht, wäre es wohl besser, die GUI derzeit nur per
bedingter Kompilierung einzubauen, da ich z.b. unter Linux entwickle
und die Windowsroutinen in main.cpp da eher sehr hinderlich
sind.
Stimmt. Ich entwickle mit MSVC++, daher ist das auch ein Problem, da
dort die Include Dateien anders sind.
Aber ich habe jetzt das komplette Grafikpaket als optionale
Kompilierung geklammert. Wenn du in globals.h das define
compile_opengl_win löschst, kannst du wahrscheinlich alles auch auf
Linux kompilieren.
Das ist die beste Lösung, denke ich. Wenn ich dazu komme, dann mache
ich noch eine bedingte Kompilierung für MSVC++, damit das auch mit
diesem Compiler problemlos funktioniert.
Ansonsten ist die Visualisierung mit OpenGL eine gute Idee.
Ich hätte da mal eine Idee, wie man das ganze etwas modularer bauen könnte. Es ist schon klar, dass die Aktualisierung des Displays jeden Tick von Population::live ausgehen müssen.
Hier der Vorschlag:
Wir bauen in Population einen Funktionszeiger ein, der auf die aktuelle Display-Aktualisierungsfunktion zeigt (und ev. noch einen für die Initialisierung), dem wir eine noch zu konstruierende Klasseninstanz mit Status-Daten (wo sind z.b. die Lifeforms zur Zeit usw.) übergeben. Dieser Funktionszeiger ist dann halt in main entsprechend zu setzen, je nachdem, was man für eine Ausgabe will.
Der Vorteil wäre daran halt, dass man so die GUI - Implementierung praktisch vollkommen von Population löst....
balk0th
Assimilator
24.05.2003, 19:37
balk0th: Also mit der Hirarchie der Klassen, so wie ich das vorgschlagen habe braucht es weder GUI-Code in der Population- oder Life-Klasse, noch einen Pointer o.ä. =)
mfG Assimil8or
rebugger
25.05.2003, 07:06
Wie sieht das ganze denn dann aus ?
Also den Anfang hab ich ja schon gemacht.
Es gibt drei grundlegende Klassen: Eine für die einzelne Lebensform "basic_life", einen Container für alle LFen "basic_world" und eine Grundklasse für eine Benutzerschnittstelle "basic_visuals" die in der Grundform nur Konsolenausgabe macht.
Davon abgeleitet werden Klassen die an die jeweilige Problemstellung angepasst sind.
Davon wiederum kann man noch spezialisierte Klassen für eine optimale Visualisierung ableiten.
Damit das Kind einen Namen hat würde ich vorschlagen die drei Ebenen als "Abstraction Layers" kurz AL 1 bis AL 3 zu bezeichnen.