Das alte leidige Problem. Man hat sich selber dazu "durchgerungen", dic VCL zu verwenden. Blos, wo rendert man jetzt? Wollte mit diesem Thread mal 'n ekleine Diskussion einleiten, bei welcher man sich über die fongenden dinge Gedanken machen Kann:

- Ist es ausreichend, im OnIdle der Application zu rendern?
- Ist eine eigene Render-Loop sinnvoll, wenn mann dabei Application.ProcessMessages aufruft?
- Lohnt sich ein Render-Thread wirklich?

Kurz zu meinen Überlegungen:

Einen eigenen Thread zu erstellen, in welchem man die ganze Zeit ununterbrochen Rendert? Hmm, stellt sich die Frage, ob's das wirklich 'rausreist. Denn die Variablen, welche zwischen dem Render-Thread und dem Haupt-Thread ausgetauscht werden müssen, muss man erstmal synchronisieren. Einfaches austauschen iss nich'. Also wäre die Überlegung, alles vom Haupt-Thread zu rendern (wobei OnIdle wirklich ausreichend dafür sein sollte) und Wenn schon MultiThread, dann verschiedene Thread erstellen, um die Anderen Objekte (z.B. NPCs) zu positionieren und "Leben" zu lassen. Allerdings sei vorsicht geboten. Als ich mal im Netz einen Artikel mit dem Thema "Tips zur Mutli-Thread programmierung" gelesen hab', war der erste Tip: Lasses, wenns nicht wirklich zwingend Notwendig ist!

Außerdem ist es nicht garantiert, das durch einen extra Render-Thread die sache Schneller läuft, da dieser Thread bei einem Single-Prozessor System auch nur zwischen druch läuft und sich seine Resourcen mit den anderen Threads teilen muss. Also ein Thread mehr klaut sich (mal ganz ganz simpel und einfach gesprochen) Zeit von jedem anderen Thread. Ein bisschen was mag's shcon bringen, aber ob's das wirklich 'rausreißt verglichen mit dem Programmier-Aufwand (Verwalltung verschiedene Threads, Fehleranfälligkeit, ...) ist die Frage.

Also bleibt nur noch eine eigene Loop wie z.B.

while Runnging do
Render;
Application.ProcessMessages;
end;

Aber dann kann man ja eigentlich gleich im OnIdle arbeiten, da hier die gleichen Anweisungen abgearbeitet werden. (Durch das ProcessMessages). Und das Problem mit der ALT und F10-Taste kann man umgehen (siehe Thread "Alt"er Fehler, <a href='http://www.phobeus.de/hosting/dgl/forum/viewtopic.php?p=5139#5139)' target='_blank'>http://www.phobeus.de/hosting/dgl/forum/vi...hp?p=5139#5139)</a>. Isses nun wirklich sonnvoll, sich ein Bein 'rauszureisen um ein paar ms zu sparen, die nacher im Endeffekt sich nicht wirklich bemerkbar machen? Denn Optimierung eines Programms ist nicht nur die Renderloop. Mann sollte bei Seiner Level-Darstellung, Script-Sprache, Eingabeverarbeitung etc., eben dem ganzen drum herum, anfangen zu optimieren.

Was sind eure Meinungen / Gedankengänge?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Zum Thema Geschwindigkeit kann ich nur Sagen, dass es relativ egal ist ob man in einem Thread, onIdle oder in einer Whileschleife rendert.
Ein Thread ist nicht schneller. Eher sogar etwas langsamer. Weil er synchrinisiert werden muss. (Da sehe ich ein großes Problem für unerfahrene Programmierer. Was muss nämlich alles Synchrinisiert werden?) Der große Vorteil an einem Thread ist, dass diese unabhängig vom Rest läufen.

Bestes Beispiel für einen solchen. Du hast eine Map in der Größe 40000x20000x2byte (ca. 1GB) Diese Map kann man unmöglich an einem Stück laden. Mit 2 Threads kann man dieses Problem recht leicht erschlagen. 1 Thread lädt ein Stücke aus der Map. Der andere hingegen rendert das. Das alles in 1 Thread zu machen ist purer Selbstmord. (weil das Rendern für den Ladevorgang unterbrochen werden müsste)

Ein anderes Beispiel wo Threads sinn machen ist bei einem Webspider. Dort warten die Thread die meiste Zeit auf die Server der Webseiten. Man kann also gleichzeitig mehrere Webseiten auf einmal ziehen.
Dadurch hat man ein paar Vorteile.
- Die Anwendung blockiert nicht wärend des Downloads (bzw. Seitenhängern).
- Man ist viel schneller fertig.
- Und nutzt seine Resourcen besser (DSL, Standleitung)

Merke! Threads lohnen nur dann, wenn man mehrere Dinge gleichzeitig machen muss. bzw wenn die Anwendung (VCL-Thread) durch irgendetwas blockiert werden könnte man aber gleichzeitig noch dinge machen muss (rendern).

Eben, so dachte ich mir das auch. Gut, das mit der Map iss natürlich krass. Aber durch aus möglich (z.B. Ultima 9. Riesen Areale!) Aber dennch sollte man sich die Verwendug von Threads wirklich überlegen. Und wenn man sie verwendet, muss man sie gut durchdenken und durchplanen!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Also, ich hab' soeben festgestellt, das vor OnIdle noch einige Überprüfungen duchgeführt werden (Welches ist das aktuelle Control, wo ist die Maus, ...). Wer sich das Sparen will (wobei das wahrscheinlich wirklich nix ausmacht), kann eine eigene Loop erstellen. Ansonsten gibt es wirklich keinen Größartigen unterschied zwischen Application.ProcessMessages und einer eigenen Loop. Hm...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Höhendaten der Erde in 1KM Auflösung incl. 3GB Textur (ebenfalls 1KM Auflösung).


Das ist durchaus richtig. Auch ein erfahrener und profesioneller Programmierer kann dabei schon graue Haare bekommen. Ganz zu schweigen von einem "Anfänger" oder nicht ganz so Erfahrenem.
Denn woher soll jemand Threadunerfahrenes wissen, was man Synchronisieren muss und was man getrost sein lassen kann.

Die Whileschleife würde ich persönlich aber auch nicht so ganz empfehlen.
Ich denke, wenn die anwendung etwas viel zu tun hat. So 1 bis 2 (die Stunde) dann werden ja auch alle Ereignisse (Messages von Windows, Benutzereingaben) nur all 1 bis 2 Tage abgearbeitet. Ich für meinen Teil finde das nicht so vorteilhaft.

Bleibt also nur das OnIdle. Was ist den meisten Fällen ja auch super ausreicht.

Stimmt nicht ganz, denn wenn ich Application.ProcessMessages mach, werden ja alle Nachrichten von Windows verarbeitet. Also

While Running do
begin
DoRender;
Application.ProcessMessages;
end;

gibt dann kein Problem. Für Eine Anwendung, die massig Berechnungen von ein Paar Stunden durchführt, kann man ja nichtmehr von RealTime-Rendering ausgehen. Wenn Deine Anwendung allerdings bei DoRender 2 Stunden läuft, bis die Funktion verlassen wird, dann bringt die auch OnIdle nix, denn OnIdle, wie der Name ja sagt, wird nur dann aufgerufen, wenn das Programm gerade in keiner Funktion "steckt" und keine Windows-Messages verarbeitet werden müssen. Deswegen ist bei Schleifen (wenn man z.B. die Festplatte nach 'ner Datei durchsucht) Application.ProcessMessages aus irgendwie pflicht! Wie auch immer.

Ich schätze, OnIdle dürfte die beste und ausreichende Möglichkeit sein. Für die, welche noch 'n Paar MS 'raushlen wollen, di ekönnen die While-Schleife verwenden. Aber mal ehrlich, die Abfragen, die VOR OnIdle von Application ausgeführt werden, dürften wohl wirklich nicht mehr stören, denn wir reden Heutzutage von Prozessoren bis zu 3 GHz. Allerdings dürfte der Durchschnitt Prozessor bei 700 MHz liegen.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?