Hi ...

Ich schlage mich jetzt seit geraumer Zeit mit einem ziemlich großen Problem herum...

Ich bin vor einer Weile von MSVC++ auf GNU umgestiegen. Und ich glaube seit dem habe ich cracks in meinem Terrain.
Ich benutze zum Rendern des Terrains die Methode von Röttger, wie sie auch hier im Tut beschrieben ist.
Habe auch schon einige Einstellungen verändert und Teile anderer Implementationen eingebaut, aber ich habe trotzdem deutlich sichtbare Cracks.

Bei einer älteren Version, die noch mit MSVC++ compiliert wurde, sonst aber exakt die gleichen Methoden benutzt habe ich keine Cracks. Das kann ich mir aber irgendwie nicht erklären, die Compiler sollten doch annähernd das gleiche ausspucken oder irre ich mich da?
Also ich bin mir zu 90% sicher, dass es nicht an dem Code liegen kann, da ich ihn wie gesagt nicht verändert habe ...

Hat irgend jemand ne Ahnung woran das liegen könnte?
Habe vor einiger Zeit auch ein Problem mit meinen Stencil-Schatten gepostet (z-fighting). Das Problem bestand trotz gleichen Codes bei der MSVC++ Version auch nicht ...

Ich hab wirklich keine Ahnung ob es am Compiler liegen kann, aber ich denke hier gibts Leute, die da mehr Ahnung von haben als ich...
Würd mich freuen wenn mir wenigstens jemand sagen könnte, dass es definitiv NICHT an den Compilern liegen kann

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Um Compiler auszuschließen, müsstest du den relevanten Code zeigen.
Wenn du einen neuen GNU-Compiler hast, kann das schon anders sein.
Der VC6 ist für einen Compiler ziemlich alt und in einigen Sachen nicht standardkonform. Das wirkt sich allerdings meist darin aus, das noch Sachen erlaubt sind, die es im derzeitigen Standard nicht gibt. Von daher ist das schon komisch, was du da postest.

Du kannst ja deinen Code mal mit VC 2005 Express(is kostenlos) kompilieren und schauen, was du dann für ein Ergebnis erhälst.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Ich kenne mich nicht mit den Unterscheiden zwischen den beiden Kompilern aus aber kann eine kleine Anekdote zu Kompilerunterschieden zum Besten geben.

Und zwar habe ich vor ein paar Jahren mal mit an einer Client/Server Software gearbeitet wo der Server in MS VC++ 6 geschrieben wurde. Unerklärlicherweise kamen in der Releaseversion immer seltsame Fehler, die in der Debugversion nicht aufgetaucht sind. Nach tagelanger Suche fand der Entwickler dann herraus woran es lag. Und zwar arbeitete die eine Methode im Debug von Oben nach Unten durch den Speicher und im Release von Unten nach oben durch den Speicher. Da die Speicherbereiche aber übereinander lagen war die Reihenfolge sehr wichtig.

Was will ich also damit sagen. Ich würde mich nicht darauf verlassen, dass immer das Selbe rauskommen muss. Nicht einmal dann wenn man den selben Kompiler benutzt. Selbst kleinste Einstellungen (Optimierungsversuche) können den Code stichhaltig verändern.

Ein ehemaliger Kollege meinte auch, dass der VC++ sogar hergeht und die Schleifen aufdröselt und den Schleifenkern dann 10 Mal hintereinander aufruft um die Schleife an sich zu verkleinern. Ob das der 6er auch schon macht weiß ich aber net.

Würden alle Compiler den gleichen Objectcode liefern, würde es nicht mehre Compiler geben? Die Linux-Leute sind jedoch meist immer fix am schreien, wenn es darum geht die minimale Version des gcc anzugeben. Schneller sau der alte, optimierter etc. etc. Ich würde den entsprechenden Code bei Dir einmal durchgehene und exakt auf Pointer-Probleme hin untersuchen. Gerade die C/C++-Varianten sind an dieser Stelle meist recht eingreifbar und bei einem anderen Compiler schiebt sich das ganze dann doch in Bereiche, die man eigentlich nicht haben möchte. Den was die Compiler tun sollten (wenn schon andere Wege) ist den Source Code so umzusetzen, wie er dort steht... und das sollten sie eigenlich auch machen. Auch die Idee mit einem driten Compiler (Bzw. einer neueren Version) ist vielleicht gut, um das Problem genauer zu lokalisieren. Insgesamt vermutlich ein gutes Beispiele dafür, warum Plattformenunabhängigkeit meist doch Fehler ans Tageslicht bringt, die sonst verborgen geblieben wären.

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

Also wo ich das jetzt gerade so gelsen habe, klingt das für mich weniger nach Pointern als nach Rundungsfehlern. Eventuell sind Wertebereiche von Fließkommazahlen zwischen den Versionen anders. Und deshlab rundet er jetzt anders. Finde das aber sehr unwahrscheinlich...

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

Rundungsfehler sollten jedoch nicht so massiv ins Gewicht fallen und recht leicht identifizieren zu sein, da der Unterschied der Ecken nur ein wenig voneinander abweicht. Ich verstehe unter Löchern eher richtige Lücken, die sich da auftun, weil eine Ecke ins nirgendwo abdrifftet. Aber gut, immerhin schonmal zwei mögliche Ursachen... vielleicht gibts ja noch eine dritte?

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

Ich glaub ich dreh durch.

Habs jetzt mit MSVC++ 2005 Express compiliert (ohne etwas am Code zu ändern) und das Ergebnis:
keine Cracks ...

das kann ich mir einfach nicht erklären ...

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Hi ...

Hab mich noch bissl schlau gemacht.
Hab heraus gefunden, dass MS mit ner 53-bit Mantisse arbeitet und MingW mit 64, wie es eigentlich sein sollte.
Habe das auch auf 53 umgestellt, hat aber nichts geändert ...

Vll kann sich das ja jemand erklären ...

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

also 64 bit mantisse glaub ich nicht =) Wo wird dann der Rest der Zahl untergebracht? Also Vorzeichen und Charakteristik ... .
Hast du mal den relevanten Code etwas eingrenzen können? Oder kann es gar an verschiedenen OpenGL-Libs(unterschiedlich bezüglich der Compiler) liegen? Klingt zwar auch unwahrscheinlich, aber das ganze Problem is irgendwie unwahrscheinlich

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

was spricht den gegen 64bit mantissa? Ist dann insgesamt 10byte anstatt 8...

double hat (momentan) standardmäßig eine Datenbreite von 64 Bit, wenn die jetzt allein nur für die Mantisse genutzt werden, wo soll dann Vorzeichen und Charakteristik sein???

edit: jo was du meinst ist long double, das wird im VC unter der 32-Bit Version auch einfach als double genommen.
Nur weil er geschrieben hatte "so wie es sein muss", dachte ich er meint das normale double, was ja wohl für die meisten grafischen Koordinaten mehr als ausreicht. Hier nimmt ja sogar eigentlich eher float.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Hi ...

Also in der float.h von MingW steht folgender Kommentar:


Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Das daher der Fehler kommt is wohl aber eher unwahrscheinlich oder? Hast du externe Abhängigkeiten ,bindest irgendwelche DLLs ein?

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Hi ...

Also die DLLs sollten nicht relevant sein.
Hab da nur SDL, SDL_image, Newton und natürlich OpenGL, achja und SDL_net noch, aber die benutz ich noch garnich (da sind halt die cracks dazwischen gekommen )

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

AAAARGH

ich könnt mich köpfen !!!

Jetzt hab ich mich so extrem lange damit herum geschlagen und der Fehler war so eine verdammte Kleinigkeit:
Der GNU Compiler scheint nicht mit statischen lokalen Variablen zurecht zu kommen.

Jedenfalls hatte ich in der Methode zum Abfragen der Nachbarn eines Nodes die maximale x/z-dimension als statische lokale Variable gespeichert ... und anstatt sie als 512 zu speichern, hat er sie als 50 gespeichert, wodurch das Abfragen der Nachbarn total schief gelaufen ist.
Jetzt scheint alles zu funktionieren...
Da muss wohl noch bissl poliert werden am GNU...

Bei solchen Fehlern könnt ich echt ... naja egal

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)