Hört sich recht interessant an, und dürfte mit nem ansprechend wirkendem und v.a. leicht zu bedienendem Frontend wirklich ne tolle Sache sein.
Aber ist das nicht irgendwie ein wenig zäh da nur alle paar Tage mal nen Spielzug machen zu können, den man (so wie ich das verstanden habe) dann auch noch vorausplanen muss? Macht das überhaupt Spaß?

Ansonsten bin ich aber mal auf das fertige Frontend gespannt, evtl. kann ich mich dann nämlich auch dafür begeistern.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Es wurde so konzipiert, dass man es nebenbei spielen kann. Da tun 15 Minuten ein oder zwei mal in der Woche nicht weh. Aber da hast du auch nicht so unrecht. Es ist nicht jedem sein Ding. Meines eigentlich auch nicht. Und eigentlich bin ich auch kein Strategiefan und schon gar nicht Rundenbasiert. Es macht dafür aber irgendwie doch erstaunlich viel Spaß.

Aber normal musst du das gar nicht so großartig weit voraus planen. Du solltest dir nur überlegen welches Ziel du verfolgst. Also Galaxieherschafft, Handel, etc.

Vielleicht ließe sich der Spielemeister auch dazu überreden eine spezielle Schnellrunde zu starten. Aber eine rege Nachfrage dafür sollte da als Vorraussetzung schon gelten. Aber in dem aktuellen Spiel wurde von den meisten Spielern eine Zugabgabeintervall von einer Woche gewünscht. Na ja. Ich kann ihn ja mal morgen drauf ansprechen.

So ich habe meinen Kollegen mal darauf angesprochen und er ist bei solchen Wünschen recht flexibel. Ihm würden dann auch ca. 5 Leute genügen um ein neues Spiel aufzumachen. Der Rest würde dann mit Computer aufgefüllt.

Also der Menügenerator schaut ja extrem vielversprechend aus. Insbesondere ist das etwas, was jede etwas ausgefeiltere Applikation brauchen kann, anstatt immer wieder das Rad neu erfinden zu müssen - insbesondere wenn du den Source veröffentlichst, sollte es kein allzu großes Problem sein, die Quellen an den eigenen BaseCode anzupassen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ach so hast du das tolle Menu hinbekommen...
...mit einen eigenen Editor.
Nicht schlecht vorallem weils es wie schon Mars sagte sehr gut wieder verwendbar ist.
Wie wäre es noch mit einer Check-Liste?
MfG
IFlo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Also es freut mich, dass es gefällt.

Das blaue Menü was ich auf den Bildern (die mit den Feldern im Hintergrund) immer mal hatte habe ich nicht mit dem WindowMaker erstellt. Das geht ja auch nicht. Diese Sachen habe ich alle per Hand gemacht und festgestellt, dass es per Hand doch ein wenig zu umständlich und langwierig ist. Deswegen habe ich hauptsächlich den Maker gemacht.

Eine CheckListe. Hmm. Also ich habe vor die StringListe sowieso noch mit auszubauen. Muss ich dann mal sehen was das für ein aufwand ist und wenn der nicht groß ist kann ich den noch machen. Aber aufgrund, dass die Stringlist später auch ein Benutzermalen dabei hat könnte man sich so etwas dann recht einfach ohne große Probs selber machen.

Das klingt ja fast so als wolltest du uns deine Tools zur verfügung stellen .

Wäre glaube ich generell keine schlechte Idee für die DGL-Community ein Menu-Tool zusammenzustellen, da doch fast jder für sein Programm ein Menu brauchen kann.
So ein Projekt "OpenGL-Komponenten für Delphi" würde bestimmt recht schnell Anhänger finden die mithelfen.
Vielleicht sollten wir mal eine Umfrage starten.
MfG
IFlo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Lossey X hat sich in diesem Thread recht ausführlich über seine Menükomponente geäußert.
Ich geb ja zu, ich hab bissl gedrängelt... 8) [/url]

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

Das schaut ja schon sehr vielversprechend aus.

Ich nehme an, uPS verwendest du, um den erstellten Source auch sofort testen zu können.
Warum musst du dazu denn sämtliche OpenGL Daten freigeben - es ist an sich (relativ) leicht möglich, auf Scriptvariablen von außen zuzugreifen, bzw. existierende Delphivariablen (Klasseninstanzen) ins Skript hineinzubringen - oder hat dies einen ganz anderen Grund?

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Das Problem sind unter anderem die Texturen. Wenn ich zwischen Quelle und OpenGL hin und her schalte müsste ich meine bereits geladenen Texturen (befindlich in einer TList) mit den zu erstellenden abgleichen. Das würde ja auch gehen. Allerdings wenn eine Eigenschaft einer Textur geändert wurde, dann müsste ich die Textur auch wieder neu generieren und da einen Algorythmus einzubauen der die Einstellungen miteinder abgleicht und ggf. neu generiert ist mir einfach zu viel Aufwand. Wenn die Texturen mehr oder weniger statisch wären wäre das ziemlich einfach möglich nur das kann man Garantieren oder festlegen.

Ein anderes Beispiel sind Veränderungen an der Objectstruktur. Wenn ich die nicht vollständig zerstöre und wieder neu aufbaue würde ich wahrscheinlich echt lustige Dinge erleben. Z.b. Bei geänderten Parents. etc.

Und langsam wird es auch erst nur dann wenn mal reichlich Texturen eingebunden hat. Wenn man 3 Fonts und 2 "normale" Texturen verwendet dann liegt die Wartezeit bei 1-2 Sekunden. Das ist eine Zeit die ich durchaus verschmerzen kann.

Finde auch das deine 2D-GUI da inklusive dem an Delphi angelehntem Editor und sogar Skriptsupport sehr lecker aussieht.

Wenn du das konsequent durchziehst, dann könntest du damit quasi (zumindest für uns Delpher) ne 2D-Standard-GUI-Library auf die Beine stellen, die man dann ruhigen Gewissens auch in DGL-SDK unters Volk bringen könnte.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Freut mich, dass es gefällt. Ich werde alles daran setzen, dass es funktional und von der Bedienung her kompfortabel wird und bleibt. Zu mal wahrscheinlich ich derjenige sein werde der es am meisten benutzen wird.

Zum Thema Verbreitung. Das größte Problem sehe ich darin, dass diese Komponenten und auch die IDE vollständig auf meinen eigenen Quellen basierten. Nicht jeder wird da freiwillig umsteigen wollen. Aber sonst bin ich da für alles offen.

Ich hatte eigentlich vor als nächstes Projekt eine eigene glVCL zu schreiben die grundlegende Elemente beherrbergt und komplett anpassbar ist.

Anscheinend wächst dein Projekt in die selbe richtung. Mein Ziehl war es ein KomponentenSystem zu erstellen, welches mindestens in der Lage ist ein Managementspiel (Sportmanager) zu visualisieren (mit auswertung von Programmstatus und daran abhängigen Zeichenaufrufen etc.).

Kann das deine Unit? Wird sie das Können? Wie einfach ist es für fremde deinen Code in ein Projekt einzubinden?

Ich frage, weil das direkten Einfluss auf meine Zeitplanung nach dem Vordiplom haben wird.

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

Eine weitere Idee wäre die Klassen kompatibel zu den VCL Klassen zu machen um die Verwendung zu erleichtern. Also das ganze auf TComponent aufsetzen, in dfm Dateien zu speichern und möglichst alle Eigenschaften der Komponenten auch implementieren.

@Flash
Grundlegende Elemente: Button, Panel, Label, Image, CheckBox, RadioBox, Scrollbar, Listbox (noch in arbeit). Edit und Combobox kommen irgendwann noch. Reicht das?

Komplett anpassbar: Du könntest für jedes Element eine eigene Textur und eigene Texturkoordinaten verwendet. Wie die aussehen ist vollkommen dir überlassen. Der Button zum Beispiel besitzt Texturkoordinaten, Koordinaten für den gedrückten Zustand, einen Rand (Rect) den manc auch weglassen kann. Du kannst in Abhängigkeit des Zustandes die Caption positionieren. Und für wen das immer noch nicht reicht, der kann in den Events OnDraw, OnBeforeDraw und OnAfterDraw die komponente so ummalen wie er es gerne hätte.

Zeitplan: Derzeit bin ich noch am Basteln des Editors. Werde aber in der nächsten Zeit die Mausunterstützung wiederherstellen. Diese ist Umbauarbeiten zum Opfer gefallen. Aber das sollte an und für sich kein großes Thema sein.

Einzubinden: Ich habe am Dienstag das mal spaßeshalber ausprobiert. Ich benutze in meinen Programmen ja bereits meine Units (Loader). Und an der Stelle sah die Einbindung so aus, dass ich eine neue Unit in die Liste aufnehmen musste. Also die Erstellte. Und ich musste 3 Methoden aufrufen. Schon waren die Elemete zu sehen. Die Interaktion mit deiner Hauptanwendung musst du dann zwar noch selber machen. Aber das sollte nicht das Problem sein.