Andorra 2D [Ver. 0.4.5.1, 31.12.08]

[xZise]

Hmmm also ich habe jetzt die "alte" Methode entfernt und sie neu deklariert:

Delphi-Quellcode:

function TAdVCLFormat.AssignTo(ABitmap: TAdBitmap;
  AGraphic: TObject): boolean;
var
  pc1, pc2: PCardinal;
  x, y: integer;
  bmp: TBitmap;
begin
  bmp := TBitmap.Create;
  try
    bmp.PixelFormat := pf32Bit;
    bmp.Width := ABitmap.Width;
    bmp.Height := ABitmap.Height;
// Ab hier habe ich das aus deinen Codesniplseln kopiert
    for y := 0 to bmp.Height - 1 do
    begin
      pc1 := bmp.Scanline[y];
      pc2 := ABitmap.Scanline(y);
      for x := 0 to bmp.Width - 1 do
      begin
        pc1^ := pc2^; //Inhalt ABitmap, Alpha $FF
        inc(pc1);
        inc(pc2);
      end;
    end;
// Bis hier
  finally
    bmp.free;
  end;
end;

Ergebnis war jedes mal eine weiße Fläche. Ich müsste auch bmp der Grafik zuweisen. Jetzt bekomme ich vernünftige Ergebnisse:

1. Blaues Bitmap durchgehend (ohne Transparenzen)
2. Weißes Bitmap (ohne Transprenzen wahrscheinlich (Hg war weiß))
3. Inhalt der Grafik, Bläulich, "Hintergrund" ist schwarz
4. Inhalt der Grafik, "Hintergrund" ist schwarz

Hier ist mein Workaround für weiße Hintergrundflächen:

Delphi-Quellcode:

function TAdVCLFormat.AssignTo(ABitmap: TAdBitmap;
  AGraphic: TObject): boolean;
var
  bmp: TBitmap;
  y, x: integer;             var i : Integer;

  LineIn, LineOut : PCardinal;
  LineInRec : LongRec;
begin
  result := true;

  bmp := TBitmap.Create;
  try
    bmp.PixelFormat := pf32Bit;
    bmp.Width := ABitmap.Width;
    bmp.Height := ABitmap.Height;

    for y := 0 to bmp.Height - 1 do
    begin
      LineIn := ABitmap.ScanLine(y);
      LineOut := bmp.ScanLine[y];
      for x := 0 to bmp.Width - 1 do
      begin
        LineInRec.Bytes[0] := 255 - LineIn^ shr 24;
        LineInRec.Bytes[1] := (LineIn^ shr 16) and $00FF;
        LineInRec.Bytes[2] := (LineIn^ shr 8) and $0000FF;
        LineInRec.Bytes[3] := LineIn^ and $000000FF;

        for i := 1 to 3 do
        begin
          if LineInRec.Bytes[0] < 255 - LineInRec.Bytes[i] then
            LineInRec.Bytes[i] := LineInRec.Bytes[0] + LineInRec.Bytes[i]
          else
            LineInRec.Bytes[i] := $FF;
        end;

        LineOut^ := $FF000000 or (LineInRec.Bytes[1] shl 16) or (LineInRec.Bytes[2] shl 8) or (LineInRec.Bytes[3]);

        Inc(LineIn);
        Inc(LineOut);
      end;
    end;

    TGraphic(AGraphic).Assign(bmp);
  finally
    bmp.Free;
  end;
end;

Wie man sieht längst nicht so performat wie dein Code, aber damit bekomme ich immerhin Transparenz.

Übrigens gibt es eine Möglichkeit bei deinem Canvas auch Kreis/Rechtecksringe zu zeichnen? Und wie sieht es mit abgerundeten Rechtecken aus?

Btw, wenn du möchtest könntest du noch folgende Funktionen implementieren (Dürfte es alle nicht geben):

Delphi-Quellcode:

function AdPoint(const APoint : TPoint) : TAdPoint; overload;
begin
  Result := AdPoint(APoint.X, APoint.Y);
end;

function AdRect(ACorner1, ACorner2 : TAdPoint; const APreventFlipOver : Boolean = true) : TAdRect; overload;
var
  CornerBuffer : TAdPoint;
begin
  if APreventFlipOver then
  begin
    if (ACorner1.X > ACorner2.X) or (ACorner1.Y > ACorner2.Y) then
    begin
      CornerBuffer := ACorner1;
      ACorner1 := ACorner2;
      ACorner2 := CornerBuffer;
    end;
  end;
  Result := AdRect(ACorner1.X, ACorner1.Y, ACorner2.X, ACorner2.Y);
end;

function AdRect(ACorner1, ACorner2 : TPoint; const APreventFlipOver : Boolean = true) : TAdRect; overload;
begin
  Result := AdRect(AdPoint(ACorner1), AdPoint(ACorner2), APreventFlipOver)
end;

MfG
xZise

[xZise]

Was ist los :) Ist so still geworden, aber auch mit Workaround sieht die Transparenz schrecklich aus.

MfG
xZise

[igel457]

Hallo,

ich habe deinen letzten Post ohne das Edit nur gelesen, deshalb wurde ich nicht darauf aufmerksam. Deinen "Workaround" muss ich mir mal genauer anschauen.

Deine AdPoint-Funktion lässt sich auch viel effizienter ohne Funktion schreiben (übrigens geht das genauso mit TAdRect):

Delphi-Quellcode:

var
  p1: TAdPoint;
  p2: TPoint;
begin
  p1 := PAdPoint(@p2)^;
end;

Mit der Transparenz schaue ich mal - wenn mich nicht alles täuscht, habe ich die Transparenzbehandlung ausgebaut: In den älteren Versionen habe ich das in das gegebene Bitmap übergeblendet. Ich dachte damals (als ich es ausgebaut habe) so was wie: "Wenn die VCL schon pf32Bit anbietet, dann verwende ich dass doch auch - da bekommt der Benutzer seine Daten auch so, wie sie sein sollen und nicht verfälscht." - Was auch stimmt, denn schließlich stehen die Daten 1 zu 1, so wie sie sein sollen im Speicher des Bitmaps. Ich denke hier sollte eher die VCL und nicht Andorra 2D gefixt werden. Du kannst ja mal Borland Inprise CodeGear Emba-irgendwas deswegen fragen ;-).

Das mit dem APreventFlip over baue ich lieber direkt ins Canvas ein. Wenn du Code für abgerundete Ecken schreibst, übernehme ich den auch gerne. Schau dir mal die Unit TAdCanvas an - du musst einfach nur eine Klasse von TAdCanvasObject ableiten und 3 oder 4 Funktionen implementieren. Aber achte darauf, dass die Texturkoordinaten, Farbverläufe und Normalen richtig gesetzt werden und du nirgendst Speicherüberläufe einbaust. Und dann musst du nur noch eine Funktion zu TAdCanvas hinzufügen, die dein Objekt erzeugt und auf die aktuelle DisplayList pusht. Also ganz einfach... :-)

Danke für die Vorschläge,
Andreas

[3_of_8]

Tja, aber wie wir wissen können Bugfixes von größeren Softwareunternehmen eine Zeit dauern. Embarcadero heißen die Jungs übrigens momentan, aber wenn mans genau wissen will, sollte man das jeden Tag überprüfen, so oft wie sich das ändert. :mrgreen:

[xZise]

Zitat:

Zitat von igel457

ich habe deinen letzten Post ohne das Edit nur gelesen, deshalb wurde ich nicht darauf aufmerksam. Deinen "Workaround" muss ich mir mal genauer anschauen.

Naja das ist das Problem mit den Edits ;)

Zitat:

Zitat von igel457

Deine AdPoint-Funktion lässt sich auch viel effizienter ohne Funktion schreiben (übrigens geht das genauso mit TAdRect):

Delphi-Quellcode:

var
  p1: TAdPoint;
  p2: TPoint;
begin
  p1 := PAdPoint(@p2)^;
end;

Okay stimmt das sollte gehen ;)

Zitat:

Zitat von igel457

Mit der Transparenz schaue ich mal - wenn mich nicht alles täuscht, habe ich die Transparenzbehandlung ausgebaut: In den älteren Versionen habe ich das in das gegebene Bitmap übergeblendet. Ich dachte damals (als ich es ausgebaut habe) so was wie: "Wenn die VCL schon pf32Bit anbietet, dann verwende ich dass doch auch - da bekommt der Benutzer seine Daten auch so, wie sie sein sollen und nicht verfälscht." - Was auch stimmt, denn schließlich stehen die Daten 1 zu 1, so wie sie sein sollen im Speicher des Bitmaps. Ich denke hier sollte eher die VCL und nicht Andorra 2D gefixt werden. Du kannst ja mal Borland Inprise CodeGear Emba-irgendwas deswegen fragen ;-).

Tja das nervt mich auch, dass die Transparenzbehandlung nicht die beste ist. Wobei ich jetzt nicht weiß, wie das mit Delphi 2009 aussieht. Das soll ja endlich png-Dateien unterstützen.

Zitat:

Zitat von igel457

Das mit dem APreventFlip over baue ich lieber direkt ins Canvas ein.

Könntest du auch machen ;) und so schlecht ist die Idee gar nicht ;)

Zitat:

Zitat von igel457

Wenn du Code für abgerundete Ecken schreibst, übernehme ich den auch gerne. Schau dir mal die Unit TAdCanvas an - du musst einfach nur eine Klasse von TAdCanvasObject ableiten und 3 oder 4 Funktionen implementieren. Aber achte darauf, dass die Texturkoordinaten, Farbverläufe und Normalen richtig gesetzt werden und du nirgendst Speicherüberläufe einbaust. Und dann musst du nur noch eine Funktion zu TAdCanvas hinzufügen, die dein Objekt erzeugt und auf die aktuelle DisplayList pusht. Also ganz einfach... :-)

:stupid: Ich habs mir auch angeschaut aber das ist noch etwas "unverständlich", aber ich kann natürlich mal genauer nach gucken :)

Btw: Du wolltest doch mal wissen, was alles Andorra 2D verwendet? Da könntest du auch den DrawBall Editor drauf setzen!

Und eine andere Frage: Ist es möglich ein "Screenshot" davon zu erstellen?

MfG
xZise

[Florian H]

Grade gesehen: Könntest du bitte bei der Beschreibung von DrawBall auf der Andorra-HP ( http://andorra.sourceforge.net/index...ction=projects ) das "your balls" irgendwie ändern?
Durch das "your" ist das eigentlich schon ziemlich eindeutig als 'deine Eier' zu verstehen :mrgreen:

[igel457]

Uuups :oops:

Ok, jetzt sind es "Murmeln", ohne "your"... Aber vorher war es doch auch ganz lustig. ;-)

[3_of_8]

Here ye go, mate!

(Jemand mit einem englischen Lazarus könnte vielleicht noch mal überprüfen, ob die Menüpunkte so stimmen - wahrscheinlich nicht ganz, ich hab die einfach übersetzt und habe kein Lazarus, um es nachzuprüfen)

Zitat:

Andorra 2D - Compiling with Lazarus

Every beginning is difficult
To compile Andorra 2D with Lazarus, some particular issues have to be attended. Once those are taken care of, nothing stands in the way to use Andorra 2D even in Linux. This tutorial requires a working version of Lazarus as well as some knowledge in using it. Therefore, if any problems should occur with Lazarus that are not directly related to Andorra 2D (such as "Lazarus complains that 'Unit Interfaces could not be found', what should I do?"), please do not address them to me. Honest as I am, I have to admit I have not been working with Lazarus a lot myself, so if you have any more errors or suggestions for improvements, do not hesitate to inform me of them.


Compiling the plugin
The first difficulty to overcome is the fact that plugin DLLs compiled with Delphi are not compatible with Lazarus, which is quite logical as the internal Delphi compiler and the Free Pascal Compiler (which is used by Lazarus) are two different programmes, which were developed independently from one another. As a consequence of this, the class structure created by Free Pascal has become incompatible to Delphi's, but Andorra 2D exchanges objects between the library and the host application, which inevitably results in access violations.
We avoid this problem simply by recompiling the plugin library with Lazarus. For this, we open the file "AndorraOGL.lpi" in the directory "src/dll/opengl/" with Lazarus. However, before we can simply compile this file, we have to set up the search paths and the output directories accordingly.
To do this, we enter the path to the OpenGL header and the path to the Andorra 2D surce files via "Project->Compiler settings->Paths->Other unit files->...". If there should be any problems with unit files that cannot be found, just adding the "path templates" can help. Especially in Linux Andorra 2D only wanted to compile with those.
http://andorra.sourceforge.net/tutots/lazarus/img1.png
Apart from this, "../../dcu/" should be entered in "unit output path" in the paths dialogue and "../../../bin/" in "Project->Project settings->Target file name". Now we can compile the library with a click on "Start->Recompile all". If you are lucky enough to get the message "Project 'AndorraOGLLaz' built successfully. ;)", you should also make sure that the plugin was really recompiled. FOr this, take a look at the target directory and check the change date of "AndorraOGLLaz.dll".
As you may have noticed, the file name of the Lazarus DLL differs from that of the Delphi DLL to avoid confusion.
If everything went well until now, there is not much in the way of taking a trip to the world of Andorra 2D with the help of Lazarus now.


Our Lazarus Andorra 2D project
Now we want to create a simple Andorra 2D project with Lazarus. For that, we create a new "Application" project with "File->New" and add the Andorra 2D search path just like we did when compiling the OpenGL plugin. Also, it might be necessary to add the package "LazOpenGLContext" to your project when using another widget set than "Win32/Win64". (in Linux, for example)
http://andorra.sourceforge.net/tutots/lazarus/img2.png


About windows systems and device contexts
This necessity has the following background: When using the normal Windows widget set, Andorra 2D can also forward a handle (the inventory number of our window, in a manner of speaking) to the plugin library. After that, the plugin handles creating the according device context itself. (Which is done with a few lines in Windows) This is the area our graphics card or the used window graphics system can draw on. However, the device context has to be managed by the window system in use. In Linux, a multitude of window systems exists. (some of which can be selected as a widget set in Lazarus) Now the plugin would need to have a context creation routine for each of these systems, which would of course be an enormous effort. Luckily, the busy developers of Lazarus have thought of something for that, too: The component "TOpenGLControl", which creates a device context adapted to our selected window system and operating system for our application, which the plugin can draw on directly. Alternative windows frameworks, such as the GLFW framework work the same way. There is more information about this in the tutorial "About the Andorra 2D window frameworks".


Some code...
Now we just need some code to test Andorra 2D with Lazarus:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  AdDraw := TAdDraw.Create(self);
  AdDraw.DllName := 'AndorraOGLLaz.dll';
  Application.OnIdle := @Idle;
  AdDraw.Initialize;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  AdDraw.Free;
end;

procedure TForm1.Idle(Sender: TObject; var Done:boolean);
begin
  AdDraw.ClearSurface(0);
  AdDraw.BeginScene;
  with AdDraw.Canvas do
  begin
    Font := AdDraw.Fonts.GenerateFont('Arial', 24, []);
    TextOut(0,0,'Andorra 2D...');
    Font := AdDraw.Fonts.GenerateFont('Arial', 10, []);
    TextOut(0,30,'...works with Lazarus too');
  end;
  AdDraw.EndScene;
  AdDraw.Flip;
end;

To prevent problems, it has proven useful to replace the line

Delphi-Quellcode:

{$mode objfpc}{$H+}

at the beginning of the unit with this one:

Delphi-Quellcode:

{$MODE DELPHI}

http://andorra.sourceforge.net/tutots/lazarus/img3.png

Copyright and licence
(c) by Andreas Stöckel, February 2008

The content of this tutorial subjects to the GNU Licence for Free Documentation.

[xZise]

Wow .... Mal eben ein abgerundetes Rechteck zu zeichnen ist nicht ohne, wenn ich mir den Code des Rechtecks anschaue. Also ein Großteil habe ich verstanden, wobei ich bei procedure TAdCanvasQuadObject.Generate; noch nicht so den Durchblick habe :D

By the way:

Zitat:

Zitat von igel457

[...]du nirgendst Speicherüberläufe einbaust.[...]

Kreis ohne Füllung -> IntegerÜberlauf :stupid:

Und eine Frage bei dem Kreis:
Die Anzahl der Schritte sind ja: 2 * PI * r * (0,1/(0,01 * r))
Wenn mich nicht alles täuscht lässt sich das vereinfachen:
2 * PI * r * ((1/10)/(1/100)) * (1/r) | Mit dem Kerwert malnehmen
2 * PI * r * (100/10) * (1/r)
2 * PI * r/r * 10
2 * PI * 10
20 * PI

Siehe TAdCanvasEllipseObject.Generate:

Delphi-Quellcode:

steps := round(Pi * 2 * ar * (0.1/(ar*0.01)));

Wozu so kompliziert :) Abgesehen davon wird der Kreis bei größerem Radius immer schlechter, da es immer 63 Ecken sind.

Übrigens wie kann es sein, dass ein Kreis mit der SimpleDemo gezeichnet kein IntegerÜberlauf verursacht, während er in meinem Editor (komischerweise seit kurzem) einen solchen verursacht?

Ich habe mein WorkAround verbessert, da vorher es zu Integerüberläufen kam.

MfG
xZise

[Codewalker]

Warum ist das Property Name einer TAdImageList noch ein AnsiString, während alles andere ein String ist. Das könnte unter Delphi 2009 doch ein Problem geben, oder irre ich mich?