Hmm ich bin jetzt ein wenig desillusioniert, wenn das so schwer ist ein "einfaches" Framework bzw. wie ich jetzt gelernt hab wohl eher Starter auf die Beine zu kriegen
Ich hatte gehofft, dass es wirklich reicht allein eine Drawmethode auszulagern (vielleicht noch Keyevents fuer Interaktion), an Sound haette ich jetzt gar nicht mal gedacht. Ein Modelloader waere vielleicht noch nuetzlich gewesen, aber ansonsten einfach Beschraenkung auf simple OpenGL Sachen (mehr kann ich ja auch nicht )

Eine Kapselung wie Tak meint entspricht nicht dem was ich zu Beginn erwartet hatte, aber wenns nicht anders geht, muss man sich ueberlegen ob man es halt so macht, oder ganz sein laesst.

_________________
Flummi: Projektseite und Projektthread

Habe jetzt erst diesen thread entdeckt, keine ahnung welcher stand momentan ist, aber ich habe definitiv interesse daran mitzuhelfen.

Ich hatte mal vor nicht so langer zeit ein Progrämmchen geschrieben, welches eigentlich im grunde fast das ist was hier besprochen wird.
Nur sollte das als Benchmark dienen... hat aber funktioniert, zumindest bis OpenGL 1.1 standard -.-

Die Anwendung war folgendermassen aufgebaut:



Jede dll hatte die OpenGL commands über die Standard Delphi "OpenGL.pas" benutzt.
Das hatte wunderbar funktioniert, da ich den initialierungsvorgang über die Hauptapplication laufen hab lassen.

Aber hatte den nachteil, das ich max. OpenGL version 1.0 benutzen konnte und selbst texturen procs nachträglich laden hätte müssen.
Sprich shader wären so ohne weiteres nicht möglich gewesen

Ich habe das ganze noch, wer interesse hat dem ich das ganze gern erklären im gegebenfalls auch posten.


Hier ist auf jedenfall nen stückchen code der library:






Und eine idee hab ich da noch, wenn das nicht schon angesprochen wurde.
Im dem uralt game Serious Sam 1, da gab es eine genial einfache techdemo.

Man hat 2 grosse Pyramiden gehabt, wo per strasse verbunden waren, in jeder pyramide gabs räume und in jedem raum war immer eine andere technik demonstriert. In dem einen wurde Blending demonistriert, in dem anderen Lightmapping und Schatten, usw.



Es wäre überaus genial wenn das ähnlich machen kann, grosse pyramide (Haus, Halle, Raumschiff) mit vielen räumen wo jeder raum halt sone dll ist
Das einzige prob wo ich da sehe, wie man das mit dem GL > 1.0 Einbinden macht, das die hauptapplikation und die dll´s auf die gleichen probs zugreifen.

PS: Schade das man nicht mehr abstimmen kann

Ich bins nochmal, wie Finalspace und ich bereits erwähnten, gab es in Serious Sam 1 eine Techdemo. Für alle, die das Game gerade nicht zur Hand haben oder es sich nicht eben installieren wollen, hab ich schnell ein 49sec-Video zur Inspiration erstellt.

Download gibts hier:
http://www.godlikesoft.de/images/external/Serious%20Sam%20Tech%20Demo.zip (5.5 MB) (tested with VLC)

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

Bei Unreal3 haben die die Techdemo von Sam1 auch aufgegriffen und ein Weg mit allen besonderheiten gespickt.
Ich denke, man sollte die Räume und den Gang nicht gegenseitig einsehbar machen, vieleicht ein Portal, Beamplatform oder eine Tür, die man beim anklicken in den Raum gelangt. Wichtig ist auch zu beachten, dass ich und Oc2k1 z.B. c/c++ verwenden und man dabei die unterschiedlichen Header beachten sollte.

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

Projekte: https://github.com/tak2004

Jo, seh ich genauso... einfach ne simple tür könnte helfen

Die Header werden dann halt auch für c/c++ sein, also sollte man es nicht gross Objekt orientiert basteln, sondern eher prozedural.

Hi,

also... ich finde nach wie vor, mit einem simplen glPushAttribs und evtl ein paar extra-würsten ist es völlig getan.
Denn, was mich daran faszinieren würde wäre, dass ich im grunde ein stink normales OpenGL programm schreibe und das später einfach in den flur gepackt wird.. ich hab keine lust engine-spezifische sachen zu beachten, sondern einfach coden als wäre es nen normales programm.

Als alternative zu glPushAttribs würde mir noch einfallen einfach immer einen zweiten Offscreen-Rendering-Context für die räume zu erstellen. Die räume rendern dann in ihren eigenen Context und das MainProgramm nutzt nurnoch die fertigen Bilder.

Aya

Also das mit den Attributen. Ich muss ehrlich gestehen, dass ich da keinen zu großen Aufwand treiben würde, denn um es perfekt und sicher hinzubekommen muss man einen imensen Aufwand treiben. Zu mal es mit Sicherheit immer irgendwo Lücken geben wird. Es genügt doch eigentlich wenn man sagt. Alles was gesetzt wurde muss auch wieder zurückgesetzt werden! Da die einzelnen Räume ja auch Texturen erstellen können müssen diese auch irgendwann wieder gelöscht werden. Das Gleiche gilt für Shader, VBO, FBO etc etc etc. Also muss jeder Raum eine Methode zum Initialisieren und zum Deinitialisieren bereit stellen. Das ist etwas wo ich die Verantwortung ganz klar beim Ersteller des Raumes sehe. Denn Texturen VBOs muss jeder Raum selber wieder frei geben. Das funktioniert über Push und PopAttribs nicht und würde sonst nur sinnlos den Speicher zufressen

Und falls sich da jemand nicht dran hält wird man das schnell feststellen, denn dann wird höchstwahrscheinlich die Lobby nach dem Verlassen eines Raumen nicht mehr so aussehen wie zuvor. Außerdem sind die Quellen der meisten ja Räume vermutlich ja auch öffentlich und wenn jemand etwas sieht wird er sicherlich so nett sein und es dann sagen.

Engine: Man kann mit einer Engine nicht alle Anwendungsfälle abdecken. Und außerdem liegt dann der Lerneffekt nur bei den Leuten die das Framework erstellen. Denn alle Anderen wissen anschließend nur wie man erfolgreich diese Engine benutzt. Aber mit OpenGL hatten sie doch dann nichts zu tun.

Man kann und sollte den Entwicklern aber durchaus unter die Arme greifen. Also so etwas wie Texturen oder Modelle laden. Wenn man dort bereits Funktionalitäten zur Verfügung stellt, dann muss nicht jeder Raum so etwas selber implementieren, denn Texturen wird vermutlich mal jeder Raum benutzen. Falls man etwas anderes braucht kann man es immer noch selber einbauen. Also da sehe ich das Ideal eigentlich irgendwo in der Mitte. Das Framework sollte unterstützen und nicht dominieren. Denn dann ist es eine Arbeitserleichterung für Raumersteller. Nicht zu komplex und frustrierend für die Frameworker (ein halbfertiges Framework ist nur etwas für die Tonne). Und keine vollkommen abstrakte Schicht mit der man sonst nichts weiter anfangen kann.

So wie Lossy sehe ich das auch.
Jeder Raumhersteller ist verantwortlich, die OpenGL-States so wieder zurückzusetzen, wie er sie bekommen hat.

So Sachen wie Texturen laden etc. könnte ich mir vorstellen, dass man das über das Framework laufen lässt.
Das Framework hat dann halt einen Texture-Loader (z.B die glBitmap), und man kann über einen Callback seine Texturen laden lassen, bzw. bekommt dann Indices auf diese zurück, und kann sie dann in seinem Raum einfach binden (evtl kann man dafür auch noch nen Callback machen).

Bzgl Models:
Ich denke es wird schwierig sein, das Model-laden in das Framework zu integrieren, da man sich dann auf ein Format/Loader einigen müsste, und man nicht mehr flexibel genug wäre...

Mit Sound ist das ne andere Sache. FMod kann man ja im Framework laufen lassen, und dann, ähnlich wie für die Texturen, den Räume Zugriff darauf geben.

_________________
http://texelviews.delphigl.com

So würde ich das nicht sagen. Ich würde es eher so formulieren, dass man alles wieder ausschalten muss, was man eingeschaltet hat, sodass man davon ausgehen kann, dass alles ausgeschaltet ist, wenn man anfängt zu rendern. Das gilt dann auch für den Lobby-Renderer des Frameworks: Alles sollte auf aus sein, auch der Depth Test (wobei man sich darüber sicherlich streiten kann).

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

Das ist ja im Prinzip das selbe... man muss sich nur entscheiden, was default-mäßig aus ist, und was nicht.

_________________
http://texelviews.delphigl.com

Was soll ich dazu schon sagen: Natürlich soll jeder seine Stats wieder zurücksetzen. Sonst hat ein Raum erstellen nicht mehr viel mit Programmieren zu tun sondern ist wieder Engine-basierend (in meinen Augen ist das zwar schon programmieren, aber viel zu automatisiert, sozusagen LaTeX-OpenGL, wobei ich LaTeX sehr gut finde). Wenn wir so etwas wie glBitmap nehmen, sollten wir uns drum kümmern, dass wir glBitmap auch mindestens bei Linux zum Laufen bekommen.

_________________
Meine Musik: spiker-music.net

Das steht groß auf meiner Liste. Bin bisher nur noch nicht dazu gekommen es fertig zu stellen. Ich habe schon einen recht weitreichenden Support für SDL und Linux eingebaut. Allerdings alles noch nicht wirklich gut getestet bzw gibt es noch einige Stellen die noch komplett auskommentiert sind. Aber so etwas wie die Unit JPEG und Graphics sind optional bzw konfigurierbar.

Das freut mich! Dann gibt es keine Argumente mehr gegen glBitmap.

_________________
http://texelviews.delphigl.com

Na ja. Aktuell sind da noch reichlich Baustellen. Und bevor ich mich da intensiv drum kümmern kann/werde muss ich erst die Fonts richtig veröffentlichen. Ich kann euch aber den aktuellen Stand als Developerversion zur Verfügung stellen. Damit sollten sehr viel von den typischen Sachen aber schon gehen. Also das bitte nicht zu euphorisch sehen.

Mit den Stats finde ich, ist eine gute Lösung.
FMod direkt einzubinden und den Plugins zur verfügung zu stellen halte ich auch als brauchbare Lösung.
Ein Datenformat für Models mit zuliefern finde ich allerdings falsch.
Gerade bei Datenformaten gehen die Meinungen extrem auseinander, jeder hat andere ansprüche oder sogar eigene Formate mit bestimmten Features, da sollte man den pluginschreiber die Klinke in die Hand drücken.

Zum Thema Physik, wir sollten definitiv auf eine Fertige Lösung ala Newton, Ode, Bullet, Havok verzichten, denn erstens hab ich teilweise schlechte Erfahrungen mit der Kompatibilität gemacht(32bit/64bit,windows/linux) und dann kann es auch im Konflikt mit der Physikalischen Implementierung von z.B. Partikel oder ähnlichem, in einem Plugin stehen.
Wenn man sagt, im Gang soll Newton oder ähnliches genutzt werden und im Plugin kann man dann selber entscheiden ist auch keine Lösung, da sich sonnst das Verhalten des Akteurs verändern kann(reibung, laggs,geschwindigkeit,...).
Eine Routine zur erkennung von Kollision zwischen Spieler und Umwelt, Strahl und Umwelt, sowie eine einfache Reaktion auf Kollision sollte reichen.
So könnte man dann z.B. bei Kollisionen auf bestimmte Objekte die Reaktion erweitern.

Eine weitere Lösung, vieleicht auch die bessere wäre eine Kamerapfad im Raum(vom plugin festgelegt) und laufen im Gang(eine fertige Physiklösung oder eine eigene, die beim raum betreten abgeschalten wird). Aussehen könnte dann sowas wie folgt. Kamera startet und fliegt zu einem bestimmten Punkt und wartet, der User kann nun in alle Richtungen gucken und auch interagieren(wenn was verfügbar ist) und dann fährt die Kamera zum nächsten Punkt.

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

Projekte: https://github.com/tak2004