Das Spiel darf nur etwas in den Speicher schreiben, wenn das Flag nicht gesetzt ist. Und nachdem es fertig ist muss das Flag gesetzt werden. Die Anwendung darf den Speicher nur auswerten, wenn das Flag gesetzt ist und darf es erst löschen, wenn sie fertig ist. So sollte es eigentlich nicht zu Problemen kommen. Nicht mal auf DualCore maschinen.

Aber dann muss 100%tig dafür gesorgt werden, dass niemand Anderes in den genuss des Hooks kommt. Also Hook lässt sich nicht kontrollieren aber der Code darf nicht ausgeführt werden. Keine Anwendung und kein zweites Spiel (ja so was habe ich auch schon gemacht. ). Denn ansonsten kann es zu Problemen kommen.

Nichts desto trotz würde ich eher betriebsysteminterne Methoden empfehlen. Die sind einfach sicherer.


PS: Wenn an der Größe des Speichers oder dem Speicherbuffer (nicht inhalt) nicht rumgefummelt wird sollte es maximal zu dem V-Sync typischen aussehen kommen. Denn gegenseitiges Lesen und Schreiben wird da nichts abschießen sondern nur die Daten verunstalten. Sofern sich mehrere OpenGL Anwendungen nicht in die Quere kommen.

ok moment.
tut mir leid für den stress - aber das forum war heute offline als ich meinen post noch ändern wollte .

1. ich hab einen hook auf wglswapbuffer ( was glaub ich eh klar war oder? ).
2. ich lese im hook mit glreadpixel in einen sharedmemory ein.
also erzeuge ich einen shared memory und schreibe gleich dirrekt über den pointer in den memory.
3. momentan schicke ich eine WM_USER windows message an mein programm wenn der screenshot fertig ist.
im wparam ist breite und im lparam die höhe des bildes.
den bitmapheader bau ich erst in meinem endprogramm ein - also lese ich die rawdaten aus dem shared memory.
4. grundsätzlich lese ich in meinem programm nur aus dem shared memory.

Geplante änderungen sind jetzt:
1. ich kann die größe des bildes auch in den shared memory speichern - einfach als int vor dem bild - damit kann ich events oder mutex oder ähnliches als benachrichtigung nehmen - dem trau ich mehr als einem sendmessage.
2. einen echte synchronisation findet nicht statt - bisher hol ich jedes frame einen screenshot und das funktioniert recht gut.
ich bin damit bei ca. 10 frames pro sekunde ( das bedeutet das viele messages nicht ankommen bei meinem programm - im spiel hab ich immer noch 80-90 frames )
Das funktioniert deshalb sehr gut, weil ich momentan für jedes frame einen neuen shared memory erzeuge.
Wenn also die nachricht an mein programm kommt, dann macht der den aktuellen shared memory auf ( macht windows mit dem namen für mich ). Dieser wird nicht überschreiben, weil ich ja immer neue öffne. - Danach schließe ich den wieder.

Das ganze wird dadurch allerdings kompliziert - das wirklich gut zu implementieren wird mich wohl noch etwas beschäftigen.
Ich will das gut steuern können wann ich einen sc hole und auch wieviele.

Hoffe das klärt mal einiges auf.
lg

Theoretisch nicht unbedingt, die CPU kann die Befehle in ihrer Reihenfolge teilweise ändern.

_________________

ja klar - er kann jederzeit auch wieder den gleichen speicherbereich überschreiben.
aber es funktioniert momentan sehr gut - ich bin gerade am vermüntigen synchronisieren und werde mir ein konzept überlegen müssen, wie ich das gut implementiere.

Wirklich schade ist einfach, das das abfragen vom Viewport nicht funktioniert - ich würde sonst ganz auf die windows api in dem bereich verzichten.
Grundsätzlich ist geplant nur einen ShMemory zu benutzen - dort vor dem raw bild die auflösung zu speichern ( die kann sich ja wärend des betriebes ändern ).
Und das ist auch schon die schwieriegkeit - ich muss die größe des ShMemory auf das bild anpassen - also bei jeder auflösung ändern.
Entweder ich speichere das ganze bitmap mit integriertem Header in dem memory und hol mir vorher den Header bereich und lese die auflösung aus, berechne die neu und hol mir dann das bild.
Oder ich speichere die größe des bildes und hol mir nur die raw daten, erstell dann den header und verarbeite das dann.

Momentan spiel ich mich mal mit den mutex um eine gute synchronisation hin zu bekommen.
Ich plane ausser Mutex ganz auf windows api zu verzichten ( abgesehen vom hook und den windowinfos ).
Das sollte die Geschwindigkeit noch etwas erhöhen - ausserdem die synchronisation verbessern.

mal sehen wie weit ich damit komme ....

lg
Arnulf