Das deutsche QBasic- und FreeBASIC-Forum

[Nitroxis]

Ich hab mich schon länger mal gefragt, welches von beiden schneller ist (insbesondere für Spiele), denn OOP find ich sehr vorteilhaft für Spieleprogrammierung.
Aber bevor ich in VB.net ein Spiel schreibe, wollte ich einmal fragen, ob das überhaupt möglich ist (von der Geschwindigkeit her).
Denn ich wollte das Spiel dann schon in OpenGL machen und es hat wahrscheinlich große Arrays usw.
Kann mir das jemand sagen?

[28398]

<ot level="leicht">
Arrays + OpenGL?
Schonmal was von VBOs oder zumindest VAs gehört?
</ot>

Und warum nicht? VB.Net wird teilweise per JIT-Compiler in Maschinencode übersetzt; Derartige Perfomanceprobleme gibt es einfach nicht. Du wirst nur ein ganz anderes Problem haben: Keine Beispiele in VB.Net. Außerdem ist es ja bei .Net (also zumindest bei C#, womit ich ja auch an einem Projekt arbeite) eine Freude C-Funktionen zu importieren...

[Nitroxis]

Davon habe ich gehört
Mit den Arrays meine ich Partikelarrays und keine Vertexarrays

[28398]

Partikel im Array: abcdefgh
Die Lifetime von d läuft ab. Du entfernst das Elemtent indem du efgh irgendwohin kopierst und defgh deallokiert. Dann kopierst du efgh zurück (memmove() ).
Listen, wenn du mit VB.Net arbeitest wird es da ja wohl sowas wie STL-Vectoren und Listen geben.

(Nur so am Rande)

[darkinsanity]

Falls du ernsthaft vorhast ein Partikelsystem zu schreiben, solltest du auf keinen Fall ein Array verwenden. Entweder eine linked list oder du nimmst VBO´s.
Noch besser ist es, wenn du das komplett auf der GPU machst, denn CPU basierte Partikelsysteme sind der Flaschenhals schlechthin, da du jede Menge Daten auf die GraKa schicken musst.

In meiner Engine ist das bisher mit einer linked list gelöst, gezeichnet wirds über die Point-Sprite Extension.

Einige Links:
http://wiki.delphigl.com/index.php/Tutorial_Partikel1
http://wiki.delphigl.com/index.php/Tutorial_Vertexbufferobject
http://wiki.delphigl.com/index.php/GLSL_Partikel
http://wiki.delphigl.com/index.php/GLSL_Partikel_2
http://www.gamedev.net/reference/list.asp?categoryid=225
_________________
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak

[Nitroxis]

Das mit den VBOs hört sich sehr schnell an.
Aber es gibt keine Funktion namens glGenBuffers, glBindBufferARB, ...
Ist das ein OpenGL-Plugin?!
Wenn ja, wie benutze ich das mit FreeBASIC?

Edit: Habs gefunden (Ist in glext.bi)
Hab auch die deklaration gefunden...
Aber es kommt immernoch der Fehler, das er die Variable glGenBuffers nicht finden kann...

Edit 2: Ok nach längerem suchen in bi habe ich gesehen das man eine Variable definieren muss, damit er die Funktionen deklariert.
Jetzt sagt mir der Compiler folgendes:

[28398]

Dir fehlt ganz klar GLEW. Unter allen anderen Betriebssystemen, die OpenGL unterstützten benötigst du das nicht.

[Nitroxis]

Nein... ich habe glew im system32 ordner.
Edit:
Nochmal was zu den linked lists
Wie liest du bei einer linked list die 10000 partikel enthält das partikel 5000 aus? dann musst du ja alle partikel < 5000 durchschleifen um an dieses eine ranzukommen

[28398]

Wie du ganz richtig erkannt hast, ist bei Listen der Aufwand um das Element n auszulesen O(n) und nicht - wie bei Vektoren oder Arrays - O(1) ist.
Aber bei _durchdachten_ Partikelsystem besteht normalreweise überhaupt kein Grund, warum man plötzlich an ein Partikel n dran möchte. Normalerweise iteriert man durch die Liste.
Und noch ganz kurz btw.: Bei double-linked-lists gibt es eigentlich keine richtigen Indizen, weil die Liste weder Anfang noch Ende hat.

[Stueber]

Warum soll eine double-linked-list kein Ende haben? Laut Definition in der englischen Wikipedia ist eine double-linked-list eine ganz normale linked-list bei der jedes Element zusätzlich den Zeiger auf das vorherige Element enthält, um sich auch rückwärts bewegen zu können. Also ist der Start das Element dessen Zurück-Zeiger 0 ist und das Ende das Element dessen Vorwärts-Zeiger 0 ist.

[The_Muh]

Man kann nartürlich den prev_ptr von element1 auf das letzte element der liste mappen und den next_ptr vom letzten element auf element 1 legen... aber wer sowas macht, sollte vorher gründlich nachdenken was er da tut...
_________________
// nicht mehr aktiv //

[Nitroxis]

Das beantwort aber nicht meine Frage, warum glext nicht funktioniert...

[28398]

Weil du vll. glew einbinden solltest? Und nicht nur die Binary im %path% rumgammeln muss.

[Stueber]

Naja, sieht nach einem Link-Fehler aus. Da schaut man zuerst mal ob sich die .a Datei in FBORDNER/lib befindet. Wenn ja und der Fehler trotzdem bleibt am besten mal ganz oben im Quelltext #inclib "name_der_lib" benutzen. Wie die .a Datei heist musst du selber rausfinden...

[Nitroxis]

Der .a datei enthält die funktionen "glGenBuffers" und so weiter nicht...
Ich denke mir mal die ist unvollständig

[28398]

Ist sie nicht *Kopfschüttel*
Zu faul zum Suchen:
http://www.opengl.org/wiki/Getting_started#Windows

Und auch noch zu faul um sich den Getting-started-20-Zeiler auf glew.sf.net anzuschauen.

[darkinsanity]

So, zu dem Problem sag ich mal wieder was. Das Problem ist, das die Erweiterung für VBOs zwar schon seit OpenGL 1.5 im Core ist, aber Windows nur ein OpenGL 1.1 Interface zur Verfügung stellt. Trotzdem geht es, wenn man es über die Erweiterung macht:

Zuerst brauchst du am Anfang deines Codes natürlich folgendes:

[28398]

@darkinsanity:
Wenn man das so macht, ist das mehr als .... zeitaufwändig, unsicher und stupide. Ohne GLew kann man unter Windows effektiv nicht arbeiten. Ok, da gibts noch GLee, aber GLew ist der dé-facto Standard.

Btw.: Wenn ich wo bei mir drunter schreiber "das klingt unlogisch", dann meine ich nicht den Inhalt meines Postings, sondern die Formulierung. Fände ich selbst den Inhalt logisch würde ich es schließlich nicht posten.

/EDIT:
Ok, ich poste jetzt mal ein Beispiel, sonst bin ich nur wieder der Arrogante Sack, der die Leute dazu bringen will, es selber zu lernen

[Nitroxis]

@28398: Und in deinem Beispiel läuft GLEW dann?
Also ich meine ganz normal (ohne irgendwelche funktionspointer, ...)

[darkinsanity]

Was ist daran bitteschön stupide? Ein Blick in den source von glew offenbart, das es dort ganz genauso gemacht wird. Nur wird eben dem Nutzer etwas mehr Komfort geboten, da man es nicht mehr selbst machen muss, und der Code wird dort Größtenteils aus den Spezifikationen der OpenGL Registry generiert. Gerade für kleinere Projekte halte ich es aber für sinnvoll, nicht gleich auf so etwas wie glew zurückzugreifen. Zumal alleine der glew.h header über en halbes MB groß ist.
Aber für OpenGL-Einsteiger und Programme mit vielen Extensions ist glew definitiv sinnvoll, da geb ich dir Recht.

Btw Wo hast du denn die FB-header dafür her? Mein selbst übersetzter zickt im Moment nur rum...

@Nitroxis: glew initialisiert dir unter Windows die ganzen Funktionspointer, das heißt, du musst nur glew initialisieren (aber erst nachdem OpenGL initialisiert ist) und kannst dann alle Funktionen der Extensions, die glew unterstützt, nutzen. Du kannst also glGenBuffers usw. einfach aufrufen.
_________________
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak