Lösungsvorschläge | Client-Server | Desktop übertragen

Das ändert nicht an der Tatsache, dass momentan die Farbwerte total durcheinander sind

Aber grundsätzlich...

babelduo

@Meep Meep
ja danke schonmal! darüber muss ich mir nun auch gedanken machen

ich habe hier mein projekt mal hochgestellt... vllt. findet ihr ja den
fehler mit den farbwerten - wär cool!

http://www.babelduo.de/screen.rar
(MFC-Anwendung Visual C++)

danke schonmal

p.s: wenn man Enter drückt gehts los...

Andromeda

DC->SetPixel (x,y, (red<<16 | green<<8 | blue)<<3);

Er hat damit aber noch immer einen Farbstich im Bild.

Hast du denn das Senden via Winsock schon hinbekommen?

hustbaer

Naja, zum Ausgeben solltest du das richtig hochskalieren.
Also (r << 19) + (g << 10) + (b << 3) wenn r, g, b in 16 bit 5-6-5 vorliegen.

Vielleicht bin ich einfach zu doof, aber ich fummel mir dabei einen ab
und erhalte, wie auch immer ich es anstelle, immer einen heftigen Farbstich
im Bild.

Bei mir seh ich auch nur ein lustig eingefärbtes Bild,...aber wems reicht

Was sagt der Threadersteller dazu? Gelöst?

hustbaer

blue = (*w) & 0x1f;
			green = ((*w)>>5) & 0x1f;
			red = ((*w)>>10) & 0x1f;

			DC->SetPixel(x,y,RGB((red * 8), (green * 8), (blue * 8)));

So, das funktioniert.
Das 16 Bit Format wo Windows verwendet wenn man bloss BI_RGB angibt ist halt RGB555. Natürlich muss das dann noch Faktor 8 hochskaliert werden...

Noch besser ist das, damit Weiss Weiss bleibt und nicht Grau wird:

DC->SetPixel(x,y,RGB((red << 3) + (red >> 2), (green << 3) + (green >> 2), (blue << 3) + (blue >> 2)));

Andromeda

hustbaer schrieb:

blue = (*w) & 0x1f;
			green = ((*w)>>5) & 0x1f;
			red = ((*w)>>10) & 0x1f;

			DC->SetPixel(x,y,RGB((red * 8), (green * 8), (blue * 8)));

[/cpp]

Ich möchte ja nicht aufdringlich sein, aber das entspricht genau meinem Vorschlag sechs Beiträge darüber

PS: Eine unterschiedliche Gewichtung der Farbkomponenten ist IMHO nur für LC-Displays nötig.

Naja, er wollte ja auch den differenten Teil ermitteln.
Dann muss er ja noch irgendwie eine Prüfung einbinden.

Ich kann mir nicht vorstellen, dass das so einfach bzw. schnell geht
und man das dann noch sinnvoll über Winsock senden kann. :xmas2:

hallo ^^

ja danke euch schonmal sind ja viele vorschläge hier... allerdings
habe ich bei den vorschlägen entweder einen blauen oder einen gelben
farbstich?

klappt denn ein vorschlag bei euch richtig?

@Fruggle
ja das mit über WinSock senden ist echt kompliziert
den vorschlag mit dem differenten teil ermitteln (also altes bild
- neue) find ich recht interessant...

man könnte das ja erstmal offline testen und halt immer wenn man ne
taste drückt (oder mit nem timer) wird nur der differente teil
neu gezeichnet...

wenn jemand auch lust hat da rumzuprobieren gerne - hier nochmal mein
projekt:

http://www.babelduo.de/screen.rar
(MFC-Anwendung Visual C++)

ich hab in den nächsten tagen wohl net so viel zeit...

aber vielen dank schonmal an euch

Bleib am Ball. Das hört sich alles sehr interessant an.
Werde mir das Projekt auch mal ansehen Poste hier doch mal,
wenn du weiter machst und bei dem Differenzieren bist.

hustbaer

babelduo, bist du doof? Ich habe es runtergeladen und ausprobiert und was ich zuletzt gepostet habe funktioniert. Nimm es oder lass es aber frag bloss nicht nochmal obs denn nu funktioniert. Probiers wenigstens aus du faules Stück *****.

@Andromeda:

Ich möchte ja nicht aufdringlich sein, aber das entspricht genau meinem Vorschlag sechs Beiträge darüber

Äh, ja, richtig. Wenn man die Korrektur von "0x1" -> "0x1f" noch dazunimmt die vom ursprünglichen Code ausgehend noch notwendig ist, hier aber schon zu sehen war... dann schon

Andromeda

hustbaer schrieb:

Äh, ja, richtig. Wenn man die Korrektur von "0x1" -> "0x1f" noch dazunimmt...

Es war nur ein Tippfehler. Das sieht doch ein Blinder mit Krückstock

hustbaer

In dem Rar-Archiv wo er hochgeladen hat ist dieser Tippfehler aber so drinnen -- egal ob Tippfehler oder nicht (ja, ich glaubs ja, so doof kann man nicht wirklich sein), funktionieren wirds mit 0x1 nicht

p.S. @XTC: was ist daran eigentlich so interessant? UltraVNC gibts doch schon... ?!?

CodeFinder

@hustbaer:
Sagmal, ähm, schlechte Laune ?^^

hustbaer

CodeFinder schrieb:

@hustbaer:
Sagmal, ähm, schlechte Laune ?^^

Ja, könnte man denken, was? ^^
Ich weiss nicht, mich nervt das halt wenn da eh bloss 2 oder 3 Vorschläge kommen, alle in 5 Minuten auszuprobieren, und 2 davon noch richtig (und praktisch identisch) ... und dann kommt "ja und was stimmt denn nu, bin grad eben zu faul selber nen Finger krumm zu machen, sagt mal, vielleicht interessierts mich dann auch genug dass ichs probiere" (sinngemäss).
*grummel*

Ok, @topic noch was:
Ne erste einfache "bloss Unterschiede übertragen" Version wäre: Screenshot machen, diff = screenshot XOR alter_screenshot, alter_screenshot = screenshot, diff mittels LZW/RLE/zlib komprimieren, abschicken.

Oder man könnte gleich ne Art "spezial RLE" machen, wobei man nicht nur "Runs" gleicher Farbe speziell behandelt, sondern auch "Runs" wo sich gegenüber dem letzten Screenshot nix geändert hat, und da dann nen LZW drüberlassen. Wenn man das LZW Window gross genug wählt und nicht nach jedem Frame resettet sollte das recht gut Verschiebungen erkennen können.

Ich würde am ehesten die zlib verwenden, die ist relativ einfach zu handhaben. Runterrechnen auf 8 Bit bringt dann sicher nochmal was - die berühmte 216 Farben Palette eben (6*6*6).

*Cpp-Anfänger* 0

Hallo zusammen,

Mit einer DIBSection arbeite ich doch auf dem Speicherbereich, der
dargestellt wird, oder?
Dann mal eine vielleicht blöde Frage:
Warum ist auf dem Abbild des Speicherbereichs kein Mauszeiger?

Gruß,
*Cpp-Anfänger*

hustbaer

Cpp-Anfänger schrieb:

Hallo zusammen,

Mit einer DIBSection arbeite ich doch auf dem Speicherbereich, der
dargestellt wird, oder?

Nö, die einzige Möglichkeit direkt auf den Speicher zuzugreifen der dargestellt wird (die ich kenne) ist DirectDraw zu verwenden. Das DI in DIB legt eigentlich schon nahe dass das nicht der Grafikkarten Speicher sein kann, DI steht für Device Independant.

Dann mal eine vielleicht blöde Frage:
Warum ist auf dem Abbild des Speicherbereichs kein Mauszeiger?

Gruß,
*Cpp-Anfänger*

Ob die Frage blöd ist weiss ich nicht , aber die Antwort ist: a) ist das eben nicht der "Speicher der dargestellt wird", und b) sorgt Windows dafür dass der Mauszeiger da nicht drinnen ist. Meistens ist die Maus sowieso als Hardware-Sprite implementiert, und wenn sie das nicht ist, bzw. irgendwas die Verwendung eines Hardware-Sprite verhindert (pointer shadow, ...), dann pinselt Windows wieder das "Bild unter der Maus" drüber bevor es blittet oder irgendein Programm (z.B. über DirectDraw) direkt darauf zugreifen lässt.
Kurz: Windows sorgt dafür dass der Mauszeiger nie in einem Screenshot sichtbar ist. Macht IMHO auch Sinn.