In Programmen gibt es so eine Funktion aus einem einfachen Grund nicht - was du willst ist kein gedrehtes Bild, sondern ein zeilenweise verschobenes Bild.

(in Paint gibt es das glaube ich unter "Strecken/Zerren").

Der Punkt ist, dass ein Pixel in der Diagonale länger ist als in der Höhe oder Breite - drehst du ein Bild also müssen, damit die Größe beibehalten wird, Pixel zusammengestaucht werden.

Falls Paint nicht funktioniert kannst du das ganze im Game Maker machen mit draw_sprite_part - einfach in einer for-Schleife aufrufen und pro Durchlauf die in diesem Durchlauf gezeichnete Zeile um i versetzt zeichnen:



edit: Ok, dass du kein wirklich gedrehtes Bild haben wirst hast du selbst geschrieben, ich hatte diesen Post nur schon geschrieben bevor der Thread da war.

"Pixel-genau drehen" machen die Programme heutzutage eigentlich auch, das problem ist dort, dass es keine 0.5er pixel und kleiner gibt, weswegen gerundet wird und am ende sieht es... bei großen Bildern ok aus, bei kleinen ist das meist etwas schwerer.
Für solche sachen wurde übrigens das Anti-Alaising entwickelt wenn ich mich nicht täusche, lasse mich dennoch eines anderen belehren.

@Schattenphoenix
Du bist richtig belehrt. Anti-Aliasing bekämpft vor allem den "Treppenstufen-Effekt" bei diagonalen Linien und Flächen. Es ensteht die Illusion diese Pixeltreppchen seien diagonale Geraden. Und das ist also tatsächlich nötig, wenn man sauber einen Sprite drehen will, allerdings kann Anti-Aliasing verwischen, nicht aber verlorene Informationen wiederherstellen. Wie Du schon sagtest: Es gibt keine halben Pixel. Und eine gewiße Anzahl von Pixeln geht bei einer Spritedrehung unter 90°-Schritten verloren. Daher erscheinen geneigte bzw. gedrehte Sprites bei Anti-Aliasing unschärfer als ohne. Je nach AA-Stufe wird der Treppenstufeneffekt leicht verwischt oder nahezu gänzlich entfernt (geschieht aber im Zusammenspiel mit der Auflösung - selbst x8 AntiAliasing kann bei 320x240 Pixel den Effekt nicht völlig besetigen).

Und bei KHT ist ein Denkfehler drin. Mathematisch ist es eben nicht möglich Pixelgenau zu drehen. Man kann Zeilenweise verschieben, doch dadurch wird eben nur gezerrt. Um eine Drehung zu erzeugen, müssen die Zeilen jedoch auch ihre Vertikale Position ändern und dabei entstehen gewiße Konflikte - so müssten Pixel sich manchmal tatsächlich um einen halben Schritt im Raster bewegen, was nicht nötig ist, daher werden einige Pixel einfach entfernt oder so verschoben, dass eine Verfälschung im Sprite entsteht. Also: Pixelgenaue Drehung ist nicht bei allen Winkeln möglich. Wer versuchen würde manuell eine 45°-Drehung zu erzeugen, würde etwa feststellen, dass die Grafik dadurch verzerrt wird, da die ursprünglich horizontale Achse nun zu einer diagonalen Achse wird, der diagonale Minimal-Abstand zwischen den Pixel aber natürlich größer ist als der horizontale (wer mal versucht hat in einem Strategispiel auf quadratischen Feldern eine Formation zu schwenken wird definitiv verstehen, wovon ich rede - genaugenommen ist das sogar ein perfektes Beispiel um die Problematik beim Drehen in einem quadratischen Raster einzufangen).

Na denn. Für heute war das wohl genug an Klugschießerei.

Klugscheisserei oder Belehrung, wie man es nennen mag, kann ich nie genug haben, sofern ich auf dem Gebiet noch nicht belehrt bin

"Pixelgenau Drehen" könnte man evtl, wenn man eine andere Maßeinheit als Px benutzen würde, man brauch dementsprechend jedoch sämtliche umrechnungen von 1 Punkt zum anderen IN EINEM PIXEL um dann auf bsp. Milimeter umzurechnen und den Winkel zu verändern, jedoch kommt einem da wie immer das x = round(x) und y = round(y) in den Weg, welches bei einem Pixel auf z.B. 59.6 und einem auf 60.4 diese beiden pixel auf einen setzen würde.

Was lernen wir daraus? Pixel sind sch****e um Bilder zu drehen.

EDIT: @F4LL0UT: Es gibt doch auch verschiedene Anti-Alaising Filter-Typen, worin besteht da der Unterschied, bist du da informiert?

Puh... bin ich da informiert... hm... ja, jetzt wo Du mich fragst, bin ich es schon.

Full Screen Anti-Aliasing
Die meisten werden FSAA aus den Optionen verschiedener Computerspiele oder ihrer Grafikkarte kennen. FSAA ist dabei nur ein Prinzip, nicht ein bestimmtes Vorgehen bei Anti-Aliasing. FSAA bedeutet einzig, dass das gesamte dargestellte Bild mit Hilfe von Anti-Aliasing bearbeitet wird. Das bewährteste Verfahren für FSAA ist Supersampling.

Supersampling
Bei Supersampling wird das Bild auf einer viel höheren Auflösung gerendert als der Bildschirm erlaubt und wird dann verkleinert. Die zusätzlichen Informationen aus dem größeren Bild erlauben eine Farbwahl von Pixeln, die möglichst viele Informationen aus der "echten" Weilt (also der 3D-Engine) übernimmt (mit anderen Worten: die Pixel einen Mittelwert aus den umgebenden Pixeln bilden, die man wegen der geringen Auflösung nicht sehen kann), was sich je nach Auflösung und AA-Stufe in Unschärfe äußert. Der Tatsache entsprechend, dass die Grafikkarte ein sehr großes Bild rendern (welches wir garnicht erst zu sehen bekommen) und es im Nachhinein auch noch verkleinern muss, braucht Supersampling verhältnißmäßig viel Rechenkraft und Videospeicher. Übrigens kennen "Supersampling" auch alle User in diesem Forum, die manchmal ein Sprite erst in höherer Auflösung pixeln und dann zusammenstauchen. Das ist dann im Prinzip manuelles Supersampling - allerdings werden eben diese User auch wissen, dass es verschiedene Algorithmen zum "Stauchen" des Bildes gibt und somit "Supersampling" nicht immer gleich "Supersampling" sein muss, sondern es Variationen geben kann. Und um es mit einem Wort ganz einfach festzuhalten: Bei Supersampling handelt es sich um nichts anderes als "Scaling" in Echtzeit.

Multisampling oder Multipass Sampling
Dieser Prozess ist viel Leistungssparender als Supersampling. Wie bei Supersampling werden auch hier alle Pixel untersucht, allerdings zunächst nur auf ihre Tiefenwerte in der Engine. Stellt die Grafikkarte fest, bei welchen Pixelansammlungen Tiefenunterschiede bestehen, wird nur bei diesen Antialiasing angewandt. Das heißt also Multisampling bekämpft einzig und allein den Treppenstufeneffekt an den Kanten von 3D-Objekten, nicht jedoch den Polygoninhalt, was entsprechend Videospeicher spart - der Leistungsverbrauch variiert aber enstprechend der Szene, die dargestellt wird (da je nach Tiefenmuster auf dem zu bearbeitenden Bild verschieden viele Berechnungen gemacht werden müssen). Anscheinend stammt der Ausdruck "Multisampling" eigentlich nur aus OpenGL, wird heute aber allgemein angewandt, wenn von Anti-Aliasing Prozeduren die Rede ist, die nur bestimmte Bildausschnitte betreffen.

Adaptive Anti-Aliasing/Transparency Anti-Aliasing (ATI/Nvidia)
Interessanter Weise gibt es Quellen, bei denen von Adaptive Anti-Aliasing die Rede ist, während praktisch einfach Multisampling beschrieben wird. Guckt man jedoch auf Informationen der echten Kenner, nämlich der Grafikkartenhersteller selbst, stellt man fest, dass Adaptive Anti-Aliasing einfach das ATI-Gegenstück zum Transparency Anti-Aliasing von Nvidia ist (was mir auch erklärt, warum meine Geforce 8600 kein Adaptive Anti-Aliasing unterstützt, was meine Radeon 9800 noch konnte ;p). Beide Prozesse befassen sich also mit "transparenten" Texturen. Diese findet man in Spielen also bei Zäunen mit Drahtgitter, bei Bäumen, bei Graß und allen möglichen anderen durchsehbaren Objekten, die es sich garnicht lohnt als Polygonmodelle darzustellen. Also wird eine extra auf transparente Texturen ausgelegte und dafür optimierte Form von Multipass Sampling genommen. Ich denke niemand wird mich bitten hier jetzt in die Details zu gehen.

Jittering
Das ist ein primitiver und mittlerweile völlig veralteter Prozess für Full Screen Anti-Aliasing (nur aus OpenGL, wenn ich mich nicht irre), der praktisch garnicht mehr angewandt wird. Dabei wurden mehrere Bilder aus leicht verschiedenen Kamerapositionen aufgenommen und dann zu einem Bild gerendert, welches ungefähr den Mittelwert widerspiegelt. Dieses Vorgehen ist allerdings extrem leistungsfressend und hat keine Chance so gute Resultate zu erzielen, wie es mit Supersampling möglich ist.

Mipmapping
Das ist ein Beispiel für Antialiasing als Texturfilter, allerdings unterscheidet sich Mipmapping dadurch, dass Antialiasing im Voraus angewandt wird und nicht in Echtzeit. Mipmapping setzt nämlich voraus, dass jede Textur über mehrere Mipmaps verfügt, was nichts anderes ist als kleiner skalierte Formen der Originaltextur. Je nach Distanz und Winkel zu einer texturierten Fläche, wird eine andere Mipmap geladen. Es geht einfach darum, dass man davon ausgeht, dass man ein weit entferntes Objekt ohnehin nicht deutlich wahrnehmen kann und dieses daher keine klare Texturierung benötigt - also wird diese kleinere Mipmap genommen, die weniger Videospeicher benötigt. Resultat dieses Vorgehens ist allerdings, dass man häufig die Sprünge zwischen den verschiedenen Mipmaps sehen kann und die Texturierung eines Objekts plötzlich schärfer erscheint, wenn man sich im nähert.

Bilineare und Trilineare Texturfilter
Viele User und Spieler unterschätzen die Bedeutung von Texturfiltern und stellen sie entweder ganz niedrig oder ganz hoch, ohne genau zu wissen, was sie überhaupt sind. Texturfilter haben die Aufgabe Texturen in Echtzeit zu skalieren, sodass sie eine der Distanz und dem Winkel zum texturierten Objekt entsprechende Schärfe haben. Genaugenommen ist diese "Schärfe" eine Verwischung. Ziel der Filter ist es nämlich zu verhindern, dass wir zu nah an eine Textur tretend Pixelmatsch sehen und zu weit entfernt seiend eine unzureichende Menge an Texturinformationen sehen. Der bilineare und trilineare Filter unterscheiden sich nur im Algorithmus, der beim trilinearen Filter eine bessere Bildqualität erzielt. Wer sich mal davon überzeugen will, wie wichtig Texturfilter sind, kann mal bei 1024x768 im Softwaremodus Counter-Strike oder Half-Life spielen und anschließend bei gleicher Auflösung im OpenGL-Modus. Der Qualitätsunterschied ist enorm - so aber auch der stilistische.

Anisotropische Texturfilter
Die anisotropische Filterung entspricht den anderen Vorgehensweisen, nämlich durch Skalierung der Texturen in Anpassung an Winkel und Distanz zur texturierten Fläche. Anders als bei den anderen Filtern jedoch, werden hier eben auch "anisotropisch" Auflösungen unterstützt. So kann eine Text nicht nur von 256*256 auf 128*128 runter skaliert werden, sondern auch etwa auf 256*128, wenn wir etwa einen sehr hohen Blickwinkel entlang der Y-Achse einer Textur haben, aber einen geringen bei der X-Achse. Wie beim bilinearen und trilinearen Filter geschieht diese Berechnung hier in Echtzeit (anders als beim Mipmapping).

Temporal anti-aliasing
Das ist jetzt kein Prozess zum bisher besprochenen Anti-Aliasing, sondern eine völlig andere Sorte zu einer ganz anderen Form von Aliasing - nämlich zeitlichem. "Temporal aliasing" kennen wir alle etwa aus Rennspielen, wo die Reifen oder die Streifen auf der Straße sich so schnell bewegen, dass wir den Eindruck kriegen, sie würden sich in die falsche Richtung drehen/bewegen. Dem Problem entsprechend, dass unser Bildschirm nicht in der Lage ist alle Bilder pro Sekunde einzufangen (so wie er nicht in der Lage ist unendlich hohe Auflösungen zu rendern), muss die Grafikkarte mehrere zeitlich auseinander liegende Bilder nehmen (die wir wegen der Framebegrenzung garnicht alle sehen können) und zu einem einzelnen Bild gerendert. Dieses erscheint dadurch unscharf, dafür jedoch reichen die Informationen auf dem fertigen Bild, damit wir echte die Bewegungsrichtung deutlich wahrnehmen können. Im Prinzip resultiert das alles also im "Motion Blur".

So, ich denke das wäre dann erstmal alles.

Das war sehr interessant, auch wenn es nicht das war, was ich meinte.
Meine Frage bezog sich lediglich auf die Anti-Alaising-Algorythmen (Linear, Kubisch, etc.)

Vielleicht sollten wir ein Paar dieser Posts in nen neuen Thread verschieben, ich denke es würde noch andere Leute interessieren, welche hier nicht suchen würden.