Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Quadtree und Fragen dazu

Werbeanzeige

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

81

08.11.2012, 22:07

Ja, da gibts leider noch nix, aber Tasks sind afaik spätestens für die nächste major Revision des Standard geplant, der 2017 kommen soll (2014 kommt eine minor Revision, dazwischen sollen mehre Library Updates in Form von Technical Specifications kommen)...

Unbedingt zu empfehlen: http://channel9.msdn.com/Events/Build/2012/2-005
m4studios

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

82

08.11.2012, 22:32

Na 2017 ist ja quasi vor der Tür und bis die gängigen Compiler das unsterstützen dürfte es auch spätestens 2019 sein. Fröhliche Weihnachten. :D
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

83

08.11.2012, 23:04

2017 wird die nächste major Revision. Technical Specifications für Filesystem und Networking kommen laut oben verlinktem Talk schon nächstes Jahr, das aktuelle Proposal von ersterem ist in VS 2012 bereits verfügbar, die nächste minor Revision des Standard kommt 2014 aka übernächstes Jahr und wird hoffentlich bereits Dinge wie Reader-Writer Locks und eine Concurrent Queue enthalten, mit denen man Tasks dann zumindest wohl sehr einfach schon selbst basteln kann. Man bedenke, dass es nichtmal ein Jahr gedauert hat, bis die meisten Compiler einen Großteil von C++11 umgesetzt hatten...

Und Visual C++ bietet mit der Concurrency Runtime bereits seit 2010 ein sehr sehr mächtiges Framework...
m4studios

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (08.11.2012, 23:09)

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

84

09.11.2012, 06:32

Einen Großteil? Ich habe gestern gelesen, dass VC2012 weniger als die Hälfte der Features enthält. Ich weiß nicht, klang für mich nicht nach dem Großteil. Aber soll mir auch egal sein. Für mich klingt 2014 und 2017 halt doch etwas sehr weit weg für Dinge, die ich am besten gestern schon gebraucht hätte.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

85

09.11.2012, 07:27

Wie gesagt, für Windows bietet die Concurrency Runtime bereits alles was das Herz begehrt, abgesehen davon gibts in VC++ die PPL und AMP, durch letzteres wird sogar Heterogeneous Computing (GPU, APU etc.) direkt aus VC heraus möglich. VC++ hinkt lediglich was C++11 angeht leider noch relativ weit hinterher, aber die Standardbibliothek ist selbst in VS 2012 bereits (fast) vollständig; was Sprachfeatures betrifft, sind clang, GCC und ICC allerdings wesentlich weiter...
m4studios

Horus

Treue Seele

  • »Horus« ist der Autor dieses Themas

Beiträge: 251

  • Private Nachricht senden

86

09.11.2012, 09:00

Jetzt kann ich überhaupt nicht mehr folgen :dead:

Zitat

Und permanentes Yield() der Worker Threads ist eine Katastrophe für die Leistung des Gesamtsystems - da fängt alles an zu ruckeln, selbst der Mauszeiger, weil Windows mit x Millionen Task Switches pro Sekunde beschäftigt ist.
Ich habe Yield() natürlich getestet. Ganz so schlimm war es nicht aber die Leistung war halbiert.


Aber Dot! Mit dem ManualResetEvent hat es funktioniert! :thumbsup: :vain:
An meinem Laptop ist der Leistungsgewinn immens! Die erwarteten 3ms werden übertroffen.

LG


EDIT:
Doch nicht. Leider kommt es, wenn auch selten dazu dass es nicht funktioniert. Der Thread wird dann nicht fortgesetzt. :dash:

So sieht es im EngineThread aus:

C#-Quelltext

 
1
2
3
4
5

FinishedThreads = Config.InitThreads;
for (int i = 0; i < Config.InitThreads; i++)
    ThreadPool.UnsafeQueueUserWorkItem(PhysicalSimulation, i);
ManualEvent.Reset();
ManualEvent.WaitOne();


Die einzelnen aufgerufenen Threads enden mit:

C#-Quelltext

 
1
2
3

Interlocked.Decrement(ref FinishedThreads);
if (Interlocked.Equals(FinishedThreads,0))
    ManualEvent.Set();



EDIT2:
Jetzt gehts halbwegs. Die Funktion für die Wände des Simulationsraumes wird jetzt in weniger Threads aufgeteilt. Jeder Thread dieser kleinen Funktion wurde so extrem! klein, dass es passieren konnte, dass das ManualEvent.Set(); vor dem ManualEvent.Reset(); gesetzt wurde :D 100% ig geht es aber bisher nicht.

Einzig die Prozessorlast liegt bei ~100% Das ist schonmal sehr gut!

EDIT 3:
Jetzt klappt es. Mit:

C#-Quelltext

 
1

ManualResetEvent[] ResetEvents = new ManualResetEvent[Config.InitThreads];

Also einem Array von Resetevents und folgendem Aufruf.

C#-Quelltext

 
1

ThreadPool.UnsafeQueueUserWorkItem(new WaitCallback(PhysicalSimulation), (object)i);

Bei obiger Schreibweise kann man auch einen Parameter Übergeben! :thumbsup:
Bilder zu meinem Projekt: ParSim

Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »Horus« (09.11.2012, 14:46)

Horus

Treue Seele

  • »Horus« ist der Autor dieses Themas

Beiträge: 251

  • Private Nachricht senden

87

10.11.2012, 09:48

Sooooooo!

Ich weiß momentan nichts mehr zu verbessern. ;(

Partikelsystem - Multitheading.rar
Ihr könnt das 500kb große Meisterwerk herunterladen. FALLS es überhaupt jemanden interessiert. :D Aber nicht meine Ideen klauen X( ... ...Nur Spass ^^

Hier schließt sich allerdings noch eine Frage an, Wenn ich Zeiger verwende und unsave programmiere, in welcher Größenordnung wären die Vorteile?
eher 1% mehr Leistung oder eher 50% oder wie. Lohnt sich das was schätzt ihr?

Ich speichere Alle Partikel- Indizes in einerm 2D Array. Je nach ihrer Position im Simulationsraum. Dieser 2D Array besteht aus int Variablen. Ob Zeigerarytmetik was wäre für diesen Zweck. ?(

LG
Bilder zu meinem Projekt: ParSim

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Horus« (10.11.2012, 09:55)

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

88

10.11.2012, 09:54

Kommt immer drauf an, was man macht. Bei Dir vermutlich so gut wie keine Mehrleistung. Was sich aber wirklich lohnt ist Bildbearbeitung. Da geht man mit den C# Klassen wie Graphics und Color total am Stock.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Spiele Programmierer

Alter Hase

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

89

10.11.2012, 11:25

Ich habe mal das Chaosspiel in C# implementiert und da hat sich, soweit ich das noch in Erinnerung habe, konnte ich die Performance sehr deutlich steigern.

Es kommt im Prinzip immer darauf an, wieviel Zeit du mit Rechnen und wieviel Zeit du mit Daten holen\schreiben du verbringst.
Mit Zeigern kannst du zweiteres deutlich beschleunigen.
Ersteres könnte zb. mit SSE beschleunigt werden.

EDIT:
Du könntest noch einen Geschwindigkeitsvorteil durch das einbeziehen der GPU erreichen.
Beispielsweise mit OpenCL, ComputeShader oder Cuda

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Spiele Programmierer« (10.11.2012, 11:43)

Horus

Treue Seele

  • »Horus« ist der Autor dieses Themas

Beiträge: 251

  • Private Nachricht senden

90

10.11.2012, 16:16

Zum Thema Zeigerarythmetik:
Ok, ich muss mal überprüfen wie viel Zeit das Updaten des Grind benötigt. Konkret habe ich das nie nachgemessen, da ich nicht so richtig weiß wie.
Ich muss mal eine Stopuhr-Klasse schreiben oder so. Oder gibt es das bei c# :D

Ich weiß aber mit Sicherheit, dass die Kollisionserkennung am aufwändigsten ist.

Das Grid umfasst 512*512*4 = 786.432 also 1.048.576 int Variablen.
Ich setzte mal voraus das bei durchschnittlicher Bewegung ca 10% der 32.768 Partikel also 3.276 Partikel ihre Position Ändern. Dabei werden jeweils die Indizes wie auch der Counter des Sektors geändert. Es steht 50/50 dass andere Partikel "Aufrücken" müssen. Also muss ich schätzungsweise 3276 * 3 = 9.828 int variablen pro Frame ändere, um das Grid "up to date" zu halten. :wacko:
Das ist nicht so mega viel oder?

Ist es schwer mit Zeigern zu arbeiten ..? nicht besonders oder?


Zum Thema Grafik:
Jetzt habe ich Open CL gegoogelt. Ist mir alles neu. Aber wenn ich das richtig werstehe bin ich damit von XNA weg?


Allgemein
SSE klingt auch interessant. Ob mir das gelingt mit C#, da muss ich mich noch mehr informieren.

Danke erstmal für die Tipps!

LG


EDIT
Achja, hat mal einer die Engine von der "Architektur" her angeguckt oder so ob ich da so weit sinnvoll vorgehe. Klassen zu benutzen bin ich nicht sonderlich geübt glaube ich.
Bilder zu meinem Projekt: ParSim

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Horus« (10.11.2012, 16:23)

Werbeanzeige

Ähnliche Themen