Zur Transparenz: Bei mir funktioniert das wunderbar:
Delphi-Quellcode:
procedure TForm1.Button1Click(Sender: TObject);
begin
with Image1 do
begin
Canvas.Brush.Color := clBlue;
Canvas.FillRect(Rect(Point(0,0), Point(Width, Height)));
Canvas.Brush.Color := clNavy;
Canvas.FillRect(Rect(Point(20,20), Point(Width-20, Height-20)));
end;
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
with Image1 do
begin
// Picture.Bitmap.TransparentColor := clYellow;
Transparent := True;
Canvas.Brush.Color := clYellow;
Canvas.FillRect(Rect(Point(40,40), Point(Width-40, Height-40)));
end;
end;
In der Delphi-Hilfe steht aber auch: "Anmerkung: Transparent wirkt sich nur dann aus, wenn in der Eigenschaft Picture ein TBitmap-Objekt enthalten ist."
Zum Rundungsproblem: Solange die berechneten Werte die Parameter für die nächste Berechnung sind, werden sich die Rundungsfehler aufaddieren. Mit höherer Genauigkeit wird der Verformungseffekt nur verlangsamt. Warum nicht nur den Winkel ändern und mit den ursprüglichen Werten rechen, die das Dreieck beschreiben?
Zu den Matrizen :
Zitat von
Medium:
Zitat von
Panthrax:
Zitat von
Medium:
Zitat von
Panthrax:
Zitat von
shmia:
Man kann das Verschieben, Drehen und Zurückverschieben auch mit einer 2D-Matrix berechnen, (...)
Das geht nicht, (...)
Doch, können sie. (...)
Das glaube ich erst, wenn ich es sehe, (...)
Sei A (...)
Und dann kommt er mich ja doch mit einer 3x3-Matrix... aber ich seh' schon, wir haben uns da missverstanden. Und über die Vertauschbarkeit der Operationen hat ja auch nie jemand etwas anderes behauptet... Am Ende enthalten die Matrizen dieselben Formeln, denn sie enthalten immernoch die Variablen. Mit zunehmender Komplexität der Operationen werden die Berechnungen auch teurer, als bei der schrittweisen Berechnung, da mehr Multiplikationen erzeugt werden. Die schrittweise Berechnung kann man auch nach langer Zeit und ohne Dokumentation wieder intuitiv verstehen. Solange man auf die Matrizen verzichten kann... sollte man das tun.