Andorra 2D [Ver. 0.4.5.1, 31.12.08]

[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.