DGL
https://delphigl.com/forum/

Demonstrationsprojekt
https://delphigl.com/forum/viewtopic.php?f=21&t=7275
Seite 5 von 6

Autor:  Average Idiot [ Mo Feb 25, 2008 21:21 ]
Betreff des Beitrags: 

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 :lol: )

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.

Autor:  Finalspace [ Di Feb 26, 2008 13:30 ]
Betreff des Beitrags: 

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:

Code:
  1.  
  2. benchmark.exe
  3.     data\
  4.         modules\
  5.             fillrate.bmp (Screenshot für die Benchmark liste)
  6.             fillrate.dll (Benchmark dll um die fillrate zu testen)
  7.             poly.bmp (Screenshot für die Benchmark liste)
  8.             poly.dll (Benchmark dll um polygon komplexität zu testen)
  9.  


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:

Code:
  1.  
  2. library simple;
  3.  
  4. uses
  5.   Windows,
  6.   OpenGL;
  7.  
  8. const
  9.   cName = 'Simple Hello World';
  10.  
  11.   cDescCount = 4;
  12.   cDescs : array [0..cDescCount-1] of String = (
  13.   'Simple polygon with colors',
  14.   'by Finalspace',
  15.   'made with delphi',
  16.   'www.delphigl.com'
  17.   );
  18.  
  19. var
  20.   Durchlauf : Int64;
  21.   Freq      : Int64;
  22.   FrameTime : Double;
  23.  
  24. procedure GetName(var _Name : PChar); stdcall;
  25. begin
  26.   _Name := PChar(cName);
  27. end;
  28.  
  29. procedure GetDesriptionCount(var _DescCount : Integer); stdcall;
  30. begin
  31.   _DescCount := cDescCount;
  32. end;
  33.  
  34. procedure GetDesription(_DescIndex : Integer; var _Desc : PChar); stdcall;
  35. begin
  36.   _Desc := PChar(cDescs[_DescIndex]);
  37. end;
  38.  
  39. procedure Init(_Datapath : PChar); stdcall;
  40. begin
  41.   // OpenGL Standard Setup
  42.   glEnable(GL_DEPTH_TEST);
  43.   glDepthFunc(GL_LESS);
  44.   glDisable(GL_BLEND);
  45.   glBlendFunc(GL_ONE, GL_ONE);
  46.   glLineWidth(1.0);
  47.   glDisable(GL_LINE_SMOOTH);
  48.   glEnable(GL_TEXTURE_2D);
  49.   glClearColor(0,0,0,0);
  50.   glCullFace(GL_CCW);
  51.   glDisable(GL_CULL_FACE);
  52.  
  53.   Durchlauf := GetTickCount + 5000;
  54.   QueryPerformanceFrequency(Freq);
  55.  
  56.   FrameTime := 0;
  57. end;
  58.  
  59. procedure Kill; stdcall;
  60. begin
  61. end;
  62.  
  63. function Render(_Canceled : Boolean) : Boolean; stdcall;
  64. var
  65.   StartZ,
  66.   EndZ : Int64;
  67. begin
  68.   QueryPerformanceCounter(StartZ);
  69.  
  70.   // In die Modelansichtsmatrix wechseln
  71.   glMatrixMode(GL_MODELVIEW);
  72.   // Identitätsmatrix laden
  73.   glLoadIdentity;
  74.  
  75.   // Farb- und Tiefenpuffer löschen
  76.   glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
  77.   glLoadIdentity;
  78.  
  79.   glTranslatef(0,0,-4);
  80.  
  81.   glBegin(GL_POLYGON);
  82.     glColor3f(1,0,0); glVertex3f(-1.5, -1, 0);
  83.     glColor3f(0,1,0); glVertex3f(1.5, -1, 0);
  84.     glColor3f(0,0,1); glVertex3f(0.0, 1, 0);
  85.   glEnd;
  86.  
  87.   QueryPerformanceCounter(EndZ);
  88.  
  89.   FrameTime := (EndZ-StartZ)/Freq;
  90.  
  91.   Result := (not _Canceled) and (GetTickCount < Durchlauf);
  92. end;
  93.  
  94. exports
  95.   GetName name 'GetName',
  96.   GetDesriptionCount name 'GetDesriptionCount',
  97.   GetDesription name 'GetDesription',
  98.   Init name 'Init',
  99.   Kill name 'Kill',
  100.   Render name 'Render';
  101.  
  102. begin
  103. end.
  104.  
  105.  





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 :(

Dateianhänge:
Dateikommentar: Screenshot des Benchmark tools (Unfertig)
dgl_benchmark_shotx.JPG
dgl_benchmark_shotx.JPG [ 35.95 KiB | 10697-mal betrachtet ]

Autor:  littleDave [ Di Feb 26, 2008 14:05 ]
Betreff des Beitrags: 

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)

Autor:  TAK2004 [ Di Feb 26, 2008 16:06 ]
Betreff des Beitrags: 

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.

Autor:  Finalspace [ Di Feb 26, 2008 16:24 ]
Betreff des Beitrags: 

TAK2004 hat geschrieben:
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.


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.

Autor:  Aya [ Mi Feb 27, 2008 02:02 ]
Betreff des Beitrags: 

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

Autor:  Lossy eX [ Mi Feb 27, 2008 09:17 ]
Betreff des Beitrags: 

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.

Autor:  MatReno [ Mi Feb 27, 2008 10:51 ]
Betreff des Beitrags: 

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.

Autor:  Lord Horazont [ Mi Feb 27, 2008 14:05 ]
Betreff des Beitrags: 

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

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

Autor:  MatReno [ Mi Feb 27, 2008 15:43 ]
Betreff des Beitrags: 

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


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).


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

Autor:  Nils [ Do Feb 28, 2008 17:46 ]
Betreff des Beitrags: 

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.

Autor:  Lossy eX [ Do Feb 28, 2008 19:32 ]
Betreff des Beitrags: 

Nils hat geschrieben:
Wenn wir so etwas wie glBitmap nehmen, sollten wir uns drum kümmern, dass wir glBitmap auch mindestens bei Linux zum Laufen bekommen.

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.

Autor:  MatReno [ Fr Feb 29, 2008 10:32 ]
Betreff des Beitrags: 

Lossy hat geschrieben:
Das steht groß auf meiner Liste. Bin bisher nur noch nicht dazu gekommen es fertig zu stellen.

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

Autor:  Lossy eX [ Fr Feb 29, 2008 11:02 ]
Betreff des Beitrags: 

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. ;)

Autor:  TAK2004 [ Fr Feb 29, 2008 18:04 ]
Betreff des Beitrags: 

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.

Seite 5 von 6 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/