Hallo!

Nachdem ich einfach mal Lust hatte wieder mehr 3D zu machen als zu spielen (da verlier ich ja immer ), hab ich mich also hingesetzt und OpenGL Tuts gelesen. Geht auch alles ganz prima, bis auf...

irgendwie hab ich (aufgrund des eingesetzten Frameworks nehm ich an) eine OnIdle Renderschleife nicht hinbekommen. Also war die logische Idee: Multithreading, ein Thread kommuniziert mit Windows, einer rendert.

Und jetzt die Frage: Kann es sein, dass nur der Thread den HGLRC nutzen kann, der ihn auch erstellt hat? Meine Versuche deuten in die Richtung, aber kann das irgendjemand bestaetigen?

Nebenfrage: Wir macht ihr die Renderschleifen so?

_________________
Was zum Nachdenken: (define (dosomething a b) ((if (< b 0) - +) a b))

Indeed... ich glaube ich habe sowas auch gelesen, dass der HGLRC zumindest nur pro Thread 1x eingesetzt werden kann und vermutlich ist, dass dann auch deine Beobachtung. Schau mal beim RedBook nach, da müßte sowas erwähnt sein

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Danke fuer die Antwort, hab mal in meinem RedBook-eBook nach Thread gesucht:

Remember that only one context can be current for any thread at any one time.

(Aus Appendix D, GLX Functions).

Soweit ist das ja logisch und klar. Nur das verbietet ja nicht, den Context zwischen Threads hin und herzuschieben, oder versteh ich das falsch?

An sich ist das mittlerweile auch nur noch informationshalber, ich hab mich damit abgefunden dass es so zu sein scheint.

Zur Zeit gibt es nur 2 Faelle, wo ein anderer Thread meinen Context nutzen muesste (WM_SIZE,WM_PAINT), und da hab ich mir einen Communicationsmechanismus gebaut, der auch sehr gut funktioniert.

Falls aber jemand was definitives weiss, waere ich fuer ne Mitteilung dankbar.

Viel Spass beim Coden,
--Prometheus.

_________________
Was zum Nachdenken: (define (dosomething a b) ((if (< b 0) - +) a b))

Mein ich doch, dass ich das da irgendwo gelesen hatte
Aber defintives kann ich nicht sagen... auf jeden Fall interessierts mich auch. Also auch wenn Du was findest, lass uns nicht dumm sterben

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Du kannst einen HGLRC in mehrern threads benutzen(selbst ausprobiert). Hab ich mich jetzt verlesen oder steht da gar nicht dein problem? Das einzige was mir grad so einfällt, ist dass die VCL nicht gerade begeistert reagiert, wenn man mit einem Thread in einem Fenster zu zeichnen anfängtst ohne das mit Synchronize zu machen....

Danke fuer deine Antwort. Wenn das bei dir klappt, also von einem Thread aus den in einem anderen Thread erstellten HGLRC zu nutzen, so denke ich mal frech, das es an meinen Treibern liegt, dass das bei mir nicht klappt.

VCL/Synchronize: ja ich weiss. Das ist auch der Grund, warum ich gar keine VCL nutze (ueberhaupt nutzen koennte: ich programmiere in *selbstzensiert*)

_________________
Was zum Nachdenken: (define (dosomething a b) ((if (< b 0) - +) a b))

Vielleicht kann man zu diesem Multi-Thread-Problematik ja auch mal ne Sample veröffentlichen? Ist sicherlich schon "hardcore" wissen, aber auch da haben wir ja interessierte, gell Prometheus

8O 8O 8O *zensiert.seh* ... ich empfange gedanklich negative Schwingungen... sehr böse Schwingungen. Verlasse nicht den dunklen Pfad Prometheus, sonst wirds dir irgendwann noch einmal sehr ... sehr... sehr... gut gehen

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Hi,



Ganz so einfach ist das nicht, denn es gibt zwischen der Erzeugung eines Threads mittels API oder eines TThreadobjektes gewaltige Unterschiede.
Sobald du die API CreateThread verwendest, musst du auf alle Sachen verzichten, in der dir der MemoryManager die Arbeit abnimmt (Objekte, AnsiStrings, quasidynamische Arrays).
D.h. du kannst gleich C verwenden, da du dich um Speicherbelegung, Speicherbereinigung selber kümmern musst (oder verwendest nur statische Variablen).

Bei der Synchronisation stellt Delphi schon ein TMultiReadExclusiveWriteSynchronizer-Objekt bereit.
Bei der API kannst du dich mit "Mutex Objects", "Semaphore Objects" und "Critical Section Objects" rumschlagen.

Was schließen wir daraus? Er müsste 2 Tutorials verfassen, eines für die API-Leute und eins für Objektfetischisten (wie mich).

MfG other.

_________________
Hilfe.

*lach* Oki... bisher habe ich mich um Threads in der API gedrückt, allerdings spricht ja nichts dagegen da zwei drauß zu machen ;D Freiwillige vor

Hofft, dass sich nun mindestens 2 Millionen Progger melden und er sich die besten raussuchen kann *keuch*

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

@other:

Wieso 2 Tuts? API und Objekte verbinden schliesst sich doch nicht aus.

Selbstzensur aufgehoben:

Ich nutze immer noch die Sprache wo nur die Leute so schlecht sind (gell Phobeus *gg) und dabei dann die WinAPI und die sehr gute Klassenbibliothek, die mir listen, dyn. arrays, usw. usw. bereitstellt.

Das is so wie in Star Wars....die boese Seite der Macht bietet viele Vorteile, man muss nur die Nachteile ignorieren koennen.


Sample:

Ich ueberlege einfach ein Sample zu bauen, das so funktioniert:

2 Threads, einer erzeugt den RC, und loescht ihn mit weiss.
Der Zweite Thread bekommt den RC, und versucht ihn mit Schwarz zu loeschen.

D.h. man kann dann wirklich sehen, bei wem es geht, und bei wem nicht.
(Irgendwie kommen wir schon wieder auf die Dunkle Seite...alle bei denen es Schwarz wird sind boese! *harhar*)

_________________
Was zum Nachdenken: (define (dosomething a b) ((if (< b 0) - +) a b))

Hallo,



1 Tutorial über TThread und dessen Synchronisationmethoden
1 Tutorial über CreateThread, Synchronisationsmechansimen und Hinweise, welche Probleme auftreten können





Objectpascal?



Ich wäre dafür ein Beispiel zu schreiben, wo Synchronisation auch Sinn macht.
Beispiel:
1 Thread kümmert sich ums Zeichnen
1 Thread übernimmt den Input und ändert z.B. die Position von Objekten

Beide Threads müssen nun synchronsisiert werden, so das nicht während des Zeichnens ein Objekt neue Koordinaten bekommt und es nicht mehr zu der Szene passt.
Da gibts eine Menge Beispiele ...

Und man sollte bedenken, dass es neben beiden Threads noch den Thread gibt, der den Prozess erzeugt hat .

edit

In Zeiten von Objekten sollten wir uns wohl besser mit TThread beschäftigen, schon allein um Leuten, welche keine Borlandprodukte einsetzen, Futter zu geben .

<span style='color:blue'>Don't feed people without VCL 8).</span>

MfG other.

_________________
Hilfe.

@other: Der Spruch ist gut... der ist gemerkt Nicht wahr prometheus... bleib Du ruhig auf der "guten Seite" und spüre die dunkle Macht zu spüren ...

Aber ich denke beides wäre irgendwo interessant und hätte auch seine daseins berechtigung. Wenn sich also jemand mal langweilen sollte, ich bekomms momentan nicht auf den Speiseplan... zuviel arbeit mit der Page momentan

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Hallo,



Vergiss aber bitte das "peoples".



Vielleicht kann man ihn irgendwann wieder bekehren .
Ich wüsste nur zu gerne, welches Produkt er bei größeren Projekten einsetzt, wo sehr viel Zeit in eine vernünftige Oberfläche investiert werden muss und die Standardfenster nicht erwünscht sind.



Immer diese prozedualen Programmierer !



Echt? Man sieht ja gar nichts .
Jedenfalls ist so ein Tutorial nicht so leicht zu realisieren, wie man denkt.
Da gehört IMO eine Menge Erfahrung dazu, da es gerade bei Multithreaded-Applications zu vielen Problemen kommen kann.

MfG other.

_________________
Hilfe.

Yep ))


Genau so muss man es machen... nicht auf die vielen, zahlreichen und vor allem fatalen Schwächen, wie z.B. der mangelden Benutzerfreundlichkeit, der hässlichen IDE, den vielen unvergorenden Standard etc... bloss nicht darauf hinweisen, sondern lieber nur die Vorteile von Delphi zeigen... ahem... ich versuchte Bewußt anonym zu bleiben


Mit Keule droh... Frechheit Nein, nein... bereite gerade ne Umzug vor


Aus zuverlässigen Quellen habe ich in Erhfahrung bringen können, dass genau Du diese Erfahrung bieten kannst

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Hallo,



*3-Schritte-Zurück-Geh* *fürcht*



Wo ziehen wir denn hin? Im Dorf ist es immer noch am schönsten 8).



Möge man mir diese Quellen zeigen.
Sollte es sich um eine Person handeln, so möge man dessen Namen erwähnen, damit ich dieses Schandmaul für immer stopfen kann .
Um es genau zu sagen: Dem ist leider nicht so.
Die Erfahrung bewegt sich wohl eher auf unterem Niveau (tiefer ... noch etwas tiefer ... ganz tief ... genau .. da unten), so dass ich nur ein wenig Basiswissen habe (irgendwo aufgeschnappt), aber keine Erfahrung .

MfG other.

_________________
Hilfe.