(ich hatte euch letztens wegen der ausgabe eines Strings über den Com gefragt, da die daten davon aus einem spiel währen eines Bildframes generiert werden,
ist die ausgabe über com zu langsam. LEIDER)

ABER VIELEN DANK FÜR DIE TIPPS VON EUCH !!

Aber ich gebe nicht so schnell auf !

Hintergrund:

ich versuche das Plugin vom Spiel

heruntergeladen bei

http://www.rfactor.net/downloads/utils/InternalsPluginsV3.zip
besteht aus:

RFPluginObjects.hpp
InternalsPlugin.hpp
Example.hpp

welches die Daten mit
FILE *fo = fopen( "ExampleInternalsTelemetryOutput.txt", "a" ); ca alle 10ms in eine Datei schreibt. ich möchte jetzt die daten in den gleichen shared memory bereich SCHREIBEN wie es unter:

http://www.x-simulator.de/de/programmieren/visualisierungs-interface.html

zum AUSLESEN erklärt wird.

(const char* SHAREDMEMORYSEGMENTID = "LCDHypeSharedMemorySegment";)
kompletter Code:
http://www.x-simulator.de/forum/source-code-visualisierungs-interface-t783.html
in VisualSample.rar

Wenn mir da gelingt ( mi euere Hilfe) kann ich die restliche Software weiterbenutzen !

Nur zum Verständnis : Der Shared Memory bereich wird nur durch den Namen ausgewählt ?

Gruß dirk

Nur zum Verständnis : Der Shared Memory bereich wird nur durch den Namen ausgewählt ?

Ja, unter Windows funktioniert das so.

ich habe mich dazu entschieden, diesen schon etwas älteren Thread (den ich über die suche gefunden habe) zu verwenden und keinen neuen zu starten, da das Thema sehr nah an meinem Problem liegt.

Ich schreibe gerade ein Plugin für rFactor, das Daten als Overlay im Spiel visualisiert. Dazu muss ich eine d3d9.dll ins rFactor-Verzeichnis legen, die einige Direct3D calls abfängt, weiterleitet und ggf. eigene dazwischenstreut (zumindest sehe ich keine andere Möglichkeit). Dummerweise habe ich dann in diesem Code keinen direkten Zugriff auf die Telemetriedaten, die ein normales rFactor Plugin ausspuckt, da offensichtlich komplett getrennte Speicherbereiche verwendet werden.

Ich suche nun nach der effizientesten Methode, die Telemetriedaten dem d3d9.dll Thread (oder Prozess?) zur Verfügung zu stellen. Bisher mache ich das über UDP. Aber das ist mit Sicherheit nicht gerade schnell im Vergleich zu anderen Lösungen wie z.B. Shared Memory. Ich habe auch schon den Ansatz mit MemoryMappedFiles gefunden. Aber das erscheint mir zum einen etwas unschön und zum anderen potentiell langsam, da evtl. Festplattenzugriffe getätigt werden müssen.

Könnte mir vielleicht jemand sagen, welchen Weg ich gehen sollte? Er darf ruhig Plattformabhängig sein, da rFactor nunmal nur auf Windows läuft. Und alles ältere als Windows XP ist auch vernachlässigbar.

Am liebsten wäre mir eine Möglichkeit gewesen, einfach nur die Adresse des Pointers zu senden, die sich während der Laufzeit nie zu ändern scheint, und dann ohne jeglichen Kopiervorgang auf die Daten zugreifen zu können. Aber ich werde wohl nicht um das Kopieren der Daten herumkommen (oder doch?).

Es wäre sehr cool, wenn ich zu der Lösung auch die nötigen Befehle für die beiden Seiten bekommen könnte, da ich in C/C++ nicht so fit bin. Ich möchte im C-Plugin nur das nötigste machen und so viel wie möglich in Java auslagern.

Ich hoffe, mir kann jemand helfen,
Gruß,
Marvin

d3d9.dll Thread (oder Prozess?)

Waere gut, wenn du weisst, um was es sich handelt. Ansonsten gibt es nur allgemeine Ratschlaege wie Pipes, shared memory, memory mapped files oder sockets.

C-Plugin nur das nötigste machen und so viel wie möglich in Java auslagern.

Jaca + C koennte ein zusaetzliches Hindernis sein.

knivil schrieb:

d3d9.dll Thread (oder Prozess?)

Waere gut, wenn du weisst, um was es sich handelt. Ansonsten gibt es nur allgemeine Ratschlaege wie Pipes, shared memory, memory mapped files oder sockets.

Ich kann leider nicht in rFactor reinschauen. Und ich weiß auch nicht, wie Direct3D intern funktioniert oder wie sein Threadingmodell aussieht. Daher kann ich das leider nicht beantworten. Aber gehen wir doch einfach mal davon aus, dass es ein separater Prozess ist oder zumindest einen getrennten Speicherbereich benutzt, so dass ich die Daten kopieren muss. Ich nehme mal an, dass dann Shared Memory die schnellste Variante ist, oder? Könntest Du mir vielleicht dazu eine Beschreibung geben (also die nötigen Aufrufe für die schreibende und die lesende Seite?

knivil schrieb:

C-Plugin nur das nötigste machen und so viel wie möglich in Java auslagern.

Jaca + C koennte ein zusaetzliches Hindernis sein.

Nein. Das sollte eigentlich kein Problem sein. Das ist schon komplett gelöst.

Marvin