Hallo zusammen,

ich schreibe gerade zum Üben einen Flugsicherungssimulator, wobei es mir besonders auf strukturierten und testbaren Code ankommt. Ein Kernelement des UIs soll ein Radarbildschirm sein, vom Prinzip her vergleichbar wie auf folgendem Bild: https://flyawaysimulation.com/downlo.../airtrfcfx.jpg

Neben der eigentlichen Darstellung (z. B. Flugzeuge, deren letzten Positionen, Landebahnen, Wegpunkte, Beschreibungstexte) soll später auch die Möglichkeit bestehen, den Bildausschnitt zu verschieben (so dass der Flughafen nicht zwingend zentriert liegen muss) und den sichtbaren Ausschnitt zu zoomen. Außerdem soll es evtl. möglich sein, durch Klicken auf die dargestellten Flugzeuge zusätzliche Beschreibungstexte anzuzeigen.

Da ich bislang kaum mit einem Canvas gearbeitet habe und mir die Erfahrung damit fehlt, bräuchte ich einmal euren Rat bei ein paar Fragen.


1. Welche Komponente bietet sich eurer Meinung nach bei meiner Problemstellung an? Wäre eine TPaintBox eine gute Wahl?

2. Wie kann man Änderungen in einer Zeichnung am besten implementieren? Sollte im Datenmodell die Position aller grafischen Elemente, die sich auf dem Canvas befinden, gespeichert werden, so dass man bei jeder Änderung (z. B. Position eines Flugzeugs wird verändert) alle Elemente komplett neuzeichnen kann? Falls ja, könnte das zu Flackern beim Neuzeichnen führen? Oder sollte jedes Element sich selbst darum kümmern, dass die alte Position gelöscht und die neue Position gezeichnet wird?

3. Rein logisch finde ich, dass es besser ist, wenn jedes Objekt selbst in der Lage ist, sich zu zeichnen. Meine erste Idee war beispielsweise, folgendes Interface anzulegen:

markieren

Delphi-Quellcode:

IDrawable = interface
  procedure Draw(const Canvas: TCanvas);
end;

Jedes Element, das auf dem Radarbildschirm sichtbar sein kann, muss lediglich dieses Interface unterstützen, womit es in der Lage wäre, sich auf den übergebenen Canvas zu zeichnen. Allerdings stellt sich mir bei diesem Ansatz die Frage: Wer kümmert sich darum, dass die alte Position vom Canvas verschwindet? Klar könnte sich jedes Objekt die alte Position merken und jedes Mal, wenn Draw aufgerufen wird, setzt das Objekt die Punkte von der letzten Position wieder zurück, aber das würde zu falschem Verhalten führen, wenn sich Positionen von verschiedenen Objekten überlagern, denn dann führt das Zurücksetzen/Löschen der alten Position dazu, dass möglicherweise Bestandteile anderer dargesteller Objekte mitgelöscht werden. Außerdem soll ja auch ein Verschieben/Zoomen des Bildausschnittes möglich sein. Wie können sich die Objekte wie Flugzeuge selbst auf ein Canvas zeichnen, wenn sie nicht wissen, welcher Bildausschnitt gerade sichtbar ist und an welcher Position sie sich auf dem Canvas platzieren sollen?
Aus diesem Blickwinkel wäre es wiederum gut, wenn es eine separate Klasse (eine Art "Zeichnen-Manager") gibt, die sich um alle Zeichenoperationen kümmert. Ich sehe darin dann aber ein sehr schlechtes Design, denn jedes Mal, wenn ein neuer zeichenbarer Objekttyp erstellt wird, dann müsste man die Klasse anpassen, damit sie auch weiß, wie der neue Objekttyp zu zeichnen ist. Außerdem: Angenommen eine Instanz einer Flugzeugklasse meldet sich beim "Zeichnen-Manager", weil es neu gezeichnet werden soll. Wie weiß dann dieser "Zeichnen-Manager", welche Pixel zur vorherigen Position gehören, damit er diese Pixel zurücksetzen kann?

Wie ihr seht, habe ich noch keine passende Idee, wie ich mein Vorhaben implementieren kann. Habt ihr einen Vorschlag für mich?

Ich würde immer erstmal versuchen in Bitmaps zu malen und diese dann für jedes Frame sichtbar zu machen, als Doublebuffer.

Evtl. Auch in fmx mit Vektor Elementen arbeiten über z.B. einem Grundbitmap, wenn das dann nicht zu kleinteilig wird.

Paintbox oder Image mit Scrollbox bei Fmx wäre OK.
Wenns von der Performance für dich nicht reicht evtl. Gameengine,
Aber ich glaube der Radar macht eigentlich nur kleine Änderungen pro Zeiteinheit.
Sollte wohl OK sein.

Rollo

Ich weiß ja nun nicht wie groß dieses Radar dargestellt werden soll und über wieviel einzelne Objekte wir hier reden.
Ab einem gewissen Maß könnte auch ein Gedanke an DirectX mit Hardware Beschleunigung Sinn machen.
Näheres kann man Erfahren wenn man zum Beispiel nach Delphi DirectX API sucht.

Edit
Oder über OpenGL

Das schon genannte Firemonkey wäre dafür die ideale Lösung. Nicht ganz einfach von der Einarbeitung, aber wenn man es dann gut benutzen kann, wirklich gut dafür. Denn dort kannst du Elementen Bewegungspfade geben, Animationsgeschwindigkeiten, ...
Und es ist eben kein großer Aufwand, man muss es nur verstehen.

Ansonsten ist es mit einer Paintbox auch kein Problem. Eine Demo für das Zeichnen darauf findest du hier:
https://www.delphipraxis.net/132375-...-beta-6-a.html

Danke schon einmal für die Antworten.

Ich benutze ein VCL-Projekt, d. h. die Möglichkeit über eine FMX-Komponente scheidet für mich aus (auch wenn der Ansatz interessant klingt).

Zitat:

Ich würde immer erstmal versuchen in Bitmaps zu malen und diese dann für jedes Frame sichtbar zu machen, als Doublebuffer.

In diesem Fall wäre dann die TImage-Komponente am besten geeignet, oder?

Zitat:

Ansonsten ist es mit einer Paintbox auch kein Problem. Eine Demo für das Zeichnen darauf findest du hier:
https://www.delphipraxis.net/132375-...-beta-6-a.html

Ich denke, dass ich es erst einmal mit diesem Ansatz versuchen werde. Ich weiß zwar immer noch nicht, wie ich die Bewegungen implementieren soll (alles komplett neu zeichnen oder nur die Änderungen zeichnen), aber vllt. finde ich in dem von dir genannten Link noch Anregungen dafür.

Schau dir mal das hier

https://github.com/tothpaul/DelphiTi...AnimatedArrows

an und auch einige der anderen Projekte in dem Repository.

Hallo,

das klingt nach einem interessanten Projekt

Da Du ja Wert auf strukturierten und Testbaren Code Wert legst würde ich den folgenden
Ansatz verfolgen:

Vorgaben: (So wie ich es verstanden habe)

Darstellung Zoom und Verschiebbar
Selektion einzelner Bereiche und eventuell zusätzlicher Informationen
Animation der Objekte (Flugzeuge) also Bewegung, Höhe etc...

Mein Ansatz wäre:

Definieren der Klassen ohne! Darstellungs-Optionen

Also etwa:
// Pseudo Code nur so hingetipt

zusammenfalten · markieren

Delphi-Quellcode:

type

TBaseAirplane = class

 public
   property Position : Tposition3d;
   property Speed : Double;
   property Direction : TDirection3d;
   property LastUpdateTime : TUpdateTime;
 
end;

TPlaneCalculator = class
  public
  // Bestimmt die aktuelle Position etc anhand der Zeit, Route etc
   function CalcNewPos(aBaseAirplane : TBaseAirPlane; actualTime : tUpdateTime) : boolean;
end;


TSimulator = class
  private
    fAirPlanes : Tlist<TBaseAirplane>;
    fCalculator : TPlaneCalculator;
  public
    // funcs zum verwalten der AirPlanes also add, delete, etc...
  
   
   // Von aussen z.b über einen Timer anstossen
   procedure UpdatePositions(actualTime : TUpdateTime);
   begin
     for plane in fAirPlanes do fCalculator(plane, actualPlane);
   end;
   
end;

Auf dieser Basis ist es erstmal möglich Tests für das verhalten zu erzeugen.


Zeichnen:

Dein Ansatz über ein Interface ist nicht schlecht.
Ich würde aber weitergehen und das Komplett abstrahieren. Also nicht über den TCanvas sondern
einen Eigenen Virtuellen Zeichenbereich.
Aktuell willst Du nur auf den Bildschirm, nächste Woche aber bestimmt auch auf einen Drucker,
als SVG zu ner WebPage, als Dokument in Pdf etc..........

Der Vorteil beim Abstrahieren ist, Deine Klassen müssen nicht wissen wie sie gezeichnet werden.
Alle Daten innerhalb Deiner Klassen arbeiten in World-Koordinaten.
Nur für den Canvas ist es wichtig zu wissen wie skaliert etc.. wird.

So etwa:

markieren

Delphi-Quellcode:

IRadarCanvas = interface
  procedure DrawPlane(aPlane : TBaseAirPlane);
end;

IRadarDrawable = interface
  procedure Draw(const Canvas: IRadarCanvas);
end;

So kannst Du es in eine "grosse" Drawklasse packen oder
halt dann ableiten von TBaseAirplane

also

markieren

Delphi-Quellcode:

class TAirplaneDrawer = class(TbaseAirplane, IRadarDrawable)
 procedure Draw(const Canvas: IRadarCanvas);
end;

Beim Zeichnen auf den Bildschirm würde ich das ganze in "Layer" verpacken.

Also einen Layer für den statischen Hintergrund (Das RadarBild).
Layer für das animierte Radar (Dieser Rotierende Linie).
Layer für die Aktuell vorhandenen Flugzeuge.
Layer für die Zusatzinformationen.


Wenn wir mal Threads aussen vor lassen,
benötigst Du mindestens 1 Timer.

Dieser löst immer eine Neubestimmung der aktuellen Positionen aus, ruft also
TSimulator.UpdatePositions auf.
Anschliesend wird ein "fertiges" Bitmap für die Darstellung aus den Layern erzeugt und ein Invalidate auf Deine Paintbox.


Im Paint Event wird dann immer nur das "fertige Bitmap gezeichnet"

Es wurden ja auch schon einige Möglichkeiten genannt für Graphic Bibliotheken
hier aber noch eine:
https://github.com/graphics32/graphics32

Hat Alpha und Layer. Schaue es Dir an

So könnte das aussehen,
als Zip da das Gif zu gross ist..

@scurra

Ich habe mal ein graphisches Framework gebaut, das nur zyklisch in ein Bitmap zeichnet und dieses auf den Bildschirm kopiert.
Damit baue ich Formulare auf, ähnlich VCL bzw. FMX.
Die Positionen der Controls speichere ich in der Datenschicht und ermittle darüber, über welchem Control die Maus sich befindet.

Hat ganz gut funktioniert und ging wirklich schnell (sogar ohne Grafikbeschleunigung etc).

Schau mal hier:
https://www.delphipraxis.net/175033-...-schlecht.html
Im letzten Beitrag ist eine Demo zum Testen.

Danke noch einmal für den Input von euch. Ich werde versuchen, das beste daraus zu machen und gebe dann evtl. noch einmal Bescheid ob es geklappt hat. Kann allerdings noch etwas dauern, da das ein Freizeitprojekt (und just for fun) ist und ich durchschnittlich wahrscheinlich nur 1-2 Stunden pro Woche daran arbeite. Also nicht wundern, wenn ich erst einmal keine Rückmeldung gebe.

Die Implementierung von Fritzew sieht für mich gut aus, vor allem der Schritt, die Zeichenfläche noch einmal abzukapseln. Ob ich nun direkt eine Paintbox zeichne oder ein Bitmap verwende, weiß ich noch nicht genau. Im Moment sieht es für mich aber eher so aus, als wäre es leichter, eine Bitmap zu verwenden, vor allem, weil dort die Verwendung mehrerer Schichten möglich ist.