Andorra 2D [Ver. 0.4.5.1, 31.12.08]

[xZise]

Hi,

Delphi-Quellcode:

procedure TFrPlayer.DoCollision(Sprite : TSprite; var Done: Boolean);
begin
  if (Sprite is TFrBackground) and ((Sprite as TFrBackground).BackgroundType = btWall) then
  begin
    Done := true;
    FColl := true;
  end else
  begin
    Done := false;
    FColl := false;
  end;
end;

function TFrPlayer.MovePlayer(const ADirection: TDirection;
  const ADistance: Extended): Boolean;
begin
  Result := True;

  case ADirection of
    dUp: Y := Y - ADistance;
    dDown: Y := Y + ADistance;
    dRight: X := X + ADistance;
    dLeft: X := X - ADistance;
  end;

  Collision;

  if FColl then
  begin
    case ADirection of
      dUp: Y := Y + ADistance;
      dDown: Y := Y - ADistance;
      dRight: X := X - ADistance;
      dLeft: X := X + ADistance;
    end;
  end;
end;

So wie beschrieben: Die Funktion DoCollison wird nicht aufgerufen ?! Sehr wohl aber Collision; o.O

[igel457]

Hallo,

das was Lareyne geschrieben hat, stimmt voll und ganz (Danke für die Erklärung, wenn du Lust hast, darfst du auch gerne ein Tutorial dazu schreiben ;-)).

@xZise
Es gibt verschiedene Möglichkeiten:
1. Probiere die optimierte Kollisionsmethode der SpriteEngine auszuschalten (SpriteEngine.CollisionType = ctNormal, oder so ähnlich)
2. Lasse mal das setzten von "Done" weg
3. Setzte mal einen Haltepunkt auf "Collision" und gehe all das durch, was danach passiert
4. Abstrahiere dein Problem und schreibe ein einfaches Beispielprogramm - wenn da der Fehler auch auftritt, dann kannst du mir das Programm schicken und ich suche den Fehler.

[xZise]

Okay, also:
1. Umgestellt => Keine Änderung
2. Umgestellt => Keine Änderung
3. Durchgeführt => Es wird nirgends (sichtbar) DoCollisions aufgerufen... Also habe ich mit AdSprites.pas angeguckt (ziemlich neu von CVS) und tada: Es wird NUR einmal dort DoCollision aufgerufen. Und zwar nur bei Collision2?!
4. Noch nicht durchgeführt.

Ich werde jetzt die alte AdSprites.pas angucken und wenn es dort öfter vorkommt werde ich mal CVS update durchführen und dann gucken ob es mit der neuen/alten Datei funzt :)

MfG
xZise

[edit]Update durchgeführt: Keine neuen Dateien.
Alte Datei überprüft: Keine entfernten Aufrufe von "DoCollision"
Also wurder ich mich, warum er nicht kollidiert :) [/edit]

[igel457]

Hallo,

ich habe den TPerformanceCounter mal gründlich überarbeitet. Nach der Andorra Namenskonvention heißt dieser jetzt "TAdPerformanceCounter". Neu ist, dass TimeGap "interpoliert" werden kann, was in flüssigeren Animationen resultiert. Über

Delphi-Quellcode:

TAdPerformanceCounter.Interpolate := false/true

kann das Interpolieren an und ausgeschaltet werden. Über

Delphi-Quellcode:

TAdPerformanceCounter.InterpolationFactor

kann das Verhältnis zwischen altem und neuem Timegap eingestellt werden. Normal ist hier 99, was einem Verhältnis von 99:1 entspricht.

Außerdem habe ich eine neue Demo mit dem Titel "WormHunter" gebastelt. Ist zwar noch nicht 100%ig fertig, läuft aber schon ganz gut (Achtung, wegen erhöhter Gewaltdarstellung ist diese Demo für Kinder unter 12 Jahren nicht geeignet :mrgreen: ).

[igel457]

Hallo,

ich habe mal eine neue Version hoch geladen: 0.20 ALPHA 2

Neue Features seit der letzten Version:
- TAdSpriteEngineEx
- TAdSetup (Einstellungsdialog)
- Voll Funktionsfähiges OpenGL-Plugin
- Viewports
- JPEG kann geladen werden
- PixelCheck bei Sprites
- Neue Features in TAdGUI
- Editoren wurden teilweise überarbeitet
- Überarbeiteter TPerformanceCounter
- Einige neue Demos
- Einige Bugfixes

[g0rmed]

Ich hatte gestern nen Fehler in AdPhysics.pas in Zeile 474-496:
r.Left war 0, aber als die for-schleife, die anstatt der "while (ax <= r.Right) and (ax < r.Left) do" steht, beim letzten Durchlauf war, wurde ax auf 65000 oda so gesetzt, dann gab es ne Exeption :(

Als ich es so "korrigiert" hatte hat es funktioniert, aber ich weiß nicht warum es vorher falsch war, bzw. nicht funktionert hat... :|

Delphi-Quellcode:

procedure TPhysicalSprite.ActivateNeighbours;
var r:TRect;
    ax,ay,i:integer;
    List:TSpriteList;
begin
  r := GetCollisionField;
  ax := r.Left;
  while (ax <= r.Right) and (ax < r.Left) do
  begin
    for ay := r.Top to r.Bottom do
    begin
      List := Parent.SpriteField.Items[ax,ay];
      for i := 0 to List.Count - 1 do
      begin
        if (List[i] <> self) and (List[i] is TPhysicalSprite) and 
           (TPhysicalSprite(List[i]).Typ <> ptStatic) then
        begin
          TPhysicalSprite(List[i]).Active := true;
        end;
      end;
    end;
  end;
end;

[igel457]

Hm... Komisch...

Kannst du mir vielleicht ein Projekt schicken, in dem du den Fehler rekonstruieren kannst? Das würde mir die Fehlersuche ziemlich erleichtern.

In deiner aktuellen Lösung vergisst du ax hochzuzählen...

Die Prozedur ist für Folgendes da: Wenn ein Objekt in Newton für eine gewisse Zeit ruht, dann wird es irgendwann in einen "Pausemodus" gesetzt. "ActivateNeighbours" ist nun dafür da, die benachbarten Sprites wieder aufzuwecken, sobald sich das Sprite bewegt.

[g0rmed]

Ja, dass hatte ich dann vergessen. Habe ich danach auch mitbekomen (leider offline), muss natürlich noch hochgezählt werden. Da Projekt häng ich mal an. Es muss nur mit den aktuellen Andorra2d Version 0.20 ALPHA2 compilieren, dann müsste der Fehler auftreten sobald man einen Block anklickt. Einfach nen Breakpoint in die entsprechende Zeile(Main.pas, 480 oda so) setzten.

[igel457]

Hallo,

ersetzte mal die Funktion "TSprite.GetCollisionField" durch die Folgende:

Delphi-Quellcode:

function TSprite.GetCollisionField: TRect;
var r:TRect;
begin
  r := GetFieldCoords;

  result.Left := r.Left - 1;
  if result.Left < Engine.SpriteField.StartX then
  begin
    result.Left := FEngine.SpriteField.StartX;
  end;

  result.Top := r.Top - 1;
  if result.Top < Engine.SpriteField.StartY then
  begin
    result.Top := FEngine.SpriteField.StartY;
  end;

  result.Right := r.Right + 1;
  if result.Right > Engine.SpriteField.EndX - 1 then
  begin
    result.Right := FEngine.SpriteField.EndX - 1;
  end;

  result.Bottom := r.Bottom + 1;
  if result.Bottom > Engine.SpriteField.EndY - 1 then
  begin
    result.Bottom := FEngine.SpriteField.EndY - 1;
  end;
end;

Dann läuft es - das "-1" hat gefehlt. Ich werde da aber mal nochmal genauer nachschauen, ob "EndX/Y" nicht generell 1 kleiner sein sollte.

Zu deinem Spiel: Echt Klasse! Weiter so!

[g0rmed]

Danke :) Mit so ner guten Engine ;)
Jo, bei mir gehts nun auch ohne Fehler. Danke!

[igel457]

Gerade schreibe ich den Andorra 2D Canvas um/neu. Neue Features darin werden sein:
- Doppelt so schnell wie vorher
- Keine Darstellungsfehler wie vorher
- Einstellen der Stiftbreite
- Einstellen von Texturen als Pen oder Brush
- Zeichnen von Polygonen
- Zusammenfassen von Objekten in "Display Listen"
- Vielleicht zeichnen von "Dashed"-Linien

Als Vorgeschmack im Anhang ein Screenshot meiner neuen Demo "Spiral"

[igel457]

Nochmal ein Screenshot von genau der gleichen Demo, dieses mal wurde die Linie jedoch texturiert. Alles was dazu nötig ist, sind folgende Zeilen:

Delphi-Quellcode:

Pen.Texture := AdImageList[0].Texture.Texture;
Pen.TextureMode := tmTile;  //Alternativ auch "Stretch"

Wichtig ist jedoch, das die Textur eine "Power of Two"-Größe hat, sonst entstehen schwarze Lücken.

Übrigens: Mein Canvas-Code ist mittlerweile rund 1000 Zeilen lang - kann aber nur Linien zeichnen. Er wurde in die Unit "AdCanvas" ausgelagert, die jetzt bei der Benutzung extra eingebunden werden muss.

Man kann das mit den Texturen besonders gut für "Strahlenkanonen" verwenden.

[mimi]

Sieht nicht schlecht aus.... sind das jetzt OpenGL Funktionen die du vereinfachst mit deinem TCanvas ?

[igel457]

Nach wie vor ist das natürlich von OpenGl oder Direct3d unabhängig und läuft mit beidem.
Spezielle OpenGl/DirectX Funktionen kommen nicht zum Einsatz - an der Plugin-DLL wurde nichts verändert.
Vielmehr generiere ich aus dickeren Linien ein Polygon:

Delphi-Quellcode:

function OrthogonalPoints(x1, y1, x2, y2, d: integer): TAdCanvasQuad;
var
  alpha:double;
  l:double;
begin
  FillChar(result, SizeOf(result), 0);

  l := sqrt(sqr(x2-x1)+sqr(y2-y1));

  if l > 0 then
  begin
    alpha := arccos((x2-x1)/l);

    if (y2 > y1) then
    begin
      alpha := 2 * pi - alpha;
    end;
    alpha := - alpha;

    result.p1.X := x1 + cos(alpha + 0.5*pi) * d / 2;
    result.p1.Y := y1 + sin(alpha + 0.5*pi) * d / 2;
    result.p2.X := x1 + cos(alpha - 0.5*pi) * d / 2;
    result.p2.Y := y1 + sin(alpha - 0.5*pi) * d / 2;

    result.p3.X := x2 + cos(alpha + 0.5*pi) * d / 2;
    result.p3.Y := y2 + sin(alpha + 0.5*pi) * d / 2;
    result.p4.X := x2 + cos(alpha - 0.5*pi) * d / 2;
    result.p4.Y := y2 + sin(alpha - 0.5*pi) * d / 2;
  end;
end;

[...]

    //Calculate Vertices
    FPoints.StartIteration;
    i := 0;
    lp := nil;
    while not FPoints.ReachedEnd do
    begin
      cp := PAdLinePoint(FPoints.GetCurrent);

      [...]

      if lp <> nil then
      begin
        FLastQuad := quad;
        quad := OrthogonalPoints(lp^.x, lp^.y, cp^.x, cp^.y, FPen.Width);

        Vertices[i*2].Position   := AdVector3(quad.p3.x, quad.p3.y, 0);
        Vertices[i*2].Color := cp^.Color;
        Vertices[i*2+1].Position := AdVector3(quad.p4.x, quad.p4.y, 0);
        Vertices[i*2+1].Color := cp^.Color;

        if i = 1 then
        begin
          Vertices[0].Position   := AdVector3(quad.p1.x, quad.p1.y, 0);
          Vertices[0].Color := lp^.Color;
          Vertices[1].Position := AdVector3(quad.p2.x, quad.p2.y, 0);
          Vertices[1].Color := lp^.Color;
        end;
      end;

      lp := cp;
      i := i + 1;
    end;

[...]

    //Calculate Indices
    for i := 0 to FPoints.Count - 2 do
    begin
      Indices[i * 6]     := (i * 2) + 1;
      Indices[i * 6 + 1] := (i * 2);
      Indices[i * 6 + 2] := (i * 2) + 2;
      Indices[i * 6 + 3] := (i * 2) + 1;
      Indices[i * 6 + 4] := (i * 2) + 2;
      Indices[i * 6 + 5] := (i * 2) + 3;
    end;

DirectX (über IDXLine oder sö ähnlich) oder OpenGl (über SetLineWidth oder so) machen das vermutlich intern genauso.

Zur Veranschaulichung habe ich nochmal ein Bild angehängt:

[mimi]

und wie bekommst du die Textur da rein ?

[igel457]

Ganz Einfach: Indem ich die Texturkoordinaten der Vertices entsprechend setze:

Delphi-Quellcode:

procedure TAdCanvasLine.GenerateTextureCoords(maxlen: double;
  var Vertices: TAdVertexArray);
var
  i:integer;
  lp,cp:PAdLinePoint;
  ax,ay1,ay2,len:double;
begin
  //Stretch coordinates
  if Pen.TextureMode = tmStretch then
  begin
    FPoints.StartIteration;
    i := 0;
    lp := nil;
    ax := 0;
    while not FPoints.ReachedEnd do
    begin
      cp := PAdLinePoint(FPoints.GetCurrent);

      Vertices[i*2].Texture.Y := 0;
      Vertices[i*2+1].Texture.Y := 1;
      if lp = nil then
      begin
        Vertices[0].Texture.X := 0;
        Vertices[1].Texture.X := 0;
      end
      else
      begin
        len := sqrt(sqr(lp^.X - cp^.X) + sqr(lp^.Y - cp^.Y));
        ax := ax + len/maxlen;
        Vertices[i*2].Texture.X := ax;
        Vertices[i*2+1].Texture.X := ax;
      end;
      lp := cp;
      i := i + 1;
    end;
  end;

  //Tile Coordinates
  if Pen.TextureMode = tmTile then
  begin
    FPoints.StartIteration;
    i := 0;
    lp := nil;
    ax := 0;
    ay1 := 0.5 - (FPen.Width / 2) / (Pen.Texture.Height);
    ay2 := 0.5 + (FPen.Width / 2) / (Pen.Texture.Height);
    while not FPoints.ReachedEnd do
    begin
      cp := PAdLinePoint(FPoints.GetCurrent);

      Vertices[i*2].Texture.Y := ay1;
      Vertices[i*2+1].Texture.Y := ay2;

      if lp = nil then
      begin
        Vertices[0].Texture.X := 0;
        Vertices[1].Texture.X := 0;
      end
      else
      begin
        len := sqrt(sqr(lp^.X - cp^.X) + sqr(lp^.Y - cp^.Y));
        ax := ax + len/Pen.Texture.Width;
        Vertices[i*2].Texture.X := ax;
        Vertices[i*2+1].Texture.X := ax;
      end;
      lp := cp;
      i := i + 1;
    end;
  end;
end;

Der Grafikkarte ist es schließlich egal, ob die Vertices die ich zeichne ein 3D-Model, ein 2D-Sprite, ein Stern oder eben eine Linie sein sollen.

[mimi]

Interessant.... würde das so auch bei einem Normalen Canvas gehen ? also ohne OpenGL Unterstützung oder DX ?

Weil ich mich immer gefragt habe, wie die das bei www.clonk.de z.b. immer machen, mit den Texturen.... das die in einen Polygone gezeichnet werden.

[igel457]

Mit der Graphics32-Bibliothek ist das kein Problem. Sonst ist es vermutlich mit der GDI/GDI+ irgendwie möglich. Unter Linux (worauf du sicherlich hinaus willst) habe ich keine Ahnung. Mehr weiß ich leider auch nicht. Wenn es dich interessiert (mich interessiert es auch) kannst du ja einfach einen neuen Thread aufmachen und Fragen, vielleicht weiß ja jemand anderes bescheid.

EDIT: Die einfachste Methode ist es, die Textur gekachelt auf ein Bitmap zu zeichnen und dann ein anderes Bitmap mit dem Polygon als SW-Bild als Maske darüberzulegen.

[mimi]

ich habe mal hier nachgefragt:
http://www.delphipraxis.net/internal...=795880#795880

[knoby]

HI

ich benutze seit einer Woche Andorra und wühle mich im mom durch die ganzen Funktionen ...
Dabei bin ich auf zwei Probleme gestoßen:

1)
Wenn ich versuche ein Programm mit TAdSetup aus der AdSetupdlg zu compilieren also diesen Optionendialog spukt mir das Programm folgenden Fehler aus:

Fehler beim Lesen von Image1.ExpliciteLeft: Eigenschaft ExpliciteLeft existiert nicht.

Das spuckt er mir nicht als Compilerfehler aus sondern das compilierte Programm ... woran kann das liegen?

und

2)
Die GUI steuerung sieht so was ich bis jetzt gesehn habe gut aus nur ich komme mit der Ansteuerung der einzelnen Elemente nicht ganz klar wie ich zum beispiel Rausfinde Was jetzt im GUI in die Textbox geschrieben wurde usw ... wäre shcön wenn du dazu nen einfaches Beispiel Programm hättest oder gleich nen Tutorial

schonmla danke


mfg

knoby

[igel457]

Hallo knoby,

schön das du meine 2D-Engine verwendest.

Zu 1)
Das solltest du beheben können, indem du die Datei "AdSetupDlg" in Delphi öffnest und die F12-Taste drückst. Delphi sollte nun die nicht vorhandenen Eigenschaften entfernen.
Alternativ kannst du auch die Deklaration von "ExpliciteLeft" etc. manuell aus der "AdSetupDlg.dfm" entfernen.
Der Fehler resultiert nämlich daraus, dass du wahrscheinlich eine ältere Delphiversion als ich verwendest und die entsprechenden Eigenschaften beim Laden des Formulars zur Laufzeit nicht gefunden werden.
Ich habe bei mir nun alles aus der dfm entfernt was mir irgendwie "unwichtig" erschienen ist - in der nächsten Version sollte es also ohne Probleme klappen.

Zu 2)
Eigentlich auch ganz einfach:
Du gibst den Komponenten im Editor Namen. Über den Befehl

Delphi-Quellcode:

"AdGUI.FindComponent('MeineKomponente1')"

bekommst du die Komponente mit dem entsprechenden Namen zurückgeliefert. Nun musst du das Zurückgelieferte nur noch in den entsprechenden Komponententyp umwandeln (casten): Die Funktion liefert nämlich immer nur den Typ TAdComponent zurück, von dem alle anderen Komponenten abgeleitet sind:

Delphi-Quellcode:

  TAdEdit(AdGUI.FindComponent('Edit1')).Text := 'Test Test, 1-2-3';

Ich hoffe das hilft, :wink:
Andreas

[knoby]

HI

JO danke hat sehr geholfen rennt jetzt wie suppe ;) Diese Componenten in AdComponents sind genau das was ich gesucht habe

tausend danke!!!

[Bääääär]

Tach igel!

Ich habe ein bisschen herumgefriemelt und bin dabei auch auf die TAdLog Klasse gestoßen. Ich finde den Log noch etwas unübersichtlich. Was hältst du davon:

Delphi-Quellcode:

procedure TAdLog.AddMessage(AMessage: TAdLogMessage);
const
  cTabulator = 20;
var
  Space:integer;
  LMessage:string;
  i:integer;
begin
  LMessage := '[' + AMessage.Typ + ']';

  Space := cTabulator - length(AMessage.Typ) - 2;
  if Space < 1 then Space := 1;
  for i := 0 to Space do
    LMessage := LMessage + ' ';


  LMessage := LMessage + AMessage.Sender + ':';

  Space := cTabulator - length(AMessage.Sender) - 1;
  if Space < 1 then Space := 1;
  for i := 0 to Space do
    LMessage := LMessage + ' ';


  LMessage := LMessage + AMessage.Text;

  self.Items.Add(LMessage);
  if FileName <> '' then
  begin
    SaveToFile(FileName);
  end;
end;

Ist nur so eine Idee von mir. Ich hab bei mir eine Unterklasse angelegt und mir funktionen geschrieben, die den Error typ nicht als Parameter brauchen (z.B. procedure LogError(const aLog: String; const Sender:String); => würde den Typ "Error" haben). Dabei ist mir etwas aufgefallen, was ich blöd finde:

1. Die Items sind nicht abrufbar, da sie in private deklariert sind. Wenn ich die Funktion oben in meine Unterklasse einbauen will, muss ich da aber drauf zugreifen können.

2. Das gleiche gilt für die property Log im AdDraw. Wenn ich nun meine Unterklasse von TAdLog für die Engine nutzen will, muss ich das ja ändern können. Vielleicht spricht etwas anderes dafür, das ganze Read-Only zu machen, das ganze war nur so'ne Idee von mir.

Wenn du oben geposteten Code in die AdDraws.pas übernehmen solltest würde ich mich natürlich freuen, ich habe den nämlich jetzt einfach in meine AdDraws.pas eingebaut. So brauche ich bei neuen Andorra Versionen nicht wieder diesen Code ändern... Wenn nicht, dann gib mir die Items frei, damit ich das in meine Unterklasse bauen kann! ^^

Bääääär

[igel457]

Hallo Bäääär,

habe deinen Code eingebaut - Items ist nun außerdem auch freigegeben. In der nächsten Version wird es enthalten sein.

Vielen Dank,
Andreas

[igel457]

Hallo,

ich plane gerade an einigen Umstrukturierungen um Unitabhängigkeiten zu minimieren - wo es geht möchte ich auf Units wie "Types", "Graphics" etc. verzichten.
Deshalb habe ich mir einige Schritte überlegt.
Um es vorab zu sagen: Das Ganze wird dazu führen, dass "einige" Units mehr eingebunden werden müssen. Es wird nicht bei dem einfachen "AdDraws" und "AdClasses" bleiben:

• TAdCanvas ist in eine extra Unit gewandert
  • Keine Abhängigkeit mehr zu "AdDraws"
  • Nun muss jedoch die Unit "AdCanvas" extra eingebunden werden, sobald man das Canvas sinvoll verwenden will
• TAdFont wandert in eine extra Unit
  • Da "TAdCanvas" "TAdFont" verwenden soll, jedoch keine Abhängigkeit zu "AdDraws" haben soll muss auch "TAdFont" umziehen
  • TAdFont kümmert sich nur noch um das darstellen der Fonts, nicht mehr um das Erstellen dieser
  • Um keine Abhängigkeit mehr zu "Graphics" und z.T. auch "Windows" zu haben, wandert ein "TAdFontCreator" in eine neue Unit, die Fonts (d.h. die Textur) erstellen kann
  • Außerdem wird es möglich sein mehrere "FontCreators" einzubinden
  • Um nach wie vor Fonts nur als Metadaten speichern zu können, werden alle "FontCreators" registriert.
  • Die Unit "AdFont" und die verwendeten "FontCreators" müssen als Unit eingebunden werden.
• Da ich die Unit "Types" nicht mehr verwenden möchte (ich verwende daraus sowieso nur TPoint und TRect), wird diese durch "AdTypes" ersetzt. Auch diese Unit muss eingebunden werden.
  • Es anstatt Funktionen wie "Bounds" oder "Rect" müssen die Funktionen "AdBounds" oder "AdRect" verwendet werden, anstatt "TRect" "TAdRect" etc.
• Da "TAdPerformancecounter" Abhängigkeiten zu "Windows" bzw. "LibC" hat, ist auch dieser in eine Extraklasse gewandert. "AdPerformanceCounter" muss eingebunden werden.
• Der Standard "HAI" und "BMP" Dekoder/Kompressor fliegt wegen Abhängigkeit zu "Graphics" auch erstmal aus "AdDraws" in eine neue Unit, die eingebunden werden muss.

Jetzt stellt sich natürlich die Frage - Wieso das Ganze? Ich möchte später auch die Möglichkeit geben, Non-VCL-Anwendungen zu erstellen, die dann endlich unter Linux laufen werden - so wie bei Phoenix2D.
Außerdem ist es somit möglich wirklich nur die Module zu kompilieren, die man auch braucht. Wenn jemand nur PNG-Dateien lädt, wieso sollte er dann den BMP-Loader mitkompilieren?

Noch habe ich erst wenige der oben aufgeführten Schritte durchgeführt, wenn also irgendwer Einwände oder Kommentare hat, immer her damit. Ich versuche natürlich, Andorra 2D nach wie vor so unkompliziert wie möglich zu halten - ich möchte schließlich keinen vergraulen. Damit Anfänger keine Units vergessen, werde ich voraussichtlich Includedateien vorgeben, die die wichtigsten Units automatisch einbinden.

Dann reicht zum Beispiel folgendes:

Delphi-Quellcode:

uses
  [...],
  {$I Andorra}, {$I AdGUI}

Apropos "AdGUI", ich habe gestern auf vielfachen Wunsch ein Tutorial zum GUI-System geschrieben.

Die nächste veröffentlichte Version wird voraussichtlich Andorra 2D 3.0 BETA sein, ich hoffe, das ich diese Version noch vor Weihnachten fertig bekomme - wer möchte kann es sich ja auf CD brennen und unter den Weihnachtsbaum legen :-D .


Hier ist meine aktualisierte Roadmap:

Code:

Andorra 2D Roadmap
------------------

This roadmap may change from time to time...

[b]Project Alpha State[/b]

[...]

Version 0.2 (Releases: ALPHA1|ALPHA2)
Plugin side:
- Transform the view matrix to a 3D view [DONE]
- Draw lines [DONE]
- Viewports [DONE]
Application side:
- Canvas [DONE]
- GUI [DONE]

Version 0.3 (Releases: STABLE)
- Rewrite Canvas [85%]
- Extended Spriteengine [75%; Zoom works, but rotation doesn't]
- Restructure [15%]

Version 0.4 (Releases: BETA|STABLE)
Application side:
- Load 3D objects [50%]
- TGA etc. texture loader and compressor
- Expand Newton-Unit

[b]Project Beta State[/b]

Version 0.5
Plugin side:
- Textures as rendertarget
- Shader

Version 0.6
- Animated 3D-Models

[b]Project Stable state[/b]

Version 1.0
- Everything is done

Dann mal her mit der Kritik ;-),
Andreas

[mimi]

Eine frage hätte ich dochnoch; würde oder könntest du eine SDL unterstützung einbauen ?
Dann würde diese Enginen sogar bei mir unter Linux laufen, wo es ja noch kein OpenGL gibt bzw. läuft....

Das währe sehr schön. Ich kenne mich mit SDL nicht aus.... Wenn du oder ihr sagt das währe möglich, könnte ich mich mal neher mit SDL befassen, Das läuft auch unter Lazarus. Die Frage währe nur, wie man das am besten einbringt, so das man einen Code nicht 1000 Mal schreiben müsste.

Im Moment schreibe ich ja meine Spiele in 2D, aber das ware ist das leider auch nicht.

Wenn das mit SDL läuft unter deiner Engine, währe das toll.

[igel457]

Hallo mimi,

für was sollte ich SDL einbauen? SDL ist eine Platformunabhängige Hardware und Software Abstraktions Ebene - und genau das gleiche ist Andorra 2D doch auch. Das einzige, was ich von SDL gebrauchen könnte, wäre Fenster und Eventmanagement.

[Progman]

Zudem sind die verfügbaren SDL-Units schon recht alt (ich glaub 2002) und werden anscheinend auch nicht weiter aktualisiert. Außerdem müsste man seiner Anwendung einige DLLs mitgeben. Und ich denke mal, auf einer Umgebung, wo nicht mal OpenGL läuft, wird das auch nicht laufen... :wink:

[mimi]

Naja unter meinem Linux läuft ja leider kein OpenGL, aber SDL.
Und ich denke SDL kann einiges was OpenGL auch kann, im 2D bereich meine ich jetzt.

und ich dachte jetzt, wenn du oder einer von euch, das in die Engine von dir Einbauen könnte, dann könnte ich und andere die das gleiche Problem haben, deine Engine nutzen ob man nun eine DLL mitgeben muss oder nicht, das spiel für mich keine große roll.

Es war ja nur ein Vorschlag. ob das ginge.
In den Letzten Tagen hatte ich mal unter Lazarus Jedi SDL ausprobiert, was auch ganz gut läuft...
Daher kam die Idee. ist OpenGL nicht (fast) das gleiche wie SDL ? weil beide läuft doch auch Platform unabhänig.

Und mir geht es darum einfach mal deine Engine Unter Lazarus zu testen und ob ich damit ein oder mehrer Spiele zusammen bekommen. Im Moment nutze ich ja TCanvas, weil das am einfachsten ist.

In SDL müsste ich mich erst einarbeiten und OpenGL läuft nicht, da habe ich keine große wahl oder ?
naja gut GDI könnte ich noch nehmen, aber wo da die großen Unterschiede sind weiß ich auch nicht.

Und ob ich mich jetzt näher mit SDL befasse weiß ich auch noch nicht.
Aber würde das denn Überhaupt gehen ? so ohne weiteres ?

[igel457]

Hallo mimi,

wenn ich dich richtig verstanden habe, dann meinst du, man könnte ein SDL-Plugin für Andorra 2D schreiben. Dabei gibt es jedoch ein paar kleinere Schwierigkeiten:
Die meisten Grafikoperationen, die ich verwende, finden im 3D-Raum statt. Verwendet man SDL dafür, so verwendet dieses intern OpenGL/DirectX. Da kann ich mir OpenGL/DirectX doch direkt sparen, und meine Bibliotheken verwenden. Man könnte natürlich alle Grafikoperationen in den 2D-Raum transformieren und dann den SDL Framebuffer verwenden. Das wäre eine Möglichkeit, die vielleicht nicht einmal so abwegig, dafür aber ziemlich langsam ist.
Das größte Problem ist, dass die SDL Grafikausgabe IMHO an ein in SDL erstelltes Fenster gebunden ist und nicht auf ein schon vorhandenes Fenster gemappt werden kann.
SDL zu verwenden ist momentan also nicht möglich, ich habe mir aber wie in meinem Beitrag von Gestern beschrieben, schon einige Gedanken gemacht, wie ich Andorra 2D endlich unter Linux zum laufen bekomme.

Zitat:

Zitat von mimi

ist OpenGL nicht (fast) das gleiche wie SDL ?

Nein, SDL verwendet sogar unter bestimmten Umständen OpenGL.

[mimi]

Schade !

Zitat:

Die meisten Grafikoperationen, die ich verwende, finden im 3D-Raum stat

um die Hardware Beschleunigung zu unterstützen ?

Zitat:

dass die SDL Grafikausgabe IMHO an ein in SDL erstelltes Fenster gebunden ist

Ich bin mir noch nicht sicher ob man das nicht ändern könnte.
Aber wenn schon, so schlimm währe das meiner Meinung nicht unbedingt.

Zitat:

SDL zu verwenden ist momentan also nicht möglich

Ich denke es währe aufwendig oder ? so ein Plugin zu schreibe, was dann noch eingier Maßen Schnell läuft.
Es währe halt toll, wenn das nicht doch Irgendwie ginge...

Zitat:

schon einige Gedanken gemacht, wie ich Andorra 2D endlich unter Linux

An was genau hast du dabei gedacht ? Du müsstest endliche Complier Schalter einbauen, denke ich mal, oder ?
um OpenGl zu nutzen.

und was hältst du von GDI ? währe das nicht denkbar ?

[Stoney]

Ui, es geht um die SDL. Mein Lieblingsthema :)
Die SDL ist in keinster Weise veraltet, das letzte Release war meines Wissens im Mai diesen Jahres. SDL funktioniert eigentlich auf jedem beliebigen PC , ich hatte ein Testprogramm auch auf einem 166 MHz - PC mit 16 MB RAM laufen lassen. Ging einwandfrei, die Performance war aber nicht so der Hammer *G*.
Unter Windows benutzt die SDL DirectX 7.0, wenn DirectX nicht vorhanden ist, greift SDL automatisch auf GDI zurück.
Unter Linux wird X verwendet und unter Mac Carbon (bin mir bei Carbon nicht ganz sicher, könnte unter OS X auch Aqua sein und unter Classic Carbon).
Die SDL verwendet nur dann OpenGL, wenn es der Programmierer implementiert, sonst nicht.

Momentan ist Andorra2D nur pseudo-plattformunabhängig, anders als die SDL.
Wie ohne weiteres Linux-Unterstützung für Andorra2D eingebaut werden soll, kann ich persönlich nicht vorstellen. Du müsstest ein bestehens Fenster-Framwework wie z.B. die GTK nehmen und außerdem die Unterstützung von FreePascal gewährleisten. Und dann geht der Spaß erst los: Wenn man die GTK verwendet, sehen die erstellten Programme unter KDE bescheiden aus, mit Qt genau andersrum. Einen Dinosaurier wie GLUT sollte man von Anfang an vermeiden.
Das Ergebnis am Schluss: Du hast jede Menge Code, was man mit der SDL deutlich einfacher und eleganter erledigen hätte können.

@mimi: Du kannst mal nach "ElysionSDL" googeln. Oder in meine Signatur schauen :)
Ist aus gleichen Gründen wie Andorra entstanden, nur etwas mehr als ein Jahr früher. (BTW: Alphablending mit der SDL rockt :D )
ElysionSDL läuft nachweislich auf Windows, Linux und Mac und benötigt in der Version, die zum Download steht, kein OpenGL.
Folgende Compiler wurde mit ElysionSDL getestet: FreePascal, Kylix und Delphi.

[mimi]

Zitat:

Ui, es geht um die SDL. Mein Lieblingsthema

ich glaube ich schließe mich mal dir an.....

Vielen Dank für den Tipp mit "ElysionSDL" werde ich gleich mal ausprobieren.
Mit Lazarus kann man meine ich auch API code erstellen entweder Linux oder Windows....

Aber du bist auch der ansicht, das SDL nicht in Andorra eingebaut werden kann ?

[igel457]

Um es noch einmal klar zu stellen:
Ich meine nicht, dass SDL schlecht, veraltet oder für Andorra 2D an sich nicht zu gebrauchen ist. Ich meine nur, dass es keinen Sinn macht ein Andorra 2D SDL Plugin zu schreiben ;-)

Nicht, dass mich jemand falsch versteht...

[Progman]

naja, Stoney, das SDL aus deiner Signatur läuft bei mir grad mal mit 30 FPS (GeForce2 MX 400) und dazu benötigt man auch noch 6 DLLs, also das wär für mich nicht erstrebenswert, aber wers mag.... :spin2:

[mimi]

ich finde es auch nicht so toll, es fehlt ein Beispiel. der Shooter und beim Memory fehlen die Grafiken.
Aber toll ist das nicht gerade. und auch wieder 100% CPU last... das ist doch lächerlich bei einfachen 2D Spielen.

Im Allgemeinen sollten 2D Spiele finde ich so gut wie keine CPU last verbrauchen 20 oder 30 % ist für mich inordnung aber gleich 100 ? das geht auch anders.

Ich musste alles Beispiele nach Lazarus Umwandeln. und auch die Verzeichnis namen ändern wegen dem Leerzeichen.

[Stoney]

Zitat:

Zitat von mimi

Aber du bist auch der ansicht, das SDL nicht in Andorra eingebaut werden kann ?

Selbstverständlich kann es eingebaut werden, und wäre langfristig gesehen sicherlich besser, zumal sich Andorra2D groß "Plattformunabhänigkeit" auf die Fahne schreibt und das wäre mit der SDL einfach zu erreichen, der steierne Weg wäre sich über GTK, Qt, o.ä. alles selber hinzuzimmern. (Das wäre natürlich erstmal auf Windows und Linux beschränkt, will man auch noch Mac unterstützen, muss man sich mit Carbon und/oder Cocoa beschäftigen.)

Edit:
Ok, die Vorwürfe hätten auch in den ElysionSDL-Thread reingehört, aber ich antworte auch mal darauf :)
Erstens: Die Version zum Downloaden ist auch schon über ein Jahr alt.
Zweitens: Die Versionsnummer ist bei 0.25, es ist nicht fertig und es sind eine Menge Leichen aus alten Releases noch drin (z.B. das Lazarus-Projektfile, noch nicht komplett auch casesensitiv angepasst, Code von anderen einfach ohne Bedenken eingefügt). Ich hatte die Beispiele immer über die Konsole kompiliert.
Drittens: Die Tolligkeit eines Programms/einer Engine wird nicht daran gemessen, wie viele DLLs dabei sind. DirectX-Programme benötigen auch knapp 10 DLLs (nur sind diese schon im Windows-System-Ordner mit drin). Das Spiel "Ankh" installiert dir ca. 8 DLLs mit, die zur Ogre3D-Engine dazu gehören.

Du weißt schon, dass die SDL (ohne OpenGL) komplett über die CPU rechnet, oder? Deine gewünschten 20-30% Last erreichst du erst mit Hardwarebeschleunigung. Die Grafikkarte wird überhaupt nicht beansprucht. Deswegen sind auch 30 FPS kein Wunder.


Edit2:
Außerdem steht die ElysionSDL unter der MPL-Lizenz, feel free to change. :)

[igel457]

Zitat:

Zitat von Stoney

Zitat:

Zitat von mimi

Aber du bist auch der ansicht, das SDL nicht in Andorra eingebaut werden kann ?

Selbstverständlich kann es eingebaut werden [...]

Aber Bitte nicht als Plugin! Bei allem anderen habe ich ja nie gesagt, dass ich das schlecht fände oder ich SDL nicht verwenden will :roll: :

Zitat:

Zitat von igel457

Das einzige, was ich von SDL gebrauchen könnte, wäre Fenster und Eventmanagement.

:wink:

[mimi]

naja es gibt Lazarus warum kann man das nicht verwenden. Das läuft schon auf vielen Systemen und gut ist.

Gar kein Problem. Eigentlich. Dort wird GTK1 und 2 bereit zu ca 60 bis 70 % Unterstützt.

Aber wie denn ? wenn nicht als Plugin, eine Komplet eigene Engine währe doch auch wieder Käse.
Ich dachte halt, das man es an deiner "anpassen" könnte. Mit wenig Aufwand, wobei wenig relativ ist.

[mimi]

@Stoney
Wenn man nicht ständig das Komplete Bild neu auf erstellt, kann man sogar noch weniger als 20% CPU last erreichen...