Hallo!
Hab mich endlich entschlossen eurem Forum beizutreten und hätte da ein paar Fragen.

1. Wie kann ich bei der Spieleprogrammierung Sounds möglichts Prozessor unbelastend abspielen?

2. Was ist eurer Meinung nach die beste(schnell,platzsparend) Methode, um Texturen zu laden. Ich hab glaux und glBMP ausprobiert und glBMP war nicht besonders schnell. Vielleicht kennt ihr jemand ja eine bessere Library.

3. Euhm... wie kann ich eine Kugel rendern. Ich habs schon mit Bezier-Kurven versucht, aber irgendwie klappst nicht so recht.

4. Ich hab da soetwas wie eine ganz simple "Film-Engine" geschrieben. Mittels TStringlist lade ich aus einer Datei die Strings heraus und lasse Delphi verstehen, was es mit Strings wie "TexLoad[...]" oder "MoveObject[...]" anfangen soll. Alle Daten werden so einmalig in Arrays geladen und bei jedem Rendervorgang in den Prozeduren verwendet.
Naja, irgendwie ist das aber ziemlich langsam... und ausserdem kann ja jeder die Script-Datei lesen.


Übrigens finde ich Eure Tutorials (von denen ich den größten Teil meines OGL Wissen habe) ziemlich gut. Ausserdem bewundere ich eure nicht kommerzielle Einstellung. Über irgendeine Hilfe, wäre ich dankbar.
Rüdiger

Indem du eine auf Soundhardware angepasste Library verwendest. FMOD, BASS oder OpenAL verwenden im Normalfall die Hardwarebeschleunigung der Soundkarte, also hat die CPU da kaum Arbeit.


Was heisst den langsam? Die Loader spielen doch nur eine Rolle beim Laden der Texturen, und dort spielt dann eher die Geschwindigkeit deines Datenträgers und die Uploadgeschwindigkeit deiner OpenGL-Implementation eine Rolle. High-End Grafikkarten können Texturen im Normalfall schneller erstellen als langsame Grafikkarten, der Loader spielt da eine eher untergeordnete Rolle.


Indem du der Kugel einfach mehr Segmente bzw. Seiten verpasst. Ich hab selbst mal ne Routine zum Erstellen von Kugeln auf Dreicksbasis geschrieben, der ich dann als Parameter die Zahl der Unterteilungen angeben kann. Je mehr Unterteilungen, desto runder wirkt die Kugel. Bezuer-Kurven oder NURBS würde ich vermeiden, da die auf aktueller Hardware recht langsam werden.


Auch hier : Was heisst langsam? Der Zugriff auf die Strings sollte doch sehr schnell erfolgen, oder machst du das in jedem Renderdurchlauf? Wenn ja, dann würde ich die Strings beim Programmstart auswerten und in einen eigenen Datentyp umwandeln, der z.B. solche Eigenschaften wie Bewegung, zu ladende Texture, usw. hat. Das dürfte sehr viel schnneller sein. Im Bezug auf die Lesbarkeit musst du dir halt was anderes einfallen lassen, also entweder deine Strings verschlüsseln oder ohne Strings arbeiten und z.B. Records in deine Datei schreiben.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

in der glu sind doch Kugeln enthalten!? (Neben anderen grundobjekten wie Würfel, Torus(Donut) und Teekanne(8)) )

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

Ja, aber auf die Primitiven in der glu hat man nur sehr wenige Einflussmöglichkeiten. Ausser (wenn überhaupt) die Zahl der Seiten per Parameter angeben zu können ist da nicht viel, also spätestens wenn man eigene Texturkoordinaten oder sonst was selbst machen will, muss mans selbst machen, zumal so ne Funktion die Dreiecksdaten für eine Kugel erstellt alles andere als schwer zu schreiben ist.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Richtig. Aber fuer die 08/15-Kugel reicht es voellig aus. Mehr Einflussnahme hat man ueber die OpenGL Quadrics - mehr geht dann wirklich nur noch mit selber machen. Schwer ist es nicht, aber fuer uebertrieben sinnvoll halte ich das idR auch nicht - ich gehe einfach mal davon aus, dass die GLU-Programmierer schnelleren und effizienteren Code schreiben koennen als ich.

Das glaube ich nicht. Wenn ich mich nicht irre dann zeichnet GLUT die Objekte direkt. Also mit glVertex etc. Und das einzige was man dann noch machen könnte, um es auf moderner Hardware zu beschleunigen, wäre es in eine Displayliste zu packen. Dann hat man aber keine Möglichkeit mehr (außer mit VP's) diese Objekte zur Laufzeit zu verändern. Ein Teufelskreis.
Abgesehen davon wird die Glut seit Jahren nicht mehr weiterentwickelt (wenn dann habe ich davon nichts mitbekommen). Und ich habe gerade mal einen Blick in die Quellen geworfen. Na ja. Von Assembler keine Spur. Also wurde das auch nicht so super optimiert. Was aber auch nicht unbedingt sein muss. Denn normal ist es für demos oder man speichert es sich in einer DL.

Also für allen denen die Glut zu unflexibel ist der kann sich ja die Quellen ziehen und die benötigten Methoden übersetzen und erweitern.

GLU <> GLUT

Aber auch in der GLU Bibliothek hat sich nicht viel seit OpenGL 1.1 getan (Mesa3D bietet einige neue Features - aber auch nix zum Luftsprünge machen).
Die Quadric Routinen sind übrigens ziemlich unoptimiert - das bekommt man selbst besser hin (verstehe sowieso nicht, wieso die in der GLU gelandet sind - mit mehr Matheroutinen wäre den meisten wahrscheinlich eher geholfen gewesen).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/