spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Die Geschwindigkeit solltest du schon erreichen. Es gibt halt nur ein festes Qualitätslimit und die Verwendung von OpenGL scheint mir unnötig.

OpenGL scheint mir dafür nicht gut geeignet, weil es mit sehr vielen Funktionen und Probleme daherkommt, den du eigentlich nicht brauchst. Auch GPU Beschleunigung ist nicht notwendig und ist halte es auch für fragwürdig, wann und ob das überhaupt im enorm unterteilten Immediate Mode schneller ist als eine einfache Operation auf der CPU.

Ich würde an deiner Stelle lieber auf der CPU bleiben. Du gehst einfach parallel jeden Bildpunkt des Zielbildes durch und überprüfst erstmal, in welchen Viereck er nun liegt und wendest dann auf die Formel darauf an um herauszufinden welcher Bildpunkt des Quellbildes dort liegt. Den kannst du dann einfach nachschlagen. Für einfaches Antialiasing und Texturfilterung braucht man auch einfach nur mehrere Samples zu nehmen.

Als Vorteile sehe ich, dass du nicht von der GPU und den Grafiktreiber und dessen Limits bezüglich Framebuffer, Texturgröße, Shader (für exakte Lösung) etc. abhänig bist und in C# bleiben kannst. Außerdem müssen nicht alle Daten zur oder von der GPU kopiert werden.

So'n Quatsch. Mit z.B. SFML hat er überhaupt keine Probleme oder unnötig viele Funktionen. Das ist in wenigen Zeilen geschrieben und auch wieder als Bild exportiert. Niemand hat gesagt, dass er alles von Hand schreiben sollte und muss. Wie oft er da was von CPU zur GPU und zurück kopiert, ist total egal, wenn er damit noch immer um den Faktor 100 schneller ist.

SFML oder nicht, ist doch kein Unterschied. Und er hat unnötig viele Abhänigkeiten. SFML.Net braucht SFML. SFML erfordert unnötiges Fenster. Und SFML braucht OpenGL. Oder in seinem Fall eben statt OpenGL SharpGL. Zu den Problemen gibt es zum Beispiel, dass ein entsprechender Grafikkartentreiber installiert sein muss. Außerdem benötigt er doch gar keine OpenGL Features außer triviale Rasterisierung. Das ist doch in ein paar Zeilen C# geschrieben.

Das ist ein Spieleprogrammiererforum. Das ist es nicht verwunderlich, dass hier gleich OpenGL und SFML empfohlen wird. Dort ist das richtige Tool. Für Image Processing und ganz besonders die hier benötigte Transformation, ist OpenGL aber nicht das richtige Tool und SFML, das Fenster und die Unterteilung einzurichten braucht vielleicht nur "wenige Zeilen", aber einfach über die Quellpixel auf der CPU zu iterieren und die Transformation direkt anzuwenden sind ebenfalls nur "wenige Zeilen". Mit dem Vorteil, dass es "Self Contained" ist.

Das es tatsächlich schneller ist steht auch nicht fest, wenn er das mit starker Unterteilung umsetzt. Die Zeit die für das Öffnen eines Contexts und den Datentransfer draufgeht, kann bei vielen Computern bzw. nicht groß genugen Bildern auch im Vergleich zu den einfachen Berechnungen sehr groß werden. Selbst wenn der Rest dann "100 mal" schneller läuft (und das ist ein wenig übertrieben), dann kann es immernoch langsamer sein.

GPGPU kann natürlich schneller sein. Aber es ist sehr gut möglich, dass es in seinem Fall bei der Umsetzung keinen Vorteil bringt.

Ja das bleibt so. Du müsstest es im Prinzip so häufig unterteilen (viele hunderte bis tausende) mal in beide Richtungen, bis der unverzerrte Bereich nur noch wenige Pixel groß ist und so nicht mehr auffällt. Und das ist eben der Punkt, an dem ich den Ansatz als falsch ansehe. Wenn du es jetzt unbedingt mit OpenGL machen willst, dann lässt sich das richtig nur mit einem Shader richtig machen. Ich habe ihn ja schon genug verlinkt, wie das geht. Allerdings bin ich eben nicht davon überzeugt, dass OpenGL hier überhaupt noch hilfreich ist.

Und dann sehe ich das eben so, dass OpenGL nicht gerade die kleinste und unproblematischte Abhänigkeit ist. Genauso wie ich nicht Boost einbinden würde, bloß weil ich irgendeine einzelne Funktion in Boost.Geometry brauche. Das sollte nicht falsch verstanden werden. Boost ist eine Spitzenbibliothek, aber für diesen hypotetischen Fall einfach nicht die richtige Wahl. Besonders nicht, wenn die gefragte Funktion (in diesem Fall einen Punkt Polygon Schnitttest) in 10 Zeilen selbst implementiert werden kann.

Der Grund warum dir OpenGL von vielen vorgeschlagen wurde ist, dass viele (auch ich) nicht an das Problem der Interpolation gedacht haben und dann normale texturierte Quads exakt wie dein Problem aussehen.

Zitat von »Spiele Programmierer«

SFML erfordert unnötiges Fenster.

Ach ja? Das is mir aber neu. RenderTextures haben ihren eigenen Context. Klar, ich kann den Käse von Hand schreiben inklusive der Samplings und große Freude haben, sobald ich eine feine Unterteilung der Verzerrungen wie über ein Gitter vornehme... oder ich nehme mir ein Framework und einen Shader für korrekte Quad-Verzerrung und bin alle Probleme in wenigen Zeilen Code los und das mit Realtime-Performance ohne die CPU zu belasten. Sicher, ja, das benötigt einen OpenGL Treiber. Vielleicht sollte man nochmal fragen wofür das ganze sein soll und ob die Anforderung an OpenGL ein Problem ist oder nicht und welche Performance er denn gern hätte.