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!

100 Screenshots in der Sekunde

  • 1
  • 2

Werbeanzeige

iF

Frischling

Beiträge: 11

  • Private Nachricht senden

11

08.12.2009, 16:43

Zitat

ich möchte ein kleines Programm schreiben welches einen Screenshot macht und ihn mit den Screenshot den es davor gemacht hat vergleicht. Das ganze müsste ca 100 mal in der Sekunde gemacht werden ohne dabei großartig das System zu belasten! Embarassed
Nach ein wenig suchen bin ich auf die BitBlt Methode gestoßen.

Wie schnell würde das ganze ablaufen? Ist das überhaupt machbar?

Nicht machbar bei aktuellen Homecomputern: Du kannst zwar ohne grosse CPU-Last mehrere Hundert BitBlit-Operationen anweisen und von der HW-Beschleunigung auch ausführen lassen - aber sobald Du selbst die "Pixel"/DIB-Daten beziehst und sogar verarbeiten möchtest wird es nicht mehr "ohne dabei großartig das System zu belasten" - Beispielsweise wäre ein 12-GHz QCore auf ~1,5 Prozessoren 100% ausgelastet.

Es sind (leider) zur Zeit zu viele Pixel die Du da 100x pro Sekunde verarbeiten möchtest - selbst wenn die Verarbeitung rein in Assembler geschrieben ist: nicht ohne deutliche Last. Das kannst Du auch ausrechnen, Pixel zur Zeit im Normalfall 32-Bit breit sind.

Crush

Alter Hase

Beiträge: 383

Wohnort: Stuttgart

Beruf: Softwareentwickler

  • Private Nachricht senden

12

08.12.2009, 23:22

Die schnellste Methode wäre es, den Bildschirm in einen von 2 Buffern zu grabben und dann eine Bitblt-Operation (SRCERASE oder SRCINVERT) durchzuführen. Dann reicht eine simple Leerschleife zur Prüfung aus, sobald irgendwas anderes als 0 rauskommt gab es eine Änderung. Da die SRC Bitmap nicht geändert wird, brauchst Du nur beim nächsten mal den Bildschirm in den anderen Buffer einzulesen und wiederholst alles.

Du könntest das ganze etwas beschleunigen, indem Du zu einem Frame den Bildschirm grabbst und dann den Folgeframe mit SRCERASE/SRCINVERT direkt auf dessen Buffer grabst.

Ludwig

Frischling

  • »Ludwig« ist der Autor dieses Themas

Beiträge: 29

  • Private Nachricht senden

13

09.12.2009, 16:30

Ok in der Theroie habe ich das verstanden ! :roll:

Nur : Mit grabben meinst du auch die Infos (Pixel) mit mit Bitblt kopieren?
wenn ich 2 Buffer habe und die mit SRCERASE oder SRCINVERT "bearbeite" verbinde ich doch die Bildinfos oder ist das eine Abfrage ob die Pixel gleich sind , ansonsten werden sie nicht übernommen ?


Const SRCERASE = &H440328
' Kombiniert die invertierten Farben des Zieles mit den Farben der Quelle
' mit Hilfe des AND-Operators

Const SRCINVERT = &H660046
' Kombiniert die Farben des Zieles und der Quelle mit Hilfe des XOR-Operators


0 sollte dann doch auch nur zurückgegeben werden wenn was schief läuft.

Und wie ist das mit der Leerschleife gemeint?

danke schonmal
Ludwig

Crush

Alter Hase

Beiträge: 383

Wohnort: Stuttgart

Beruf: Softwareentwickler

  • Private Nachricht senden

14

09.12.2009, 17:40

Ja, das grabben geht auch mit Bitblt. (CWnd * pwndGrabscreen = FindWindowW(0, Windowname), man kann sich aber auch über GetDesktopWindow() durchhangeln)
Die Rückgabe der Funktion ist was ganz anderes. Das hilft Dir nicht weiter.
Das Ergebnis ist im Destination sollte immer 0 sein (durch das XOR), weil sich die gleichen Bits vom aktuellen Bildschirm und dem Vorherigen aufheben. Du mußt also noch in einer Schleife einfach schauen ob irgendwo etwas anderes als 0 auftaucht.

Werbeanzeige

  • 1
  • 2