Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 22:41

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 86 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste

Habt ihr Lust auf so ein Projekt ?
Kein Interesse 6%  6%  [ 1 ]
Nur anschauen 35%  35%  [ 6 ]
Ich möchte einen Raum erstellen 24%  24%  [ 4 ]
Ich möchte beim Framework helfen 18%  18%  [ 3 ]
Ich möchte helfen und einen Raum erstellen 18%  18%  [ 3 ]
Abstimmungen insgesamt : 17
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 22, 2008 12:39 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Jan 31, 2005 11:02
Beiträge: 432
Wohnort: Rheinlandpfalz
Ich hatte mir das Framework auch nicht so komplex vorgestellt.
Da ja jeder Raum nur alleine gerendert wird, kann man ja ruhig alle Zeichenbefehle in der Raum-dll belassen.
Das Framework stellt lediglich die Events zur Verfügung, lädt alle Räume und ruft die Render-Procedures auf.
Zumindest als grobes Konzept. :roll:

Für die States ist jeder Raum selbst zuständig, dass heißt er kann ja alle States, die er benötigt, in der Init und dann wärend dem Rendern machen.
Und jeden Graphik-Speicher der allokiert wurde muss natürlich auch wieder freigegeben werden.

_________________
http://texelviews.delphigl.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 22, 2008 13:43 
Offline
DGL Member

Registriert: Mo Dez 26, 2005 22:27
Beiträge: 117
Programmiersprache: Pascal, C++
wow! Top Idee muss ich sagen. :P


Aber da ich nicht glaube dass meine fähigkeiten es zulassen beim Framework usw mitzuarbeiten, lasse ich das lieber, aber ein Raum is sicher drin.

_________________
Ein Computer wird das tun, was Du programmierst - nicht das, was Du willst.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 22, 2008 13:58 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Da ja eigentlich nur ein Raum gleichzeitig Sichtbar sein sollte, ist das mit den States doch kein Problem, oder?
Ein größeres Problem hat man bei offenen Türen, aber die würde ich sowieso vermeiden, wegen der Rechenleistung.

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 22, 2008 14:30 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Bei den türen würde ich das so machen, das es ne funktion gibt "DrawFloor" welche halt das zeichnet was hinter der tür ist.

Wobei es durchaus schick wäre, wenn man durch den Flur läuft und links und rechts direkt in die räume reinschauen kann, das wäre auch problemlos möglich allerdings würden die übergänge zwischen flur und raum merkwürdig aussehen, weil dann der raum das shading im flur nicht beeinflussen könnte und ungekehrt (ich würde dann im framework den raum in ne textur rendern und die dann einfach hinter die tür setzen)

Aya


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 22, 2008 16:12 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Also Türen würde ich da schon rein machen. A wegen den Übergängen und B ist nur son Klingelschild neben dem Übergang auch nciht das wahre :wink:

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 22, 2008 16:39 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Wenn du die zeichenroutinen in die dll auslagserst, dann müsste jedes plugin den opengl context erstellen und zerstören, da sonnst die states verfuscht sind, die funktionen mehrfach verlinkt wären und eventuell sogar speicherprobleme gibt.

Wenn ich das richtig verstehe, dann wollt ihre eigentlich nur ein Starter schreiben.
Der via OpenGL ein Gang zeichnet und je nach anzahl der plugins er länger wird.
Wenn man ein Gang betretet soll alles was der Starter nutzt zerstört werden und das Plugin aufgerufen werden, welches dann alles was er braucht erstellt.
Also müsste bei jedem wechsel zwischen Gang und Plugin der OpenGL Context zerstört werden, die funktionen 0 gesetzt werden, eventuell noch Physik und sound libs das gleiche geschehen, damit dann das Plugin alles wieder initieren darf und umgekehrt.

Ein Framework wäre was anderes, es würde die Funktionalität liefern und der Entwickler erstellt mit diesem Framework nur noch Content und erweitert es.
Framework und und Engine sind übrigens das gleiche.

Die alternative zum starter wäre das Framework und dinge wie erstelle VBO,FBO,GLSL Shader wären zu befehlen zusammengefasst und werden zur verfügung gestellt.

Ein Framework wäre nicht so flexibel aber ein Starter wäre ein hoher programmieraufwand, da man für jedes plugin alles nochmal programmieren muss.

edit:
https://svn.linuxprofessionals.org/filedetails.php?repname=karmarama&path=%2Fprerelease%2Fcode%2FKar_GL.pas
So sieht z.B. eine Kapeslung, von OpenGL Befehlen, aus die ich für Karmarama verwende.
glBegin/glEnd sollte man eh nicht mehr verwenden und VBO hat eh nur Vorteile beim zeichnen, masken und solche dinge kann man auch über den shader regeln und somit müsste man ledeglich die set Funktionen für Materials, Licht, Fog,.. 1zu1 übernehmen. Die die schonmal OpenGL an eine Scriptsprache gebunden haben, z.B. für Lumina ;) oder um Materials zu realisieren, die wissen, wie wenig man wirklich von opengl an das plugin bekannt machen muss.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 23, 2008 15:57 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Ich versuch mir gerade das fertige Projekt vorzustellen, um mal nen groben Ansatz zu haben. Dabei kam mir eine Idee: Kenn jemand noch Serious Sam 1? Da gabs auch so eine "Engine-Demo". Ein langer Gang, links und rechts waren Räume in denen dann die Features der Engine demonstriert wurden. Beim Betreten eines Raumes wurde dann noch eben ein kurzer Text auf das HUD geladen, in dem dann stand, welche Technik hier verwendet wurde ... nur so als Anreiz von mir ...

Um z.B. das Problem zu vermeiden, dass mehrere Räume gleichzeitig gerendert werden, kann man ja Türen in den Gang einbauen. Sobald eine Tür geöffnet wird, schließen sich automatisch alle anderen Türen, so dass nur der Gang und der Raum in der Render-List stehen.

Eine weitere Sache die mir gerade in denn Sinn kommt, wäre eine eigene State-Machine im Hauptprogramm zu schreiben. Dann werden die einzelnen States nicht mit glEnable/glDisable geändert, sondern z.B. mit dglEnable/dglDisable. Die Funktionen dglEnable stellt das Hauptprogramm zur Verfügung. Die Statemachine im Hauptprogramm hat einen Default-Wert, der immer wieder zurückgesetzt wird. Und um zukünftige Extensions nicht auszuschließen, würde ich eine Art Integer-Bool-Liste erstellen. Sobald dglEnable einen Integer-Wert übergibt, der noch nicht in der Liste ist, wird dieser einfach hinzugefügt. Nach dem Rendern geht die Statemachine einfach die Referenz-States und die aktuellen States durch und Enabled/Disabled alles so, dass man den original-State wieder hat.
Das gleiche lässt sich auch auf Shader und Matrizen erweitern.

@TAK2004: ist es nicht möglich, den Render-Context vom Hauptprogramm auch in der DLL zu nutzen? wglMakeCurrent? Wenn man die opengl32.dll im Hauptprogramm und in der dll initialisiert, sollten zwei Funktionen (z.B. glEnable im Hauptprogramm und glEnable in der DLL) auf die gleiche Speicheraddresse zeigen, oder steh ich da gerade aufm schlauch?

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 23, 2008 18:29 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Klar kann man den Hauptcontext verwenden aber es ist übelster aufwand mit den States und das zeichnen kann sehr schnell in die hose gehen.
Ich habe ja mal für Blender eine Schnittstelle programmiert, welche erlaubt eigene Renderer Engine per dll/so zu laden, die kommunikation und das Zeichnen erlaubt.
Diese haben dann den OpenGL Context von Blender genutzt und es hat viele Probleme mit sich gebracht, Lighting, Farben, zeichenfehler und man muss dann auch ein callback zur verfügung stellen, wenn sich das Fenster verändert. Wenn man Fehler im Plugin macht ist die ganze Anwendung im Popo.
Dann muss man für das Plugin alle Befehle nochmal aus den OpenGL Treiber laden und führt 2mal die gleichen Funktionen.
Eine saubere Lösung sieht garantiert anders aus, z.B. Kapselung oder Interface.
Wenn ich so weit bin und meine Engine steht, werde ich das Interface neu programmieren und auf UDP und TCP/IP setzen, da man so beides in abgeschlossenen Prozessen laufen lassen kann und die sich nicht gegenseitig im Weg stehen können.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 24, 2008 17:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Seh ich das zu kompliziert, oder was spricht gegen ein simples glPushAttrib??

Wenn es darauf hinauslaufen soll, das es wirklich mehr eine Engine wird würde ich mich wieder streichen für die dev. des Frameworks, weil dafür fehlt mir dann doch irgendwie die zeit, das wird ja dann was doch recht umfangreiches..

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 24, 2008 18:05 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
glPushAttr und glPopAttr funzt aber es wurden bei mir trotzdem farben für lichter und 1-2 andere Flags nicht mit gepusht.

edit: Wenn man die Arbeit nicht im Framework macht, dann hat man sie xmal bei den Plugins. Es ist allerdings nicht mein Projekt und auch nicht meine Entscheidung.
Von viel Arbeit kann man nicht sprechen, wenn die Specs stehen ist das Coden des Frameworks ne arbeit von 1-2 Tagen.
Je mehr Zeit man in die Planung steckt, des so weniger Zeit wird beim programmieren gebraucht und die Konzeptionsphase findet ja im Forum als Gruppe statt.

Framework_Enable(Flag);
Framework_Disable(Flag);
Framework_SetValue(Flag,zeiger);
Framework_GetValue(Flag,zeiger);
Framework_CreateMesh(IDzeiger);
Framework_DestroyMesh(IDzeiger);
Framework_MeshSetFlags(IDzeiger,Flags);
Framework_MeshBind(IDzeiger);
Framework_MeshDraw(IDzeiger);
Framework_PhysicCreateObject(IDzeiger);
Framework_PhysicAddMesh(PhysicIDzeiger,MeshIDzeiger);
Framework_PhysicSetFlag(IDzeiger,Flags);
Framework_CreateShader(IDzeiger);
Framework_ShaderLoad(IDzeiger,pointer);
Framework_ShaderBind(IDzeiger);
Framework_ShaderUnbind(IDzeiger);
Framework_CreateTexture(IDzeiger);
Framework_TextureFlags(IDzeiger,Flags);
Framework_TextureLoad(IDzeiger,zeiger);<-abhängig von Format, welches per Flag bestimmt wurde
...

So kannst du z.B. das laden,konvertieren auf pluginseite belassen(unabhängigkeit von Dateiformaten) aber trotzdem die Kompatibilität wahren, indem du ein Standard setzt. Grafik,Physik und Sound werden dann schon vorgegeben(z.B. OGL, Newton, OpenAL) und das Plugin muss dann die verwendeten Formate(ogg,tga,jpg,png,wav,ogg,...) in die Hardwarenahen Formate der Libs konvertieren.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 24, 2008 20:06 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Hmm... Ich würde da gerne etwas zu sagen. Ich persönlich würde in meinem Raum z.B. größtenteils auf einen Modelloader verzichten und einen großteil manuell rendern.
Auch sollten wir über die Auswahl der Bibliotheken für den nicht-OpenGL kram noch einmal abstimmen oder sowas, denn OpenAL z.B. halte ich persönlich für nicht so toll. Ich wäre für FMOD, welches ja für Freeware-Projekte ebenfalls kostenlos ist, aber deutlich mehr fähigkeiten hat als OpenAL. Das Handling ist natürlich nicht das gleiche wie bei OpenGL und OpenAL, aber wenn man sich eine kurze Zeit in die Docs eingelesen hat, gehts eigentlich (da kann ich auch wieder helfen, ich habe mit FMOD schon einiges ausprobiert). Übrigens erspart man sich mit FMOD vieles, da es nativ einen großen Haufen Dateiformate unterstützt.

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 24, 2008 23:57 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Wenn man FMOD einsetzt sollte man aber ein mechanismus einbauen oder darauf hinweisen, dass keine mp3's verwendet werden können/dürfen, da diese unter einer anderen Lizenz steht(bei mehr als 5000 kopien werden 2500$ fällig). Was bedeutet, dass man auf ogg ausweichen muss oder halt midi formate verwendet.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Feb 25, 2008 11:18 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Jan 31, 2005 11:02
Beiträge: 432
Wohnort: Rheinlandpfalz
Da ich selber gerne FMod verwende, ziehe ich FMod natürlich vor.
Zu den Räumen: Ich würde in meinem auch jetzt kein komplexes Model verwenden,
eben wie Horazont gesagt hat, auch vieles manuell machen.
Außerdem dachte ich für den Anfang an einen nicht allzu komplexen Raum...

TAK2004 hat geschrieben:
bei mehr als 5000 kopien werden 2500$ fällig

:shock: Das wusste ich ja gar nicht... Ich dachte nur, wenn man es kommerziell einsetzt?!

_________________
http://texelviews.delphigl.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Feb 25, 2008 13:52 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
TAK2004 hat geschrieben:
Wenn man FMOD einsetzt sollte man aber ein mechanismus einbauen oder darauf hinweisen, dass keine mp3's verwendet werden können/dürfen, da diese unter einer anderen Lizenz steht(bei mehr als 5000 kopien werden 2500$ fällig). Was bedeutet, dass man auf ogg ausweichen muss oder halt midi formate verwendet.


Das ist nicht nur bei FMOD so. Das hängt einfach mit der Tatsache zusammen, dass diese typen, die das Copyright am MP3-Format haben, diese Lizenzgebühren verlangen. Das wäre auch so, wenn der MP3-Codec auf andere weise integriert werden würde. Ist also so gesehen unabhängig von FMOD.

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Feb 25, 2008 17:33 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Lord Horazont hat geschrieben:
TAK2004 hat geschrieben:
Wenn man FMOD einsetzt sollte man aber ein mechanismus einbauen oder darauf hinweisen, dass keine mp3's verwendet werden können/dürfen, da diese unter einer anderen Lizenz steht(bei mehr als 5000 kopien werden 2500$ fällig). Was bedeutet, dass man auf ogg ausweichen muss oder halt midi formate verwendet.


Das ist nicht nur bei FMOD so. Das hängt einfach mit der Tatsache zusammen, dass diese typen, die das Copyright am MP3-Format haben, diese Lizenzgebühren verlangen. Das wäre auch so, wenn der MP3-Codec auf andere weise integriert werden würde. Ist also so gesehen unabhängig von FMOD.

Gruß Lord Horazont

Aus diesen Gründen nutzt man auch überwiegend Ogg bei kleinen Projekten, da es völlig frei ist und auch OpenSource.
Deswegen hab ich z.B. OpenAL mit Ogg Vorbis in verwendung.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 86 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 20 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.180s | 19 Queries | GZIP : On ]