Guten Morgen, Forum!
Ich habe seit gestern ein seltsames Problem und auch nachdem ich einmal drüber geschlafen habe noch keine Lösung. Ich bin auch nicht ganz sicher, ob dieses Forum das richtige für mein Problem ist, da die Fehlermeldung eigentlich von Cg produziert wird... Aber nun der Reihe nach!

Momentan probiere ich ein wenig mit Cg herum, habe mir also das Cg Toolkit von Nvidia heruntergeladen. Da die Bibliotheksdateien "cg.lib" und "cgGL.lib" daraus offenbar nicht mit Borlands Turbo C++ (ist ja eng verwandt mit Delphi) kooperieren wollen, habe ich mir die Librarys aus dem NeHe Tutorial (http://www.joachimrohde.com/cms/xoops/modules/articles/article.php?id=57) geholt - und alles hat funktioniert.

Auch mein Skinning Shader compiliert brav und ohne Fehlermeldung - solange ich meine Anwendung aus der IDE heraus mit F9 oder der grünen "Play"-Taste starte. Wenn ich die Exe-Datei jedoch auf dem selben PC manuell aus dem Windows Explorer starte, erstellt Cg kein Fragment Program mehr; stattdessen gibt nur noch NULL (unter Delphi nil) zurück. cgGetLastListing gibt statt einer Fehlermeldung einen leeren String zurück.

Das Problem ist, dass ich ja nichtmal Variablen auslesen kann - denn das geht nur, wenn ich mein Programm aus Turbo C++ heraus starte und dann gibt es ja gar keinen Fehler. Ich bin etwas verzweifelt, weil ich nicht die Spur eines Lösungsansatzes habe und es doch eigentlich überhaupt nicht sein darf, dass sich ein Programm in Verbindung mit der IDE anders (höchstens langsamer) verhält als normal.

Ich habe zwar keinen Plan, ob euch das irgendwas nützt: Mein OS ist Win Vista 32-bit, meine GraKa eine GeForce 7100 und der Treiber seit meinem letzten Post hier topaktuell (GeForce 191.07). Auch auf einem anderen PC mit ATI Radeon 9800 Pro und WinXP 32-bit habe ich mein Programm schon getestet: dort wird auch kein Fragment Shader kompiliert und die Fehlermeldung ist ebenfalls ein leerer String. Entwickler-Tools sind da leider nicht installiert (es ist nicht mein PC), daher kann ich nur vermuten, dass das Ergebnis da exakt gleich wäre.

Wenn ihr wollt, kann ich natürlich auch noch den Shader-Code posten, allerdings wollte ich es nicht einfach so machen weil das meinen ohnehin schon sehr dicken Post noch weiter aufblähen würde und ich nicht glaube, dass die Fehlerursache darin liegt.

Gruß mrtrain

Schade, immernoch keiner, der mir einen Tipp geben kann. Falls es daran liegt, dass ihr etwas an meinem Post nicht ganz versteht, dann schreibt doch bitte wenigstens das in eure Antwort. Ich bin selbstverständlich gerne bereit jemandem, der sich die Mühe macht, mir zu helfen, mein Problem ausührlicher/verständlicher/was-auch-immer zu erläutern.

Schreckt bitte auch nicht davor zurück, dass ich nicht Pascal sondern C++ verwende. Turbo C++ ist schließlich auch von Borland und intern nur ein Delphi mit zusätzlichem C/C++-Compiler. Bitte lasst mich nicht ganz alleine mit meinem Problem!

Ich wär euch sehr dankbar für eine Antwort!

Gruß mrtrain

Immer ruhig bleiben. DGL mag zwar für extrem schnelle Antwortzeiten und lebhafte Diskussionen bekannt sein (*behauptung in den Raum stell*), aber dein Problem ist ja schon etwas exotischer Art. Und ich war heute anlässlich des Fedora 12 releases auch etwas beschäftigt, sonst hätte ich dir schon früher geantwortet.

Also. Ich würde dir erstmal Empfehlen, Debugausgaben zum Beispiel auf die Konsole zu machen. WriteLn (oder das pendant für C++, müsste ja dann printf sein) wirkt manchmal wunder. Das kommt auch ohne Debugger aus . Wenn du nicht weisst, wie du die Konsolenausgaben erhälst bzw das Programm überhaupt dazu bringst, ein Konsolenfenster zu erzeugen, kannst du es immernoch mit einer kleinen Logdatei probieren.

Ansonsten würde ich sagen, dass dein Problem wahrscheinlich etwas größer ist, als du vielleicht hoffst. Denn normalerweise hat man mit Debugger (denn das ist der Unterschied zwischen in IDE und nicht in IDE) eher mehr Probleme als weniger. Dass es ohne Debugger schlechter funktioniert könnte an eventuellen Schutzmechanismen des Debuggers liegen. Im Zweifelsfall mal deinen Code grob nach möglichen Pufferüberläufen durchsuchen. Alles ist möglich. Aber schau erstmal nach den Debugausgaben .

Viel Erfolg
greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich danke dir für deine Antwort, Lord Horazont! Ja, das mit der Log-Datei habe ich auch schon probiert, allerdings ist bis jetzt noch nicht viel hilfreiches bei rausgekommen.

*schluck* Noch größer?!?

Ja, das halte ich für recht wahrscheinlich. Ich glaube ich werde mein Log-Debugging noch einmal etwas ausführlicher wiederholen.

Danke für jede weitere Hilfe,

mrtrain

Ich hab zwar jetzt nur den Titel gelesen und bin kurz über die Beiträge drüber geflogen, aber ich hab schon einmal von so einem Problem gehört.
Überprüf einmal direkt Zugriffe auf den Speicher, also ob da gültige Adressen verwendet werden. Wenn der Debugger an is, kann es sein dass du auf dessen Speicher zugreifst, was ja legal ist, aber wenn dieser aus ist, greifst du stattdessen auf geschützten Speicher zu.

Hoffe das hilft weiter.
Andreas

Debugger initialisieren Variablen oft mit 0. Das führt öfter zu dem Effekt, daß Programme außerhalb des Debuggers plötzlich nicht mehr wollen, weil sie dort mit beliebigen Werten starten - und z.B. ein Pointer bei dem Du anfangs Null erwartest, plötzlich auf existierenden Heap zeigt, nicht als Null erkannt und verwendet wird, dort irgendwelche ungeplanten Dinge passieren und es dann ganz schnell nach hinten losgeht. Variablen auf Initialisierung Prüfen ist daher mein Tipp.

Erstmal danke für die Antworten! Ich glaube wir sind uns alle einig, dass es wahrscheinlich irgendwas mit bösen Speicherzugriffen zu tun hat.

@Delphic: Eigentlich bemühe ich mich auch immer alles manuell auf 0 zu setzen, aber *grins* natürlich passieren mir da manchmal Fehler. Ich werd nochmal mein Programm darauf untersuchen. Das gleiche gilt für die Speicherzugriffe ins Nichts.

Das Problem hat seine Merkwürdigkeit noch einmal unterstrichen. Als ich die Log-Funktion wieder eingebaut hatte, funktionierte das Programm sowohl mit als auch ohne Debugger. Wie man sich darüber ärgern kann, dass ein Programm funktioniert!

BTW: Wenn etwas schiefging, dann gab cgGetError immer CG_UNKNOWN_PROFILE_ERROR aus - dabei hatte ich mir das Profil wie im Wiki beschrieben mit cgGLGetLatestProfile geholt (bei mir CG_PROFILE_FP40). Ich weiß nicht ob euch diese Info was nützt.

Gruß mrtrain

Oh... Das bestätigt meine Vermutung. Irgendwas stimmt mit den Speicherzugriffen nicht. Dadurch, dass du den Log erzeugst und schreibst, verschieben sich dann in der Exe irgendwelche Dinge, genauso wie im Speicher. Damit können an bestimmten Stellen wieder gültige Werte stehen. Also definitiv, da ist irgendwas nicht initialisiert oder es gibt einen Pufferüberlauf.

Viel Erfolg beim Suchen

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

So, ich bin zwar noch nicht viel weiter gekommen, aber das wird schon noch...

Eine kurze Frage zwischendurch: Darf man den Shader-Quellcode nach der Übergabe an den Compiler mit cgCreateProgram wieder aus dem Heap löschen? Sollte man doch? Der Cg-Doku kann ich das leider nicht entnehmen. Wenn ich nämlich den Vertexshader-Code nach seinem Laden lösche, kompiliert der Fragmentshader (sowohl mit als auch ohne Debugger) nicht. Natürlich könnte ich ihn auch erst beim Beenden des Programms löschen, aber wenn ich schonmal anfange, "100% sauber" zu coden, dann würde ich es auch gerne konsequent machen.

Würd' mich über weitere Antworten freuen

mrtrain

Also wenn es den Sourcecode noch nach dem Kompilieren braucht, solltest du das Framework wechseln.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich glaube ehrlich gesagt nicht, dass Cg das wirklich braucht. Vermutlich hat das eher mit irgendwelchen fehlerhaften Speicherzugriffen zu tun (obwohl ich immer noch nix gefunden habe ). Ich wollte nur *wissen* wie es offiziell ist (nicht nur vermuten). Vielleicht weiß es ja einer von euch, oder vielleicht hat einer schonmal mit Cg gearbeitet (wovon ich mal sehr stark ausgehe) und dabei den ersten Shadercode schon gelöscht bevor er den zweiten kompiliert hat.

@Framework wechseln: Ich habe ja schon von GLSL zu Cg gewechselt, weil GLSL irgendwie nur Sche*** gemacht hat und Cg zumindest theoretisch noch andere Vorteile hat:
- selbe Syntax wie HLSL, daher wohl bessere Unterstützung seitens Nvidia / ATI, weil sich diese ja primär auf DirectX konzentrieren
- evtl. höhere Performance wegen 1. und wegen den Datentypen half & fixed
- vor allem von Nvidia deutlich besserer Support, weil sie es selbst in die Welt gesetzt haben

Naja, wenn ich mir jetzt so ansehe, was Cg bei mir macht, dann ist das eigentlich das gleiche wie GLSL vorher - nämlich nicht funktionieren. Aber es bringt freilich nichts jetzt wieder zu GLSL zurückzugehen und zu hoffen, dass es da klappt. Mir reicht es eigentlich, wenn *eine* Shadersprache funzt.

Gruß mrtrain

Ich wollte damit auch nicht sagen das du wechseln sollst. Ich kenne nur cg nicht gut genug, um aus deiner Aussage zu schließen, dass du den Code erst nach dem wirklichen Kompilieren frei gibst. aber ich gehe mal davon aus, dem ist so.

okay ... du bist nicht zufällig unter Linux unterwegs? Wenn ja, könnte ich dir valgrind ans herz legen ... Ein extrem gutes Debug-Tool welches dich auf jeden unerlaubten Speicherzugriff hinweist.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

@Linux: Ich habe mir mal OpenSuse 11 installiert aber nach ca. 1 Monat wieder runtergeschmissen. Nicht dass ich es irgendwie schlecht fand, nur die Hardwareunterstützung wollte nicht. Da ich es v.a. zum proggen mit OpenGL gedacht hatte, war ein funktionierender Grafiktreiber Pflicht. In c't hatte ich gelesen, dass es die proprietären Nvidia-Treiber sehr einfach zu installieren als Download (ich glaube über YaST) gab - dumm nur, dass die Distrubution nicht mit meinem Netzwerkchip kooperieren wollte. Das Gefrickel mit manuellem kompilieren und einspielen des Treibers habe ich mir dann gespart, da ich eben Linux-Anfänger war.


Deshalb warte ich lieber mal die Meinung eines Experten auf dem Gebiet ab. Mich ärgert es immer, wenn ich mich nicht auf eine Sache konzentrieren kann, weil ich die Arbeit ständig wegen irgendwelcher Änderungen unterbrochen wird. Ich denke jeder Programmierer kann das nachvollziehen. Trtotzdem danke für deinen Rat!

Gruß mrtrain