Halli, Hallo mal wieder ,

Ich brauche in letzter Zeit häufig Rechtecke (Ortho-Modus); deshalb habe ich mir folgende Prozedur geschrieben, um ebensolche zu zeichnen



Die Farbe muss halt vorher gesetzt werden; aber das ist auch nicht das Problem. Obwohl ich meine Ansicht nicht skaliert habe (ein Pixel auf der Fläche entspricht also exakt einem Pixel), entstehen manchmal Fehler an den Eckpunkten (siehe Anlage). Das ist prinzipiell natürlich nicht all zu dramatisch; aber schließlich will ich hier ja auch was lernen .

Die Quads, die man auch noch sehen kann, sind prinzipiell genauso gezeichnet - und auch wenn ich alles größer mache, treten dort auch nie Fehler auf. Bei den Rechtecken gibt es auch nie Fehler, außer dass halt manchmal ein beliebiger Eckpunkt fehlt. Muss ich bei dem LineLoop irgendwo noch einen Pixel aufschlagen - und warum?

Ogridi

zeichenreihenfolge bedacht? kann es sein, daß der rahmen rechts oben vom gelben später gezeichnet wird? passen die tiefen, ecc..

Ja.. sieht für mich auch danach aus, dass das obere Rechteck drübergezeichnet wurde. Du könntest das testen, indem du für jedes Rechteck eine andere Farbe wählst. Dann siehst du vielleicht obs drübergezeichnet wurde. Wobei...hmmm...vielleicht auch nicht. Guck halt mal was zuerst gerendert wird.

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

öhm.. - sorry, hätt ich vielleicht gleich sagen sollen :

Das Schwarze ist der Hintergrund, also glClearColor, drübergezeichnet sind jetzt in regelmäßiger Reihenfolge Quads mit den komischen Bildchen und eben das gelbe Rechteck (noch darüber). Der Effekt tritt sogar in verschiedenen Zusammenhängen und Kontexten auf (s. zweites Beispiel). Dabei muss der Code doch ein exakt horizontal (bzw. vertikal) liegendes Rechteck ergeben, egal mit welchen Parametern man ihn füttert, oder?

Ach ja, und mir ist noch aufgefallen, dass die Fehler äußerst häufig rechts oben auftreten.

Wie gesagt: Wenn sich das Problem jetzt nicht lösen lässt, ist das kein Weltuntergang. Ich war nur überzeugt davon, dass man solche "Pixel"-Fehler vorhersagen kann und dass schlichtweg der Fehler im Code liegt.

Computer sind eigentlich deterministisch, und sollten somit vorhersagbar sein. Aber ne Idee hab ich auch nicht. Eventuell sind Rundingsfehler im Spiel die wiederum von verschiedenen Treibern anders behandelt werden. Hast dus mal mit nem anderen Rechner getestet?

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

Ah. Hätte jetzt auch darauf getippt, dass es übermalt wird. Aber so hätte ich meinen Beitrag ja doch abschicken können. Darüber sprechen wir noch mal.

Also hier noch mal was was ich heute morgen schon sagen wollte.

Bei Linien habe ich dieses Phänomen schon häufiger gesehen. Keine Ahnung wieso. Aber anscheinend geht er manchmal davon aus, dass die Linie nicht ganz bis zum Punkt gezeichnet werden soll sondern hört vorher auf. Bei der GDI ist das glaube ich auch so. Das macht die Sache aber nicht unbedingt besser. Schau dir mal diesen Screenshoot an. Das sind auch bloß Linien. Fällt dir etwas auf?

In deinem Fall kannst du einfach hergehen und vor den Zeichnen der Fläche eine gelbe Fläche zeichnen. Wenn du anschließend deine Fläche entweder mit angepasster Tiefenfunktion oder deaktiviertem Tiefentest drüberzeichnest bleibt nur das übrig was übrig bleiben soll. Und Flächen weisen an der Stelle keine lücken auf.

Andere Möglichkeit wäre eine Fläche bei der du den Füllmodus anpasst. Mit glPolygonMode. Allerdings arbeitet der auch nur mit Linien. Aber vielleicht arbeitet der anders. Ich würde aber eher immer auf die andere Methode plädieren, da du dort mehr Gestaltungsmöglichkeiten hast. Zum Beispiel könntest du auf das Quad auch eine Textur legen und dieses über das Andere blenden. Damit würde deine Selektion mit sehr einfachen Mitteln einen ganz anderen Eindruck bekommen.

Von einer Anpassung der Koordinaten halte ich nicht viel, da du nie weißt ob es einer nicht vielleicht doch richtig macht und dann sieht es bei dem bescheiden aus.

Und außerdem fällts doch kaum auf.

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

Seh ich auch so. Ging mir auch wie gesagt nur um grundsätzliche Fehler; wenn ich die GL richtig einsetze und die was falsch macht, soll mir das lange Recht sein .

Das mit dem glPolygonMode werd ich mal ausprobieren, Quads unter die vorhandenen zu zeichnen nützt mir leider nicht viel. Die Rechtecke brauche ich in vielerlei Hinsicht; der zweite Screenshot stamt beispielsweise von einer stark verkleinerten Version des ersten. Hier haben die Quads aber keine Zwischenräume und die Rechtecke können auch mitten durch ein Quad verlaufen.

Auf jeden Fall thx für die Aufklärung !

Ogridi


PS:


Wie viele? ^^

Ich könnte mir vorstellen das es am Linewidth liegt.
Kannt ja mal versuchen es auf 1 zu stellen und eventuell alle Linien einzeln Zeichnen.
Ich kenne sowas nicht obwohl ich auch ab und zu mit linien arbeite.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich hab jetzt nochmal alles durchprobiert: Sowohl glPolygonMode(GL_FRONT, GL_LINES), als auch glLineWidth(1) und glBegin(GL_LINES). Werd wohl damit leben müssen. Bei Gelegenheit probier ich's aber auch nochmal auf nem anderen Rechner aus.

Hi ...

Wenn das alles nicht klappt würd ich evtl statt der linien nen Quad zeichnen.
D.h. Gelbes Quad zeichnen, so groß wie der Umriss, und dann das richtige Quad dadrauf ...

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)

Hilft mir zwar in dem Beispiel oben, manchmal aber auch nicht; dann bin ich gerade darauf angewiesen, dass das Rechteck Quads in der Mitte teilt.

Mal ganz am Rande: Darf man fragen was du programmierst? Ein Spiel?

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

Eine Doom 3 Engine natürlich

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Sorry, ich hielt den Thread für abgeschlossen und hab deshalb nicht mehr reingeschaut .





Da ich mir nicht vorstellen kann, dass eine Doom 3 Engine in 2D geschrieben werden kann - nein . Aber Engine geht in die richtige Richtung. Ursprünglich sollten ich und ein paar Freunde von mir ein beliebiges Grafikprojekt für den Info-Unterricht schreiben. Wir haben uns damals für ein rundenbasiertes Basis-Strategiespiel entschieden (nur Einheiten, die auf einer Karte hin und her laufen können und bekriegen, wenn sie aufeinandertreffen). Nach einigem hin und her konnte ich sie davon überzeugen, dass das in 3D eh nix wird und somit haben "wir" (etwa gleichbedeutend mit "ich") dann begonnen, einen 2D-Ediitor zu schreiben.

Die Grundfunktionen stehen auch eigentlich schon; ich bin jetzt vor allem noch dabei, das ganze etwas benutzerfreundlicher zu machen (mehrere Einheiten auf einmal selektieren, Tastatursteuerung, Formulardesign etwas aufbessern und sowas). - Naja und dann fehlt noch ne Speichern / Laden - Funktion, die ich aber absichtlich hinausgezögert habe, um mir Arbeit zu sparen (http://www.delphigl.com/forum/viewtopic.php?t=5342).

Zugegeben komm ich atm nicht mehr so schnell voran wie am Anfang; das liegt aber eher daran, dass ich jetzt wieder Halbzeit-Schüler bin, als dass mir die Lust daran vergangen wäre. Ich bin mir ziemlich sicher, dass ich zu mindest den Editor noch komplett fertig kriegen werde. - Und damit wär ich durchaus sehr zufrieden - nur um Verwechslungen mit den im Tutorial http://wiki.delphigl.com/index.php/Tutorial_quickstart genannten Doom3 - Kandidaten auszuschließen. - Ach ja - und auf über ein Jahr ist das Projekt sowieso auch nicht ausgelegt .

Ogridi