:huh: Whoo...
habe mich zwar noch nie wirklich mit der Materie befaßt, habe mich allerdings beim lesen einiger Artikel schon mehrfach geärgert, dass die ganzen Sprachen alle so c-ähnlich sind. Dagegen wirkt das, was Du da gepostet hast schon wie ein heiliger Segen. Würde es sehr begrüßen, wenn man davon mal etwas zu sehen bekommt und es auch konsequent durchgezogen wird. Wäre defintiv etwas einmaliges und würde sicherlich von vielen Pascalern als alternative zu den anderen Shader-Sprachen verstanden werden. Nice

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

klingt wirklich klasse! ist aber wohl nach ein sehr ambitioniertes Projekt...

Wenn du mal soweit bist, dass man eine kleine Demo draus machen kann, würde ich mich sehr freuen das ganze mal zu sehen! Halt uns auf jeden Fall auf dem Laufenden.

-lith

_________________
Selber Denken macht klug!

Also die neue Version wirkt gigantisch gut. Vor allem da man (ich) dank verständlicher Dokumentation auch tatsächlich was damit anfangen kann .

Bis HLSL (bzw. OpenGL 2.0) tatsächlich von den meisten Treibern angeboten und unterstützt werden, wird wohl noch einiges Wasser den Bach hinunter fließen - und auch wenn es da ist (bis jetzt gibt es ja noch nicht mal eine offizielle OpenGL 1.5 Spezifikation), wird fxPascal nicht unbedingt überflüssig sein, da Vertex- und Fragmentprogramme immer noch unterstützt werden.

Ich nehme an, du hast das Ganze schon ausführlich getestet, bzw. hast auch nicht vor dieses Projekt in nacher Zukunft aufzugeben? Wenn ich einen Vorschlag machen dürfte: sehr angenehm wäre es, wenn du die Konstruktoren von TVertexProgram bzw. TFragmentProgram überladen würdest, sodass sie auch Strings akzeptieren, in denen das Programm liegt.
Ich arbeite innerhalb eines Programmes lieber mit direkten Stringkonstanten - und finde es etwas umständlich, daraus erst einen TStringStream instanziieren und danach wieder freigeben zu müssen zu müssen.

Ich hab' mir jedenfalls NVEmulate heruntergeladen, damit ich mit meiner Geforce 3 auch in den Genuss von Fragmentprogrammen kommen kann und werde mich mit fxPascal spielen.
Falls ich damit auf einen grünen Zweig komme - hättest du etwas dagegen, wenn ich über fxPascal eventuell Mcad um Vertex- und Fragmentprogramme erweitere? Selbstverständlich würdest du auch Credits bekommen.

Jedenfalls finde ich es einfach cool, mit eine Pascal ähnliche Alternative zu CG zu haben, die man auch noch direkt in seine Delphiprogramme einbauen kann, und die brauchbar dokumentiert ist ... cool

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

@Mars:
Danke fürs Testen. fxPascal ist als frei benutzbare unit gedacht und kann daher überall eingebunden werden. Ich verwende den Shader Compiler z.B. damit man bei Materialien nicht nur Texturen, sondern auch Vertex und Fragment Programme in einer lesbaren Form angeben kann. Im Moment sind mir keine Fehler bekannt, aber wenn du welche findest, dann schick mir bitte das Programm, bei dem der Fehler auftritt, so daß ich ihn dann korrigieren kann. Die Sache mit dem String anstelle des Streams ist eine gute Idee und ich werde das dann auch ändern.

fxPascal ist bereits in Mcad eingebaut und funktioniert super (weitere Informationen dazu in der Projektesektion).
Was noch nicht klappt, sind Kommentare in geschweiften Klammern - an deinem Code habe ich zwar gesehen, dass du diese wahrscheinlich unterstützt, fxPascal liefert aber eine Fehlermeldung, sobald der Kompiler drüberstolpert. Wenn du das ändern könntest, wäre es nicht schlecht - zumal das Syntaxhighlighting im Sourcecodeeditor in Mcad für Kommentare bereits eingebaut ist.

Zum Programmieren angenehmer wäre es, wenn du ESyntaxError von EAbort anstelle von Exception ableiten würdest - das musste ich nämlich ändern, um eine "stille" Fehlerbehandlung zu implementieren, praktisch wäre es außerdem, wenn du aus fxPascal.pdf ein HTML oder WinHelp Dokument machen könntest, das ließe sich dann gut als Hilfe im Programm aufrufen.

Wenn Mcad dann funktionalen Shadercode erzeugen kann, würde ich für Delphiprogrammierer gerne die Option einbauen, diesen direkt über fxPascal in den erstellten Source einzubauen (ähnlich wie C/C++ Programmierer sich entscheiden können, mit extgl eine OpenGL Bibliothek einzubinden, die fast alle Extensions unterstützt)
a) würde dich das stören (selbstverständlich bleibt fxPascal unverändert, kommt in ein eigenes Verzeichnis bei erstellten Projekten - mit sämtlicher Dokumentation die du zur Verfügung hast, bzw. weitergeben möchtest) ?
b) passhader.pas klingt nicht so toll, ich finde fxPascal.pas wäre einfach ein schönerer Unitname

Vielleicht könntest du ja auch die neue Mcad Version begutachten, und vielleicht einige Tips geben, wo die Erstellung von Shadercode mordsmäßig umständlich ist, bzw. was dir noch abgeht, um die Funktionalität von fxPascal abzudecken.
Ganz toll wäre es auch, wenn du noch mehr fxPascal Skripts für diverse häufig verwendete Anwendungen in die Dokumentation einbauen könntest - einige hast du ja bereits drin, und die helfen beim Einstieg eigentlich fast am Meisten weiter.

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

fxPascal hat mir jetzt endgültig den Anlass gegeben, mir eine neue Grafikkarte zuzulegen (Upgrade von Geforce3 auf GeforceFx 5600pro). Auch wenn's nicht die schnellste Karte ist, ist sie doch leise und unterstützt alles was ich brauche zu einem moderaten Preis.
Aber das nur nebenher...

Beim Herumspielen mit fxPascal ist mir aufgefallen, dass Arrays nicht funktionieren, folgender Code


liefert diese Fehlermeldung:

exptected könntest du auch noch ausbessern, wenn du grad schon dabei bist .

Im Zusammenhang mit Arrays wären auch noch for-Schleifen praktisch. Es ist mir klar, dass es eigentlich keine Sprünge im ARB Shaderassembler gibt, daher müsste eine Schleife wahrscheinlich eher wie ein REPT Makro (in MASM) aufgebaut sein.
Mir schwebt ein Konstrukt a'la

Die Schleife muss ebenso wie Arrays beim Index 0 beginnen, i ist gar keine richtige Variable, sondern nur ein Platzhalter für einen konstanten Ausdruck, der sich über den Code, der durch die Schleife erzeugt wird und sich n (eigentlich n+1) mal wiederholt (also n mal hintereindander abgelegt wird) jeweils pro Schleifendurchlauf inkrementiert wird und innerhalb der Schleife als konstanter Ausdruck fungiert, vor allem aber auch als Index in Arrays eingesetzt werden kann.



würde also folgenden Code erzeugen



i müsste evtl. gar nicht deklariert werden (da i ja eigentlich keine Variable ist) - es sei denn du willst so Delphiähnlich wie möglich bleiben, dann könntest du einen neuen Typ integer einführen, der dann halt nur für Schleifen und eventuell für Konstanten verwendet werden kann.
Vorzeitige Schleifenabbrüche (break) gibt es keine, Integer können logischerweise auch nicht verändert werden, da sie ja nur Platzhalter für konstante, ganzzahlige Ausdrücke sind.

Auf die Idee bin ich gekommen, als ich gestern abend ein Beispiel aus NVidias CG Paket nach fxPascal portieren wollte (bin dann aber wegen der fehlenden Arrays nicht besonders weit gekommen, es wäre schon gegangen, der Code hätte aber ziemlich umständlich ausgesehen) - CG unterstützt auch for-Schleifen (allerdings mit einer Fließkommazahl als Schleifenzähler) - mir käme ein Integer jedoch um einiges logischer vor, insbesondere da Schleifenzähler aufgrund der fehlenden Sprünge ohnehin keine "echten" Variablen sein können, weshalb NVidias Umsetzung ziemlich sicher der soeben Vorgeschlagenen entspricht.
Unbedingt notwendig sind sie natürlich nicht, würden aber manchen Code doch lesbarer machen.

Ansonsten macht es richtig Spass mit fxPascal zu arbeiten...

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

Das mit den Arrays werde ich mir nochmal ansehen. Da wird irgendwo ein blöder Fehler sein.
Ich werde dann Schleifen auf jeden Fall noch miteinbauen. Auch wenn es nur der Lesbarkeit nützt, lohnt es sich schon.
Bei For Schleifen mit festen Anfangs und Endwerten sollte das mti dem Entrollen eigentlich immer gehen. Vielleicht eventuell sogar auch eingeschränkt bei While Schleifen. Da habe ich auch schon mal drüber nachgedacht. Die NVidia Vertex Programme in der Version 2 und die D3D VS 2.0 unterstützen sogar auch dynamische Sprünge. Da könnte man dann auch While und Repeat Schleifen völlig dynamisch machen. Leider gibt es das in der ARB Version nicht, so daß man die Schleife dann als Makro realisieren muß. Die untere Begrenzung auf 0 ist hier nicht unbedingt notwendig. Bei den Arrays ist das im Moment noch so, weil man in ARB Vertex Programmen nur Arrays mit der Untergrenze 0 deklarieren kann. Ich werde das aber noch anpassen, so daß die Begrenzung wegfällt.

Wollt' nur mal anmerken, dass ich mich schon über Schleifen und Arrays in fxPascal freuen würde (aber du sollst dich natürlich nicht gedrängt fühlen, nein nein ...)

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

Ich habe mal nachsehen und es ist kein Flüchtigkeitsfehler gewesen, sondern man kann bislang nur für Parameter und Konstanten Arrays definieren. Aber ich werde das auch noch einbauen. Dazu sind allerdings ein wenig mehr Änderungen nötig als ich zuerst gedacht habe.

Gibts zu fxPascal eigentlich auch sowas wie ne Shader-IDE?Ich wollt SETH nämlich von Grund auf neuschreiben,diesmal aber nur mit Unterstützung für fxPascal.Wenn du sowas allerdings selbst schon geschrieben hast,dann spar ich mir die Mühe.

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

Es gibt bislang keine Shader IDE und ich habe für die nächste Zeit auch keine geplant. In einer der nächsten Versionen wird aber die Möglichkeit bestehen, genaue Type Informationen auszulesen und die Programme im Einzelschritt zu simulieren.

Dann hast du hoffentlich nix dagegen,wenn ich (die Grundanwendung steht bereits) mein SETH komplett auf fxPascal umstelle und es als Open-Source veröffentliche,damit alle Interessierten dran mitarbeiten könne, oder?

Bin nämlich der festen Meinung das man fxPascal als HLSL-Alternative ein wenig pushen sollte.Ausserhalb von DGL wird das wohl kaum jemand kennen (und auch nicht nutzen).

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

Die Idee gefällt mir gut und fxPascal ist ja auch als OpenSource gedacht, damit man die Möglichkeit einer Hochsprache hat ohne ein externes Program wie z.B. den Cg Compiler installieren zu müssen.
Wie hast du das mit dem Mitarbeiten gemeint? fxPascal an sich sollte als Komponente eigentlich nicht beliebig geändert werden. Oder habe ich dich da jetzt falsch verstanden?
Die Dokumentation werde ich in der nächsten Version auch als CHM und Word Dokument hinzufügen. Außer den ARB Programmen könnte ich mir auch noch mehr Compiler Ziele wie z.B. glSlang oder NV_vertex_program2(dynamische Sprünge/Call/Return) vorstellen.

Ja,da hast du mich leicht missverstanden.Ich hab mich auf SETH bezogen und nicht auf fxPascal.Das will ich nämlich,sobald die erste brauchbare Version fertig ist,Open Source zur Verfügung stellen damit daran alle mitarbeiten können.Dadurch könnte dann evtl. sogar ne richtig gute IDE für dein fxPascal entstehen (sowas in Richtung RenderMonkey).Wenn das so läuft wie ichs mir vorstelle,könnte sich fxPascal mit solche einer IDE auch sogar neben glSlang und cG etablieren.

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

Ach so. Dann ist ja alles klar. Eine richtig gute Shader IDE ist bestimmt eine Menge Arbeit, daher ist das sicherlich angebracht, wenn mehrere mitarbeiten.