Ich hab ein klines Problem mit GL unter C++.

wenn ich das hier versuche:


seh ich nur die Quads...von Textur ist weit und breit nix zu sehn.
Ich hab direkt vor dem besagten aufruf, mal ein Quad gerendert. Das hab ich geshcafft, indem ich bei den Texturkoordinaten (0,0)...(1,1) genommen hab.

Ich vermute, dass C++ mit den Brüchen was unanständiges anfängt, und GL das net kapiert.

Wisst ihr was ich falsch mache?

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

Es wird eine Integer Division (div) durchgeführt, falls beide Operanden int sind. Daher muß man hinter die Konstanten ein f schreiben: 8f/511f

Hmmmm sowas hatte ich befürchtet....

Wenn ich das aber ändere in die von dir propagierte Version erhalte ich:



Ist das vielleicht ein VisualC++ "Standard"?

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

Probiers mal mit 8.0f/115.0f

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

habs mit 8./115. gelöst.

Also...ohne wieder C++ vs. Delphi Schlammschlachten auszufechten... Die Operatorsache in Delphi is mir da lieber. Bruche sind niemals Integer, außer man dividiert geziehlt mit DIV.

Nunja... Man gewöhnt sich vermutlich an alles... nur hält einem solcher Kleingram verdammt lang auf. Ich hab hier Code vormier liegen an dem ich 3 Wochen arbeite. Das selbe hätte ich in Delphi warscheinlich in max. 1 Woche geschrieben. Andauernd hängt man an solchen Mist... Wenn man sich von seiner Muttersprache entfernt, kostet das gleich massiv Zeit.

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

Gibt's da eigentlich keine Fehler wegen impliziter Double=> Float Konvertierung?

Ich habe auch schon tolle Erfahrungen mit C++ gemacht und es ist immer wieder ein Vergnügen wenn so was ansteht. Ich muß an der Uni auch mit C++, gcc und qt OpenGL programmieren. Geschrieben wird der ganze Quelltext dann mit kwrite oder kate (Notepad mit Syntaxhervorhebung). Ein Debugger ist angeblich nicht nötig, weil man damit sowieso keine Fehler in Grafikalgorithmen finden kann. Das ganze hält tatsächlich enorm auf. Habe für eine einfache Bezier Kurve mehrere Stunden benötigt. Hat man Änderungen an der Form durchgeführt muß qt erstmal wieder jede Menge Code generieren. Hat man ein ";" vergessen, läuft der gcc erstmal eine gewisse Zeit und spuckt dann 3-4 Bildschirmseiten Fehlermeldungen aus, aus denen man sich dann die Ursache zusammenreimen kann. Ja so macht es richtig Spaß mit C++ zu arbeiten, wenn man die Hälfte der Zeit warten muß. Bei Delphi läuft das Programm schon bevor man die F9 Taste losgelassen hat. Aber nur beim Delphi für Win32, an das neue will ich gar nicht denken.

Nun eine passable IDE hab ich: Eclipse mit CDT.

Da is das Debuggen und Fehlerfinden schonmal etwas angenehmer. Was aber enorm nervt sind diese ewigen Compilierzeiten. Wenn ich in meiner Klassenhierarchie ganz unten was ändere dann kompiliert der schonmal 30 Sekunden... Da kann man dann schonmal Kaffe machen gehn...

In der Beziehung muss man C++ entwickler richtig bewundern...Die müssen ganz schön Gedult haben. (Aber wers nicht anders kennt, wird auch nicht wissen, dass man in 2 Sec ein 50000 Zeilen Projekt compilieren kann... )

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

Das ist aber nicht so. Delphi kann so etwas nicht. Es sein denn 99% der Units sind bereits vorkompileirt (DCU-s)...
C++ an sich ist nicht langsam zu kompieleiren, sondern es liegt meistens an der IDE (siehe Borland Builder), die die Sprache verwaltet.
Delphi compiler ist SinglePass compiler, c/c++ muss man mit multipass kompilieren.
Und es gibt ein kleines aber feines Unterschied was die änderungen im c/c++ code betrifft. Es ist nicht das Selbe etwas in einer *.h und einer *.c /*.cpp Datei zu ändern und dann zu kompielieren...Zweite geht schneller.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Irgendjemand hatte hier doch mal ein Bsp Programm mit 1.000.000 Zeilen gemacht und das wurde in 10-20 Sekunden kompiliert.
Warum soll C++ zwingend Multipass sein? Da gibt's doch eigentlich keinen Grund, auch wenn der gcc tatsächlich mehrere Pass benutzt. Aber auch ohne IDE direkt von der Kommandozeile ist der gcc erschreckend langsam

Nun Delphi kann eine Datei auch nicht in einem einzigen Schritt kompilieren, was an den Abhängigkeiten zwischen Units liegt und deshalb auch Delphi Dateien zwei Runden durch den Compiler machen - nur ist das bei Delphi so, daß der erste gang durch das Interface, der zweite durch die implementation Teil geht. Und weil die Sprache gut durchdacht ist, ist bei jedem Schritt sehr klar, welche Symbole folgen werden, weshalb das durchkompilieren sehr flott geht. Ob Delphi beim neuübersetzen von 50.000 nun 2 oder 8 Sekunden braucht reists dann nicht mehr raus - so flott wird ein echter C++ Compiler auf der selben Maschiene zwecks Sprache kaum werden. Aber über die Vorteile von C/++ und Delphi zu streiten ist hier nicht der richtige ort und weil ich weiß wie das ausgeht.... solltet ihr aufhören darüber zu diskutieren. Jedenfalls nicht in diesem unpassenden Thread. Ist vielleicht besser in nem IRC, dann gibts zwar im schlimmsten Fall logs vom gezanke, aber am Ende ist es nicht hier verewigt.

Zu den casts in C++: das ist gewollt. Wer C-Programm kennt, weis wie gerne implizite Casts gemacht wurden und was für eine große Fehlerquelle das ist. Daher muss man Casts in C++ explizit angeben. Das macht Arbeit, und was Arbeit macht da denkt man drüber nach. Und genau das ist gewollt, um so Fehler zu vermeiden.

ach und zu den Compile-Zeiten: ich kenne die Eclipse-IDE nicht. Unter Visual C++ gibts vorkompilierte Header, kannst ja schauen obs da auch sowas gibt.