Hi~,

das freut mich das meine idee euch gefällt

Also, den Raum würde ich an und für sich schon begrenzen, so das jeder die gleiche ausgangssituation hat.. sonst läuft es aufeinmal so das die räume garnichtsmehr miteinander zu tun haben etc, also so als wären es grund verschiedene programme etc ^^

Als DLL würde ich es machen, einfach weil es so perfekt modular ist.. die DLL hat halt eine funktion die sie exportiert (Draw (+ Init/Deinit, KeyEvents etc halt)) und von der aus kann man ja dann seine eigene OOP sachen aufrufen, hindert einen ja niemand dran..

Das Framework wäre durchaus ein wenig aufwand, aber da meinte ich ja, das mach ich gern :p
Also ich würde es erstmal so machen das es funktioniert und die leute gestalten können, das wäre auch schnell gemacht dann... das ganze dann richtig hübsch machen im flur etc kann ja später nochmal richtig nachgeholt werden (wobei ich es natürlich auch nicht hässlich machen würde )

Von dem was das Programm dem Raum gibt würde ich das vorschlagen:

- Draw (inkl. Callbacks für DrawWindow, DrawWall etc)
- InitRaum (zum laden von texturen, objekten etc, dann auch mit nem Callback für den ladevorgang/balken)
- DeinitRaum
- KeyDown/Up zum Tasten verwalten (abgesehen der standart steuerung zum navigieren)
- MouseClicks
- GetInfo-Funktion, wo die DLL dem Programm mitteilt wessen raum das ist, inkl. textur für türschild etc.. (Bzw, dsa Türschild müßte halt als BMP Resource in der DLL sein mit festem namen)

Hab ich da was wichtiges vergessen? Evtl noch dem nen FensterResize, wobei ich mir unsiciher bin wofür die DLL das wissen müßte.. da sollte es reichen, wenn man der Draw-Proc als Parameter nen Width/Height des Fensters mitgibt.

Aya

EDIT: Den großen vorteil von DLLs sehe ich auch darin, das es dann auch mit C und anderen sprachen möglich wäre einen Raum zu schreiben

Bei den Ressourcen für einen Raum müsste man sich noch überlegen, wie man das macht.
Ich denke jeder Raum darf im Hauptverzeichnis des Frameworks oder in einem Data-Unterverzeichnis einen Ordner mit dem entsprechenden Namen benutzen, der dann die benötigten Ressourcen (Texturen, Objekte, Sound, etc) für den Raum bereitstellt.
Um das ganze noch etwas witziger zu machen, und außerdem platz zu sparen (!), könnte man die Größe für den Ordner festlegen. z.B. max 4MB pro Raum.
Desweiteren kann das Framework ja auch noch ne Methode DrawTuerschild() aufrufen. Dan kann man sich die Arbeit sparen,
die Türschild-Textur mit in die dll zu packen. Außerdem müsste es dann nicht einmal eine Textur sein, sondern auch was anderes (dynamisches...).

Was mir noch einfällt: In jedem Ordner eines Raumes gibt es eine Textdatei, die erklärt, was in diesem Raum zu sehen ist, welche Techniken benutzt wurden, und und und... etwas für den Interessierten Anwender (Lern-Aspekt).
Diese Datei kann von dem Framework zu jedem Raum angezeigt werden.

Weitere Ideen?

_________________
http://texelviews.delphigl.com

Einen Data-Ordner kann man eigentlich weglassen, dafür kann man Ressourcen verwenden (.res), die man direkt in die DLL einkompiliert. Mit TRessourceStream kommt man da dann ohne weiteres dran.

Mit dem Gang... Muss man halt überlegen, wie man die Übergänge schafft und vorallem zu welchem Zeitpunkt die Daten für den Raum geladen werden. Gethreaded, wenn man sich in die nähe der Tür begibt oder erst, wenn man die Tür öffnet.

Die Größe des Ordners würde ich eher nicht beschränken. Letzendlich wirds dann wohl dazu führen, dass leute, die mehr platz brauchen die Texturen als JPEG speichern und dann siehts einfach nicht mehr so gut aus. Was man aber beschränken könnte und was viel interessanter ist, die menge des verbrauchten Graka-RAMs. Das ist doch der letzendliche effekt, was gebraucht wird.

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

Bei DLL muss man noch beachten dass Linux DLLs nicht sonderlich gut leiden kann. Da müsste man eben die Bibliothek noch für Linux kompilieren.

Ich arbeite eh fast nur unter Windows mit OpenGL, wenn das hier jedem so geht können wir das erstmal vernachlässigen und erst später doppelt kompilieren.

Ansonsten gefällt mir das alles gut

_________________
Meine Musik: spiker-music.net

Ich weiß zu meiner schande grad gar nicht, wie man mit Java dlls baut. Geht das überhaupt? Es sind ja nicht nur Delphie Programmierer hier. Gut...die C++er haben bei DLLs quasi Heimspiel.

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

Ok, wenn man Ressourcen in die dll mit reinpackt...
Jedoch weiß ich nicht wie man das anstellt
Dlls sind nicht grad mein täglich Brot
Also wenn mir vorher noch einer erklärt, wie das geht...

Aber Ordner wären auch schön. Dann könnte der Interessierte da mal reinschauen und gucken, welche Grafiken verwendet wurden etc.


Wie findet ihr das?
Gut, wenn das mit den Ordnern nix wird, kann man einfach eine Routine für schreiben, die einen String oder eher PChar zurückgibt. Diese Routine wird dann vom Framework aufgerufen.

_________________
http://texelviews.delphigl.com

Also die generelle Idee finde ich auch besser. Auch wenn ich daran nicht mitmachen werde, da ich überwiegend 2D mache und mich meine eigenen Projekte noch sehr sehr lange beschäftigen werden.

Resourcen: Resourcen sind zwar ganz schön und gut. Und es ist sicher auch nicht von der Hand zu weisen, dass es praktisch ist, wenn man nur eine einzige Datei hat. Allerdings haben Resource nicht nur Vorteile! Der Ein oder Andere erwähnte Linux. Ich meine Resourcen sind etwas Windowsspezifisches. Die gibt es also unter Linux nicht. Nicht jeder benutzt Code der zu Resourcen oder TStream kompatibel ist. Es lässt sich nicht alles in Resourcen packen. Was ist mit externen DLLs oder TTFs? Die müssten dann temporär auf die Platte geschrieben werden. Außerdem müsste man seinen Raum jedes mal neu kompilieren, wenn man in einer Textur auch nur ein einziges Pixel verändert hat. Bzw müsste außerdem die Resource ständig neu erstellt werden. Das verkompliziert die Sache nur unnötig.

Ich würde eher auch so was vorschlagen wie MatReno. Neben dem Framework gibt es ein Verzeichnis Rooms und in diesem bekommt jeder User sein Verzeichniss. Die DLL sowie alle benötigten Dateien befindet sich innerhalb diese Verzeichnisses. Um die DLLs nicht sofort laden zu müssen würde ich auch eher eine Beschreibungsdatei sehen.


Shared Librarys/Files sind auch noch so eine Sache. Also so etwas wie SDL_image. Diese sollten sich nicht in jedem Raum befinden sondern in einem Verzeichniss auf der Unterebene des Frameworks. Unter Windows müsste dort ein Path drauf gesetzt werden, damit sowohl statische als auch dynamische Linkungen funktionieren.

Wie soll das eigentlich dann ablaufen. Sollen immer alle Räume mit runtergeladen werden oder sollte man das auswählen können. Wenn ich mir eben nur mal schnell einen Raum anschauen will, dann habe ich keine Lust mir ein 100-300 MB Packet runter zu laden. Dann spielt der Traffic auch durchaus eine Rolle. Für den Anfang sicher noch nicht ausschlaggebend aber lass das Projekt mal größer werden. Zusätzlich sollte irgendwo eine Versionnummer enthalten sein. Man soll ja sehen können ob sich was verändert hat. Das wird nämlich nicht ausbleiben. Bzw falls man später Pakete per Software aktualisieren lassen wollte ist so etwas unerlässlich.

PS: Und bitte bitte benutzt englische Bezeichner. Bei solchen Bezeichnern wie DrawTuerschild sorgt ihr höchstens dafür, dass mein Optiker nicht Arbeitslos wird.

:mrgreen:

Ich benutze selber nur englische Begriffe. Das hab ich nur so geschrieben, weil es in den Kontext passte und mir der korrekte englische Begriff auf die schnelle nicht einfallen wollte. Außerdem ist ja ein Teil davon englisch (Draw)

_________________
http://texelviews.delphigl.com

Ich muss ganz ehrlich sagen dass ich von englischen Bezeichnern überhaupt nichts halte. Wir sprechen jeden Tag Deutsch und wir benutzen ständig so schwammige und häufig auch hässliche englische Bezeichner. Habe mir das abgewöhnt, arbeite sozusagen nur noch mit deutschen Begriffen (muss man auch nicht nachdenken wie etwas heißt).
Aber das ist das wohl mit Abstand Unwichtigste was es gibt. Das Framework sollte eine vorgeschriebene Codeausrichtung haben, die Räume sind dem Benutzer überlassen. Dann können einem solche Kleinigkeiten auch egal sein, an so etwas sollen schon Projekte gescheitert sein....

Zu den Räumen:
Das mit Abstand beste Updatesystem das ich kenne ist der Updater welcher afaik fast nur bei Debian standardmäßig installiert ist. Im Klartext: Wir brauchen einen kleinen Updater der anzeigt was neu ist. Bei den neuen Dingen steht Programmierer, Name, Inhalt des Raumes und selbstverständlich die Versionsnummer des Raumes. Dann kann der Benutzer wählen was er haben will. Ich könnte gerade den Linux-Kernel updaten, da das aber zu lange dauert mach ich das wannanders, wenn ich einen riesiegen Raum habe, ist das wie mit dem Kernelupdate. Zusammengefasst: Man lädt was man laden will zum gewünschten Zeitpunkt.

_________________
Meine Musik: spiker-music.net

Die Idee gefällt mir, wenn ihr Hilfe mit Linux, Cross, FPC, GCC(c/c++), SceneGraph, Datenunabhängige Streams, exporter für Blender oder ähnliches braucht, kann ich mit Rat zuseite stehen. Einfach PM schreiben.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich finde deutsche Bezeichner sehen schrecklich aus. Es heißt ja auch "if then" und nicht "wenn dann". Und schließlich sollte jeder den Code verstehen können nicht nur Deutsche. Aber ich werde eh höchstens mit Rat und sinnlosen Kommentaren zur Verfügung stehen von daher ist das auch nicht meine Entscheidung.

Zum Updater: Das klingt schon ziemlich genau so wie man das gebrauchen kann. Wobei da evtl. auch eine Möglichkeit nicht schlecht wäre mit der man einzelne Räume auch wieder löschen kann. Das aber nur so als Gedanke. Das sind meistens die liebsten Details und es ist mir nicht nur ein Mal passiert, dass man sich in solche Details verrennt und dann irgendwie wichtigere aber uninteressantere Dinge auf der Stecke bleiben. Denn der Updater ist für den Anfang nicht zwingend erforderlich. Dafür ist es wichtig, dass das Framework steht. Damit meine ich aber noch nicht mal die Auswahl der Räume sondern nur die Verwaltung davon. Denn um so früher können Räume entstehen.

PS: Evtl. lohnt es sich auch die Ideen dazu in FreeMind zu sammeln und dann nach Wichtigkeit zu sortieren. Einfach auch schon deswegen damit nichts an Ideen verlohren geht.

Ich bin auch für englische Bezeichner. Deutsche Bezeichner + (Anständiger) Code = EIncompatibleTypes

Gut, an Linux habe ich in dem Moment nicht gedacht. Interessant für den späteren Verlauf wäre dann ein VFS mit (verlustfreier zlib oder so) Kompressionsfunktion, sodass man seine Daten schön in einem Archiv halten kann, ohne selber eine Schnittstelle zu irgendeiner Kompressionsbibliothek schreiben muss.

Was den Updater betrifft, da habe ich noch irgendwo ein Framework rumliegen, was ich mal für meine eigene Software geschrieben habe. Versionsprüfung und Binäre Verbindung zu einem PHP-Skript, das dann mit der DB kommuniziert inklusive.

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

Bisher haben nur 10 Mann abgestimmt. Der DGL Kern besteht aus ca. 30-40 Personen. Es wäre interessant zu wissen wie viele hier konkret bereit wären
1. Das Framework zu erstellen
2. Einen eigenen Raum zu erstellen

Quasi mal guckn was die zielgruppe will.

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

Dafür sollten wir eventuell ne neue Abstimmung á la:
- Kein interesse
- Nur gaffer
- Raum erstellen
- Framework helfen
- Beides

machen.

Gruß 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

@Lossy: Heeey, du mußt auch nen raum machen
Kannst ja auch nen 2D-Raum machen ^^ Ich bin ja aktuell auch eher auf der 2D-Schiene

Könntest ja z.B. deine Schriften da im raum demonstrieren etc

Aya~