mist, Lars war schneller )

Ich hab' auch nix gegen FP. Aber Du wolltest wissen, warum wir Delphi verwenden. Und glaub mir, ich weiß wovon uch Rede. Ich verwende das Teil Tag-Täglich!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Das denke ich auch. Es ist einfach so, dass eine moderne IDE nicht mehr aus einer professionellen Programmierung wegzudenken ist. Der letzte Praktikant, der mir anderes beweisen wollte mußte zumindest einsehen, dass er gegen mich ziemlich alt aussah. Liegt vielleicht auch am Menschen, aber... wer eine moderne IDE hat und diese auch nutzt(!) kann sich ne Menge fehler ersparen. Man wie habe ich gelacht, als er mal im Texteditor nach einem Fehler gesucht hat, weil nichts lief und alles irgendwie nicht da war. Habe es reingeladen und Dank Syntax-Highlight auch sofort gemerkt, dass er oben die Kommentare nicht geschlossen hat? Sicherlich es geht auf viele Wegen und man kann ne Menge mit Erfahrung ausgleichen, aber wer professionell Arbeitet, weiß was "Zeit" bedeutet und da ist Delphi eine vorzügliche Sprache für. Es liegt daher sehr nahe es auch für OpenGL einzusetzen, gerade weil FP doch weitaus näher an Delphi dran ist als an C++. Das man die VCL als negativ ansieht kann ich nicht nachvollziehen. Ich selbst bevorzuge gerade bei OpenGL eher die API und neuerdings die SDL und habe somit keine Nachteile gegenüber deiner SDL-Implementation. Der Code sollte sich rein faktisch 1:1 übernehmen lassen...

Geschmacksfrage eben...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Kann FP eigentlich die Fließkomma-Zahlen /z.B. Vectoren-Rechnung) für MMX, SSE, SSE2 und 3DNow! Optimieren?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

FP verwendet diese Befehle auch in normalen Ausdrücken. Delphi kann das glaube ich nur über den Inline Assembler. Ob das für OpenGL allerdings sonderlich relevant ist, weiß man nicht, da auf der CPU sowieso keine umfangreichen Vertex Berechnungen durchgeführt werden sollten und es dafür ARB_vertex_program gibt. Bei Physik und Kollisionserkennung sieht das allerdings schon wieder anders aus.

Wieso nicht relevant? Für jedes Objekt, welches sich bewegt, müssen diverse Vektorrechnungen durchgeführt werden. Und das einfach über Vertex-Programme zu machen halt ich nun für weniger Sinnvoll. Denn nur wegen einer Objekte-Bewegung eine sündhaft teure 3D-Karte zu verlangen ist dann schon etwas overkilled. Stell Dir vor, jemand hat 'nen Standard-Atlhon PC mit 'ner GF4 MX. Nix mit Vertex-Shader. Zumindest nicht viel. Also muss für Positions- und Bewegungsberechnung eben der 3DNow! Befehlssatz herhalten! Es gibt zudem wirklich genug, wass nicht vom VP übernomment werden muss!

Ich persönlich geh' so vor: Zuerst muss das Teil laufen. Wenn man per FP noch 3D-Now oder ähnliches in seinen Berechnungen verwenden kann, gut (kann dann per TASM prima in Delphi eingebunden werden). Ansonsten muss eben die normale FPU hinhalten. Wenn das dann läuft, kann man eine Version für leistungsfähigere Karten mit VPs erstellen. Aber eben erst dann.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Nope...dafür gibts doch seit der GeForce1 die Hardware T&L-Einheit, die diese Arbeit dem Prozessor abnimmt.Und Karten die eine solche nicht besitzen, haben normalerweise bereits im Treiber für 3DNow!/SSE optimierte Routinen um diese Berechnungen durchzuführen.

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

Was ich meinte ist folgendes: Für optimale Geschwindigkeit packt man die Vertex Daten ja in ein nach Möglichkeit statisches VBO. Dann hat man von der CPU sowieso keinen direkten Zugriff mehr drauf und kann nur noch über Vertex Programme was ändern.
Bei Berechnungen auf der CPU bringt es natürlich schon was. Bei D3D gibt's ja diese Mathe DLL, die automatisch auf SSE(2) oder 3DNow umschaltet je nachdem was gerade unterstützt wird. Ich vermute die kann man auch von OpenGL aus nutzen.

Warum denn so umständlich?

Bei GLScene ist eine erweiterte geometry.pas dabei. Diese beinhaltet eine größere Anzahl an Berechnungsmethoden. Und die Methoden sind teilweise mit AMD, SIMD und Fließkommabefehlen (ASM) ausgestattet. Eine automatische Detection inklusive.

@SOS: Naja, die Berechnungen der T&L-Engine werd' ich auch nicht selbst machen. Mir gings eher um die oben genannten Objekt-Bewegungen (wie z.B. im Objekt-Bewegungs-Tut oder bei Char-Animationen).

@D3D: Seit DirectX9 wird (laut dem was ich gelesen hab) kein 3DNow mehr unterstützt. Da drückt dann halt mal wieder das Wintel Imperium durch

@VBO: Wenn ich z.B. ein Genger per Skeletal-Animation laufen lassen will, aber keine VPs zur Verfügung hab, dürfte es schneller sein die Berechnungen von entsprechend optimierten Prozeduren auf der CPU durchzuführen und aus dem Grafik-Speicher heraus das ganze darstellen. Oder ist die VP-Emu so optimiert, das man dann die animation per Software-VP machen kann?

@Gemotry: Ja, die verwend ich ja auch. Hab' mich eben nur gefragt, ob FP das ganze auch von selbst unterstützt. Dann könnte man den ein oder anderen Problemfall etvl. in FP schreiben, vom Compiler in TASM-Qeullcode übersetzen lassen und diesen dann als OBJ-File in Delphi einbinden.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Kann Delphi C++ Headers verwenden???

Ne, wozu denn?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Tja das sehe ich schon mal als GROßEN Nachteil!
Wenn der Compiler C++ kann kann er einfach und leicht C++ Headers includen. Dann braucht man nicht immer irgend welche spezial Versionen zu downloaden. Auch anders rum. C++ Compiler sollten Pascal verstehen können. Ich habe mich mit Compilerbau befasst. Und zwischen
C++ und Pascal liegen keine Unterschiede außer die verwendeten Funktionen. Im weiteren bin ich für FreePascal, da es ein Non-Profit Compiler ist. Man kann selber den SourceCode verändern usw.!
Die Compatibilität ist auch bemerkenswert. Kommt mir nicht mit Delphis Linux Version. Es ist ein Unterschied einen Windows Compiler Linux fähig zu machen als, dass der Compiler Unabhängig ist. So sind die FP Libarys Plattformunabhängig! Ich kann nur jemandem raten umzusteigen!

Bye!

Wie gesagt: soabald es entsrpechende Tools gibt, damit man mit FP produktiv arbeiten kann, gibt's da auch keine probleme mehr. Und die Vorteile die Du auflistest sind ja in Ordnung. Aber Delphi hat eben auch Vorteile. Neben der besseren Produktivität find' ich es z.B. praktischer, für überladene Funktionen die direktive overload mit angeben zu müssen. So kann es eben nicht passieren, versehentlich eine Funktion mit dem gleichen Namen zu erstellen und sich nachher zu wundern, warum nix geht (was bei großen Projekten durch aus mal passieren kann). Und eben die Verwaltung von Projekt-Gruppen (z.B.: die Haupt-EXE, eine kleine zusatz-EXE, diverse DLLs. Alles praktisch verwalltet und in einer Projektgruppe gut angeordnet). Deswegen wird eben FP (evtl. sogar leider, mag ja sein) nicht in kommerzeiellen bereichen eingesetzt.

Aber wie gesagt: sollte sich das ändern, kann es schon sein dass FP auch in kommerziellen Bereichen Fuß fasst.

@Linux: Stimmt zwar, jedoch ist a) abzuwarten, was mit Kylix sich noch so alles tut, b) ist Kylix ein reiner Linux-Compiler (man kann wie unter Deklphi core-API Programme erstellen). Es gibt eben nur eine Windows-Like oberfläche, damit die User sich beim Umstieg leichter tun und keine Probleme haben, von ein und dem selbem Produkt eine Win32 und Linux Version herraus zu bringen.

Und was C/C++ und Pascal angeht: Kylix hat C/C++ integriert. Genau so wie Borland C/C++ Builder Delphi integriert hat. Warum die Jungs sich das bei Delphi gespart haben weiss ich nicht. Aber für header fänd' ich's auch sinnvoll!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ich weiß ja nicht wie du auf Overload kommst was FreePascal sehr gut
beherscht. LOL

Aber wie schon gesagt:
+FP ist Non-Profit
+FP !!!SEHR!!! schnelle Codeoptimierung "Bis zur Klassen 5 Optimierung können nur etwa 4-5 Compiler die ich kenne und die sind C++!"
+FP Libary OS Unabhängig
+FP kannst dich beteiligen an der Entwicklung und eigene Wünsche rein bringen wie ich es schon oft gemacht habe!
+FP ist !!!KOSTENLOS!!!
+FP ist nicht umbedingt Objektbasiert
+FP kann Delphi Code auch "sehe das als Nachteile, denn wieso Resourcen in nen Scheiß Compiler stecken? Lieber eigenen weiter entwickeln. Naja...*g*"

Und und und...

Das ist in meinen Augen kein Vorteil.Wenn man von etwas Leben muss (Borland lebt ja von den Erlösen seiner Compiler), dann strengt man sich mehr an und hängt auch mehr Arbeit in ein solches Projekt.


Acuh kein tolles Argument.Wir arbeiten hier ja alle mit der OpenGL-API, und da spielt Codeoptimierung keine so große Rolle.Hier ist eher die Grafikkarte und deren Leistung ausschlaggebend.Ausserdem behaupte ich mal, das FP kaum schneller ist als Delphi.


Toll...Delphi/Kylix erlaubt es, für Windows und Linux Programme zu schreiben (ohne großen Konvertierungsaufwand).Alle anderen Betriebssysteme spielen eh eine untergeordnete Rolle.


Dazu sag ich nur : "Viele Köche verderben den Brei...".Ich bin mir sicher, das Borland fähigere Leute haben als die Entwickler von FP.


Die Delphi Personal Edition auch!


Delphi auch nicht (Siehe Konsolenanwendung).Aber OOP ist eine der positivsten Entwicklungen in Sachen Programmiersprachen die es je gegeben hat, weshalb dein Argument auch diesmal nicht als Vorteil für FP zieht.


Den Satz versteh ich nicht...liegt wohl daran das er rein grammatisch keinen Sinn ergibt.


P.S. : Mit deinem recht negativen Gepredige schades du FP mehr als du ihm nutzt.In der ganzen Diskussion hier ist noch nicht ein Argument gekommen, welches jemanden zum Umstieg auf FP bewegen könnte.

P.P.S. : Ich hab nix gegen FP, aber vor dieser Diskussion war es mir sympathischer.

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