Andorra 2D [Ver. 0.4.5.1, 31.12.08]

[igel457]

So, ich habe mal noch ein paar kleine Änderungen an Andorra 2D gemacht: Zum einen können in der neuen CVS Version alle in Andorra 2D registrierten Grafikformate automatisch auch mit der VCL geladen werden (wer das nicht möchte muss den DO_NOT_INCLUDE_STD_FORMATS Compilerschalter aktivieren). Zudem habe ich den Bug im OpenGL-Plugin behoben, der verhinderte, das Andorra 2D auf älterer Hardware lief.

[Multisaft2005]

Hi
Ich verfolge die Entwicklung der Engine jetzt schon länger und wollte mich auch mal äußern.
Also erstmal muss ich sagen, das das wirklich eine ganz großartige Leistung ist und wirklich
ein Lückenfüller in Delphi.
Was ich anmerken wollte, ist das mich eine Kleinigkeit im Partikel-Editor stört.
Und zwar der Punkt, das bei Add Color die Farbe immer ganz hinten eingefügt wird und nicht
nach der ausgewählten Farbe.
Ich habe mir deshalb da eine kleine Codezeile eingefügt.

Code:

Saved := false;
AdPartSys.Colors.Add(Ad_ARGB(255, 255, 255, 255));
AdPartSys.Colors.Move(AdPartSys.Colors.Count-1,lb_Colors.ItemIndex+1); //Hinter den markierten Eintrag schieben
UpdateColorListBox;
UpdateStatusbar;

Ich weiss nicht ob andere das auch als störend empfinden, aber ich fände es gut, wenn
das vielleicht implementiert würde, oder zumindest die Möglichkeit gegeben würde
eben nicht nur die Farbe am Ende einzufügen.

Mfg
Multisaft

[igel457]

Hallo,
vielen Dank für das Lob, den Partikeleditor habe ich entsprechend verbessert - im CVS-Repository ist die entsprechende Version. Ich habe mal noch einen kleinen Screenshot angehängt.

[mimi]

Gibt es die Editoren(z.b. Image oder auch andere) auch schon für Lazarus ?

[inherited]

Klar, der Imagelist-Editor zumindest sollte mit Lazarus unter Linux funktionieren. In der aktuellen Version sollten sogar die passenden Lazarus-Projektdateien beiliegen. Ich kann leider gerade nicht nachschauen, werde ich aber nachher nachholen.

[mimi]

Danke für die Information. Dann lohnt sich ja noch mal ein Tests.
Sind die anderen Editoren denn auch schon für Lazarus fertig ?

[Xeres]

Ich habe gestern herausgefunden, dass Andorra unter D2005 PE noch ein paar Bugs hat.

Zum einen Schlug die Inizialisierung von AdDraw immer fehl, wenn der WindowMode <> dmDefault war (das kam z.B. immer vor, wenn man AdSetup.execute verwendet hat). Desweiteren gab es immer beim frei setzen der AdDraw-Klasse eine Speicherzugriffverletzung.
Auch haben sich manche Demo's (z.B. Bounce) nach der Kompilierung unter D2005 unterschiedlich zu den fertig kompilierten Version (die mit ausgeliefert wurden) verhalten.

Mit Turbo Delphi Explorer treten die beschriebenen Fehler nicht auf.


P.S. eigentlich wollte ich die Fehlerbeschreibung im Sourceforge-Forum zu dem Andorra-Projekt reinschreiben (weil dieses Problem schon ein paar Leute in dem Forum gemeldet hatten und bisher keine Lösung gefunden wurde), allerdings ist das Forum z.Z. offline.

Gruß
Xeres

[igel457]

Die Frage ist, was die Unterschiede von Delphi 2005 zu Delphi 2006 sind. Auf jeden Fall ist der Memorymanager ein anderer (FastMM). Hast du auch die DLLs mit Delphi 2005 neu kompiliert?

[Xeres]

Ja habe ich. Hatte allerdings die Fehler nicht behoben.

Du kannst ja mal D2005 PE runterladen. Ist ja kostenlos.
Link dazu gibts hier: http://www.delphipraxis.net/delphi2005download.php

[igel457]

Ich habe Delphi 2005 PE installiert (glücklicherweise habe ich das auf CD Archiviert, sonst hätte ich es jetzt nochmal herunterladen müssen).

Ich kann deinen Fehler schon mal reproduzieren. Wenn ich irgendwelche Fortschritte erzielen sollte, melde ich mich nochmal.

[igel457]

Ok, habs - ersetze die AdVCLComponentWindow.TAdVCLComponentWindow.SetupDi splay durch folgende Prozedur:

Delphi-Quellcode:

procedure TAdVCLComponentWindow.SetupDisplay(AProps: TAdDisplayProperties);
var
  form: TForm;
begin
  if (FControl is TForm) then
    form := TForm(FControl)
  else
    form := nil;

  if form <> nil then
  begin
    form.Color := 0;
    form.BorderIcons := [biSystemMenu];
    form.Caption := Title;

    if AProps.Mode = dmWindowed then
    begin
      form.BorderStyle := bsSingle;
      form.ClientWidth := AProps.Width;
      form.ClientHeight := AProps.Height;
      form.Top := (Screen.Height - AProps.Height) div 2;
      form.Left := (Screen.Width - AProps.Width) div 2;
    end else
    if (AProps.Mode = dmScreenRes) or (AProps.Mode = dmFullscreen) then
    begin
      if AProps.Mode = dmFullScreen then
      begin
        ChangeResolution(AProps.Width, AProps.Height, ord(AProps.BitDepth));
      end;
      form.BorderStyle := bsNone;
      form.Width := Screen.Width;
      form.Height := Screen.Height;
      form.Top := 0;
      form.Left := 0;
    end;

    //Actualize handle - it may have changed because of the changes in form.BorderStyle
    //and form.BorderIcons.
    //This only applies to Delphi 2005 and earlier
    FHandle := form.Handle;
  end;
end;

Man beachte den letzten Kommentar - ist also ein Bug in der VCL.

[Xeres]

Danke für den Bugfix.

Hier noch eine Frage:
Bei meinem Projekt benötige ich 2 SpriteEngine's. Nun möchte ich einen Pixel-genauen Collisionstest machen.
Ist dies möglich?
Alternativ wäre eine Funktion wie GetSpriteAt, aber Pixel-genau das was ich suche.

Ist dies bzw. wird dies möglich sein?

[igel457]

Schau dir einfach die "PixelCheck" Demo an. Allerdings benötigt meine aktuelle Methode eine relativ neue, DirectX 9 kompatible Grafikkarte, da die Kollisionen dort berechnet werden.
Alternativ kannst du natürlich eine einfache Kollisionsmap im Speicher halten und damit auf Kollision prüfen.

[Xeres]

Die Demo habe ich mir bereits angeschaut und auch anhand dieser Demo versucht mein Fall-Beispiel zu lösen. Allerdings ohne Erfolg.

Ich versuche mal mein Problem etwas deutlicher, anhand der PixelCheck-Demo, zu beschreiben: Ich habe die PixelCheck-Demo um eine 2te SpriteEngine erweitert. Die 2te SpriteEngine beinhaltet nur den Cursor als Sprite. Ab diesem Zeitpunkt funktioniert der PixelCheck nicht mehr. Hast du eine Idee, wie man dies dann lösen könnte?


Zu deinem 2ten Tip mit einer Kollisionsmap im Speicher:
Hast du mir hierfür einen Link, der beschreibt, wie man an so etwas ran geht?



Gruß
Xeres

[igel457]

Reserviere dir ausreichend Speicher und schreibe dein Bitmap herein:

Delphi-Quellcode:

var
  pmem: PByte;
  pb: PByte;
  rgba: PRGBA;
begin
  //Reservieren
  GetMem(pmem, Bitmap.Width * Bitmap.Height);

  //Daten hereinschreiben
  pb := PByte;
  rgba := Bitmap.Scanline;
  for y := 0 to Bitmap.Width - 1 do
  begin
    for x := 0 to Bitmap.Height - 1 do
    begin
      if rgba^ = Transparenzfarbe then
        pb^ := 0
      else
        pb^ := 255;
      inc(pb);
      inc(rgba);
    end;
  end;

  //Pixel überprüfen
  pb := pmem;
  inc(pb, meineXPos + meineYPos * Bitmap.Height);
  if pb^ = 255 then
   Kollision;
  

  //Freigeben
  FreeMem(pmem);
end;

[Ebil]

Ich bekomme fehlermeldungen bei D2009.

Zitat:

[DCC Warnung]
AdTypes.pas(504): W1050 WideChar in Set-Ausdrücken auf ByteChar verkürzt. Ziehen Sie die Verwendung der Funktion 'CharInSet' aus der Unit 'SysUtils' in Betracht.
[DCC Warnung] AdTypes.pas(506): W1050 WideChar in Set-Ausdrücken auf ByteChar verkürzt. Ziehen Sie die Verwendung der Funktion 'CharInSet' aus der Unit 'SysUtils' in Betracht.
[DCC Warnung] AdTypes.pas(513): W1057 Implizite String-Umwandlung von 'AnsiString' zu 'string'
[DCC Fehler] AdVCLComponentWindow.pas(181): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen
[DCC Fehler] AdVCLComponentWindow.pas(187): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen
[DCC Fehler] AdVCLComponentWindow.pas(190): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen
[DCC Fataler Fehler] AdComponentWindow.pas(29): F2063 Verwendete Unit 'AdVCLComponentWindow.pas' kann nicht compiliert werden

Warum entstehen die und wann wird das gefixt? Nen paar kann ich selbst lösen, andere wieder nicht. (Will mich ja nicht komplett reinarbeiten ^^)

gruß
Ebil

[3_of_8]

Ich schätze mal das liegt daran, dass sich in Delphi 2009 was Strings betrifft so einiges geändert hat.

[Ebil]

Naja das einzige problem ist imo eigentlich das hier:

Delphi-Quellcode:

EnumDisplaySettings(nil,i,DeviceMode)

Dort erscheint die fehlermeldung
[DCC Fehler] AdVCLComponentWindow.pas(181): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen

Keine ahnung was das meint =o

[inherited]

ich denke es liegt am TDeviceModeA.
Wie ist der bei dir definiert?
Ich vermute, dass mit einführung von Unicode der Typ eventuell neu definiert wurde und damit inkompatibel ist. Probier mal TDeviceMode ohne A oder mit W. Das sind aber reine spekulationen, da ich leider kein Delphi hier habe um zu schauen.

[igel457]

Welche Version hast du? Die aktuelle CVS Version? Bei der hatte ich mit Delphi 2009 keine Probleme. Ich kann das jetzt allerdings nicht mehr nachvollziehen, da meine Trial schon seit Monaten abgelaufen ist.

[Ebil]

Hi Igel, hab das ganze auch im Bug tracker gepostet nicht wundern :D.
Version ist: 12.0.3210.17555.
TDeviceModeA hab ich schon einfach ohne A gemacht, das ganze startet wenigstens, aber dann kommen error (und meine könnens nicht sein, ist eine der demos).

Ebil

[inherited]

Und was für Fehler?

[Ebil]

Erste Gelegenheit für Exception bei $7C812A7B. Exception-Klasse EAdLoadImage mit Meldung 'Error while loading the image. Compatible Andorra TAdImage header not found. Not a valid Andorra Image.'. Prozess PixelCheck.exe (2768)

[igel457]

Diese ganzen Fehler hatte ich auch (der von dir beschriebene Fehler rührt daher, dass ich Teile des Streams in einen String einlas, dessen Größe hat sich nun verdoppelt) , ich bin mir aber ziemlich sicher, das ich die behoben hatte.

Seltsam... Checke auf jeden Fall nochmal die Aktuelle CVS Version aus, sei sicher das du diese im Bibliothekspfad hast und erstelle die Anwendung komplett neu (Start->Programm erzeugen).

PS: Was soll das für eine Versionsnummer sein :gruebel:

PPS: Nachdem meine fünf Jahre alte Grafikkarte den geist aufgegeben hat, habe ich mir eine neue (samt neuem Mainboard etc.) gekauft (HD 4650). Jetzt habe ich die gleichen Probleme wie zum Beispiel Codewalker, dessen GUI z.B. total verstümmelt war.

PPPS: Scheint, als hätte ich das Grafikkartenproblem (bei mir zumindest) behoben...

[Ebil]

Das ist halt die versionsnummer die unter Hilfe->Info... steht.

Hab mir nochmal Andorra gedownloaded aber keine veränderungen.

Ebil

[Florian H]

Heyho,

was hälst du denn davon, den GUI-Komponenten noch eine Eigenschaft "rotation" hinzuzufügen, sodass man ihnen also einen Winkel übergeben kann und die dann entsprechend gedreht dargestellt werden. Gibts ja zwar unter der VCL nicht, aber das tolle an Andorra ist ja eigentlich, dass sowas wie Drehungen relativ einfach machbar sein sollte (klar, man muss dann gucken dass es richtig zusammengesetzt wird etc, aber die eigentliche Drehung ist in Andorra ja einfach).
Fände ich für die GUI von meinem DrawBall prima, weil da eine so strenge und geordnete GUI nicht passt (weils eben ein Spiel ist) und ich ungern 5 Button-Typen als neue Komponente mache, und denen jeweils einen leicht gedrehten Skin gebe :stupid:

schöne grüße

[igel457]

Die Idee ist zwar nicht schlecht, aber ehrlich gesagt liegt das GUI-System bei mir zunächst mal auf Eis, da ich es (momentan) nicht benötige. Generell muss das GUI-System noch umgebaut werden. So fehlt eine (richtige) Drag'n'Drop Unterstützung und die Eventweitergabe und das Skinsystem sind auch noch nicht so toll.

Um Elemente schief zu Zeichnen, muss der entsprechende Parameter an die Skinklasse weitergegeben werden und die Kollisionserkennung (da gibt es in TAdComponent eine Funktion) muss angepasst werden.

[Florian H]

Na gut, mal schauen was ich dann damit mache .. dauert bestimmt eh noch Monate, bis mein Ding mal fertig wird :o

[Shrek_III]

Hallo, auch von mir erstmal ein fettes Lob für die wirklich super Umsetzung!

Habe mir die Tutorials "reingepfiffen" und dann mal selbst losgelegt.
Dummerweise muss ich sehr groe Dateien laden.
BMP -> 16 Bit -> 96MB

Mit kleineren Dateien (bis 22 MB) funktioniert das Ganze tadellos, sobald sie aber eine bestimmte Größe überschritten haben, kommt bei mir eine Exception :( - zumindest denke ich, dass es etwas mit der Größe der Dateien zu tun hat.

Access violation at address 011F2D23 in module 'AndorraDX93DL.dll'. Write of address 07F16000.

Ich verwende einen VAIO VGN-AR11M mit eine NVIDIA GeForce Go 7600 128 MB.
Die Andorra Version ist die neuste verfügbare - gestern heruntergeladen.

Liegt es nun wirklich an der Grafikkarte des Notebooks oder gibt es sonst irgendwelche Tips?
Wenn die GraKa Schuld ist, gibt es eine Möglichkeit das Problem zu umgehen? - Bin mir nicht sicher, ob PNG wirklich die Lösung ist, schließlich ist es das RAM, welches meiner Meinung nach die Probleme macht... ...werde das aber morgen (bzw. heute) mal ausprobieren.

Danke schon mal im Voraus...

[Florian H]

Naja, 96MB allein für eine Textur klingt ziemlich viel, wenn die Graka nur 128MB hat .. wieso muss es denn so extrem riesig sein? Ggf kann man das ja auch unterteilen oder erstmal in niedrigerer Auflösung anzeigen.

[Shrek_III]

Zitat:

Zitat von Florian H

Naja, 96MB allein für eine Textur klingt ziemlich viel, wenn die Graka nur 128MB hat .. wieso muss es denn so extrem riesig sein? Ggf kann man das ja auch unterteilen oder erstmal in niedrigerer Auflösung anzeigen.

Es handeltsich hierbei um eine Karte, auf die ich verschiedene Sachen abbilden muss, da das Ganze zoombar ist (bzw. sein muss) kann ich hier nicht wirklich mit Tiles arbeiten. - Vielleicht gibt es ja eine Möglichkeit das System RAM zu nutzen anstatt alles in das schnellere Grafik-RAM zu kopieren.

[3_of_8]

Wieso kannst du nicht mit Tiles arbeiten? Du kannst ja für Zoomstufen, die weiter weg sind, niedriger aufgelöste Tile-Texturen verwenden und die höheren Zoomstufen bei Bedarf nachladen. Wenn du dabei immer versuchst, die Tiles der nächsten Zoomstufe des Bereichs, in dem sich der Benutzer momentan befindet, nachzuladen, dann dürfte es auch kaum Ladezeiten geben, wenn überhaupt. Aber natürlich kannst du auch die einfache Lösung mit einer einzige 96 MB großen Textur nehmen, das ist ja noch eine halbwegs akzeptable Größe.

[bigben37]

Was du auch noch versuchen könntest, wäre, dass du das Bild in JPG formatierst, da JPG kleiner ist als BMP.

[Shrek_III]

Zitat:

Zitat von 3_of_8

Aber natürlich kannst du auch die einfache Lösung mit einer einzige 96 MB großen Textur nehmen, das ist ja noch eine halbwegs akzeptable Größe.

Tja,das würde ich ja gerne, aber an der Umsetzung scheitert es...

weiß denn zufällig jemand, wie die Größen errechnet werden? - Im FAQ gibt es da einen kleinen Hinweis, aber halt nur für eine Größe - scheint als würde hier mit der normalen 2er Potenz gerechnet, kann das jemand bestätigen?

Zitat:

Question:
The textures I load in my program need more graphic memory than they should and my application slows down.
Answer:
Probably you're using non-power of two textures. Because most graphic boards don't support those, Andorra 2D scales them up to power of two textures. That means: If you have a texture with the size 520x260, it will be scaled up to 1024x512 - That's four times more memory than you actually wanted to use. It would give much more performance if you resize your image to 512x256.

Ich versuch jetzt jedenfalls mal meine Texturen in die Zweierpotenzen zu drücken...


edit1:
Ok, mit Verkleinerung der Textur aus 4096x4096 Pixel funktioniert es schon mal... ...erster Lichtblick :)

[3_of_8]

Ja, alle Texturenmaße werden auf die nächste Zweierpotenz erhöht, das ist technisch nicht anders möglich. Ich weiß jetzt nicht, welche Maße du vorher hattest, aber es kann durchaus sein, dass du damit weit über die 128 MB rausgekommen bist.

[inherited]

Zitat:

Zitat von bigben37

Was du auch noch versuchen könntest, wäre, dass du das Bild in JPG formatierst, da JPG kleiner ist als BMP.

Bitte nicht! Wenn dann Targa oder PNG

[bigben37]

Zitat:

Zitat von inherited

Zitat:

Zitat von bigben37

Was du auch noch versuchen könntest, wäre, dass du das Bild in JPG formatierst, da JPG kleiner ist als BMP.

Bitte nicht! Wenn dann Targa oder PNG

Wenn du meinst. Hauptsache nicht BMP ;-)

[Shrek_III]

Zitat:

Zitat von bigben37

Zitat:

Zitat von inherited

Zitat:

Zitat von bigben37

Was du auch noch versuchen könntest, wäre, dass du das Bild in JPG formatierst, da JPG kleiner ist als BMP.

Bitte nicht! Wenn dann Targa oder PNG

Wenn du meinst. Hauptsache nicht BMP ;-)

Ok, die Datei ist kleiner, aber im Arbeitsspeicher wird sie doch anders verarbeitet - sollte doch eigentlich egal sein, oder liege ich da total daneben?

[3_of_8]

Im Arbeitsspeicher und auch im VRAM liegt die Textur garantiert nicht als JPG, TGA oder was weiß ich vor, sondern als Bildrohdaten, also als Bitmap. (Was im Endeffekt wie BMP ohne die ganzen Metadaten ist) Eine Textur komprimiert im Speicher zu haben ist im besten Fall eine grauenhafte Performanceverschwendung und im schlimmsten Fall unmöglich, da man jedes mal, wenn man die Textur jedesmal zum Zeichnen teilweise dekomprimieren müsste. Bei 96 MB kannst du dir dann nach jedem Frame erstmal ne Pizza reinschieben, ein Bad einlassen oder zum Einkaufen fahren, bis der nächste kommt. :wink:

[Shrek_III]

Zitat:

Zitat von 3_of_8

Im Arbeitsspeicher und auch im VRAM liegt die Textur garantiert nicht als JPG, TGA oder was weiß ich vor, sondern als Bildrohdaten, also als Bitmap. (Was im Endeffekt wie BMP ohne die ganzen Metadaten ist)

Aha, also genauso wie ich es mir auch gedacht habe. - Danke für die Zustimmung soweit...

Zitat:

Zitat von 3_of_8

Eine Textur komprimiert im Speicher zu haben ist im besten Fall eine grauenhafte Performanceverschwendung und im schlimmsten Fall unmöglich, da man jedes mal, wenn man die Textur jedesmal zum Zeichnen teilweise dekomprimieren müsste.

Hab ich ja auch nicht vor :P

Zitat:

Zitat von 3_of_8

Bei 96 MB kannst du dir dann nach jedem Frame erstmal ne Pizza reinschieben, ein Bad einlassen oder zum Einkaufen fahren, bis der nächste kommt. :wink:

Naja, ich hab übrigens auch keinen C64, also 96 MB Texturen laufen unter DelphiX absolut flüssig...
...aber ich will ja nicht meckern, hab es jetzt durch Beschränkung der Textur auf max 4096 Pixel in eine Richtung auch erreicht, was ich erreichen wollte.

Danke für die vielen Antworten bis hierher.