Archiv verlassen und diese Seite im Standarddesign anzeigen : Entwicklung (AL 2)
So Leute,
Wie wärs wenn wir nach unserer Schaffenspause wieder mal zu den Keyboards greifen ? hm? ;)
Hab mal damit angefangen und wild drauf los mit der zweiten Abstraktionsschicht begonnen. Leider kompiliert der Source (ich habs auf CVS geladen) in der jetzigen Fassung nicht aufgrund irgendwelcher include Fehler. Ich schätze mal irgendwo in dem Schichtenkonzept ist ein Zirkelschluss. Wäre sehr nett wenn ihr euch das ansehen würdet, ich find das echt nicht und die Compilerhilfe ist echt spartanisch..
mfg
Habe nachdem ich mich heute Nachmittag auf dieses unser schönes Projekt besonnen habe den AL 2 mal zumindest bis zur Kompilierbarkeit gebracht.
Das heißt die Objektstruktur ist jetzt wie geplant implementiert. Da waren teilweise extrem eigenartige und deshalb schwer auffindbare Fehler drinnen (zumindesten mit Dev-C++ schwer auffindbar ;) ) Deshalb gibts jetzt in der Befehlszeile die neue Option -s die nur jede Sekunde einen Schritt durchführt und jedes Mal den Weltstatus ausgibt.
Von den Interrupts stehen einstweilen die Dummies.
ToDo:
Umwelt von Datei laden
Interrupts implementieren
Mutationsschema entwickeln
(später) Erweiterte Visualisierung der Population
Also ich finde das ganze geht zwar lähmend voran, aber das Konzept selbst ist durchaus gut und mit dieser OOP Struktur kann man dieen Evolutionsframe auch auf andere Probleme anwenden,
Für Interessenten und zur Erinnerung: Dieses Projekt wird von SourceForge gehostet.
http://sourceforge.net/projects/ev0lution/
Dort findet ihr auch die aktuellen Sources im CVS Tree unter openevo.
mfg
Zum aktuellen CVS commit:
Die Laderoutinen für Konfigurationsdateien, sowohl für einzelne Lebensformen als auch für die Welt sind auf binary Streams umgestellt um der sauberen Objektorientierung zu entsprechen.
Es werden die Umwelteckdaten aus der start.world geladen und eine entsprechendes Feld and Weltpositionen initialisiert. Neue Lebensformen werden im Moment noch einfach auf die erste freie Position gesetzt.
Nächster Schritt wird sein, die Interrupts der Reihe nach zu implementieren wie sie in der Konzept Datei dokumentiert sind.
Da ich nicht Admin des Projekts auf Sourceforge bin, kann ich leider im Moment keine neuen Entwickler aufnehmen. Aber es wäre mir schon geholfen, wenn ihr euch bei Interesse Teile oder die kompletten Sources runterladen und auf Fehler durchsehen könntet.
Bin gerne bereit auf alle Fragen ausführlich einzugehen, bin aber ab Mittwoch Abend (13. August) bis Sonntag Abend (24. August) nicht online.
mfg
Zum aktuellen CVS commit:
Interrupt 2 (get food) und Interrupt 3 (Move) sind implementiert. Für die Ermöglichung der Überkreuzten Zugriffe zwischen specific_world und specific_life wurden einige abstrakte "Zwischenklassen" für world eingefügt. (siehe life_specific.h)
Außerdem gibt es ein neues Report System um die einzelnen ASM Schritte zu protokollieren. Dieses System wird durch den Kommandzeilenschalter -d aktiviert.
ToDo:
Interrupt 1: Nahrungsverteilung in der Umgebung der LF ermitteln
Interrupt 4: LF duplizieren
Mutationsroutine
mfg
Zum aktuellen CVS commit:
Na schön liebe Leute. Ich habe mal alles andere, was eigentlich wichtiger wäre als an diesem Projekt zu arbeiten vernachlässigt und wieder einen ganzen Tag hier hereingesteckt.
Ergebnis: Der Abstraction Layer 2 ist im Pre Release Stadium. Alle für diesen Layer vorgesehenen Funktionen sind zumindest rudimentär implementiert. Genauer gesagt ist speziell die Mutationroutine mehr so ein ho-ruck Ergebnis. Man gibt in der world Datei den Kehrwert des Mutationsgrades an, und dann werden die Signaturen von neuen LFen einfach per Zufallsgenerator mutiert.
Die Interrupts sind alle vollständig implementiert und bis auf INT1 auch angetestet.
Ich habe mir schon mal erlaubt ein Binary Release auf Sourceforge zu machen. Damit fangt ihr aber erst wirklich was an, wenn ihr die Sources kennt und die Konfigurationsdateien mittels Hex Editor bearbeiten könnt. Trotzdem, es funktioniert.
Ich bin jetzt wie schon erwähnt mal 11 Tage in alpiner "offline-Umgebung". Danach werde ich mich an den letzten und dritten Abstraction Layer machen, damit die Nicht-Programmierer unter euch zumindest den Lebensformen bei Herumlaufen zusehen können.
ToDo: Testen und debuggen von AL 2
Entwicklung von AL 3 (Grafisches Interface)
Assimilator war so nett mich auf Sourceforge auch zum Admin für dieses Projekt zu machen. Das heißt wenn ich zurückkomme kann ich auf Wunsch neue Entwickler aufnehmen, die dann auch Schreibrecht auf unseren CVS Tree haben. Meldet euch bei Interesse per Mail oder PN bei mir.
mfg
Also es klingt wie ein Anfängerfehler, aber seit ich vom Urlaub zurück bin geht nur mehr mein Laptop. Die Entwicklung von openevo ist aber auf der HD meines Desktops. Ich nehme jetzt die Gelegenheit wahr, das drei Jahre alte Gerät zu erneuern. :) Die HD ist das einzige neue Teil und deshalb mit Sicherheit intakt. Also in ein zwei Tagen gehts hier wieder weiter.. so long
Also...
...ich muss mich korrigieren. Die grafische Darstellung gehört in einer ersten Stufe ja noch zum Abstraction Layer 2 wie man aus dem (gebumpten) Thread http://buhaboard.de/showthread.php?s=&threadid=38155 entnehmen kann.
Ich bin mir nur nicht sicher was der beste Weg ist, den Entwurfsvorgaben gerecht zu werden. Immerhin verlangt der Entwurf bereits "grafische Funktionen".
Sollte man in visual_graph bereits ein vollwertiges OpenGL Interface aufnehmen, oder nur eine Skelett eines solchen, also nur Routinen um die für die Grafik notwendigen Daten in das visual_graph Objekt "einzusammeln" um sie dann im nächsten (einfacheren) Schritt im AL 3 auch wirklich darzustellen.
Ist hier jemand der eine Meinung dazu hat? Ich tendiere zu einem "Mittelweg", nämlich erst mal die "Sammelroutinen" zu implementieren (also mal die Zugriffsarten zu überlegen: Wie komm ich an die Positionsinformationen ohne Zirkulärreferenzen oä.) und dann aber trotzdem OpenGL gleich in AL 2 einzubauen.
mfg
delphi_progger
08.09.2003, 18:37
Hallo,
sorry dass ich mich erst jetzt wieder melde. Ich werde mir mal den neuesten Source vom CVS ziehen und mir anschauen, was du implementiert
hast.
MfG
delphi_progger
sehr schön, mach das.. ich muss mich im Moment auf eine entscheidende Prüfung vorbereiten und kann deshalb grad keine Zeit hier investieren. Wird sich aber Ende September wieder ändern.
mfg
Hallo, nach einer vorhersehbar langen Pause setzte ich meinen Monolog hier wieder fort.
Also ich nehms jetzt mal als beschlossen, dass die graphische Darstellung in den AL 2 gehört. Eigentlich ist das Layer Prinzip für die Benutzerschnittstelle ja eh nicht gültig.
Um ein Kompilieren auf Windows und Linux gleichermaßen leicht zu machen werde ich wahrscheinlich GLUT einsetzen. Das erspart viele Zeilen betriebssystemspezifischer Quelltexte.
Was man dann in der in visual_graph implementierten OpenGL Umgebung tatsächlich darstellt wird aber erst in visual_ready festgelegt. visual_graph sollte noch so weit wie möglich Problemunabhängig bleiben. Und OpenGL wird ja hoffentlich den Ansprüchen der meisten Probleme als grafisches Interface genügen.
mfg
Guten Tag, alle miteinander!
Sorry dass ich mich erst jetzt wieder melde, aber ich hatte Ewigkeiten keinen Net-Anschluss mehr. Ich hab mir gleich mal den Source gesaugt und schau ihn mir mal an, um wie wieder mit einsteigen zu können.
Hat eigentlich mein "Compiler", den ich damals geschrieben hab, irgendeine Verwendung gefunden?
Lizer.