Beiträge von Andy

eukalyptus,
hattest du den Algorithmus in meioem Link mal ausprobiert?
https://autoit.de/index.php?page…4474#post214474

@progandy
ja, kann schon sein, erstens verarbeitet ein gut (ich gehe davon aus dassdie Compiler gut optimieren) umgesetzter SSE-code 4 floats auf einen Schlag (incl Bonus durch loop-unrolling) , zweitens ist auch beim "einfachen" ersetzen von FPU-Befehlen mit SSE-Pendant der Prozessor schneller (rechnet aber auch nur einfach genau).

die Optimierung über den Algorithmus (s. meinen vorherigen Post) ist ca. 10x schneller als der ursprüngliche Code.
Da optimieren auch diverse Compilerschalter nichts mehr weg^^. Meine Rede seit 30 Jahren...."Ein langsames Programm wird auch nicht besser, wenn es auf einem schnelleren Rechner (Prozessor) ausgeführt wird!"
Der schnelle(re) Algorithmus macht immer das Rennen...

Wenn man sich mal ernsthaft überlegt, wie lahmar***ig heutzutage ein ultramoderner 1,4 GHZ-Prozessor (512MB Ram) mit läppischen 480x800 Pixeln in einem "Mobiltelefon" umgeht (von "Multitasking" mal garnicht zu reden), dann wundert gar nichts mehr. Da wird mehr Code emuliert als sonstwas. Aber über Windows meckern! Das war vor 10 Jahren wenigstens schon Multitaskingfähig und man konnte halbwegs damit arbeiten^^, auch mit 1,4Ghz
Der PIII Tualatin ist nicht umsonst als KING in die Prozessorgeschichte eingegangen
Genau so einen schiesse ich mir gleich bei Ebay, der möbelt dann meinen 1,2Ghz-Celeron noch mal richtig auf

Hi,
mal wieder ein schönes Beispiel, dass "vermeintlich" schnellere Programmiersprachen nicht immer soooo gut abschneiden
Weiterhin auch ein schönes Beispiel, dass

EIN SCHNELLER ALGORITHMUS NICHT ZU TOPPEN IST!!! <--das ist ein Link

In C (++) bietet es sich übrigens auch an, die Sinus/Cosinus usw- Funktionen als einfachen Assemblerbefehl "Inzulinen" , das spart ca Faktor 3 beim ausführen,
also aus sinf($var)

_asm
FLD ($float) ;load $float in Stack
FSIN ;sinus
FST ($float) ;speichert sinus in
_asmend

so (oder ähnlich, bin kein C-Freak) geht das, habe diesen Trick schon einmal benutzt, um c++ - Dll´s zu beschleunigen

Hi,
mein "Tut" ist kein Tut für irgendwelche Assembler, sondern eher gedacht gewesen, Assemblerbefehle in AutoIt zu "inlinen" und das zusammenspielen (Variablenübergabe u.a. ) von AutoIt und Assembler zu erklären.
Gute Assembler-Tut´s sind aber dort verlinkt^^

Weiterhin ist es als Anfänger völlig schnurz, welchen Assembler du verwendest. Für fast jeden gibts eine mehr oder weniger (meistens weniger) komfortable IDE.
Die x86-Syntax ist auch gleich, lediglich beim "fortgeschrittenen" Assemblerprogrammieren d.h. Verwendung von Macros gibts Unterschiede.
Mit Macros wird Assembler so mächtig, daß es sich hinter KEINER HLL zu verstecken braucht, OOP inclusive....

Einen schönen Bereich für Anfänger gibts übrigens im MASM-Forum!

Hi,
schau mal hier

hab u.a. die Sobel-Kantenerkennung in asm, muss das mal als dll zur Verfügung stellen, oder als AutoIt-Funktion. Bin aber zzt. nicht zuhause....

Frag auch mal nach ShadowAE, der hat vor kurzem ein Filterprogramm in asm vorgestellt, da kannst du dann erst Sobel und anschließend über die detektierten Pixel den Weichzeichner/Gauss drüberlaufen lassen.

Na, da schliesse ich mich doch an!

Glücklichen Herzwunsch und alles Gute!

Hi,

Zitat

Ach jetzt doch ?

leb mal 6 Wochen solo in div. Pensionen/Hotels ohne einen privaten Rechner, ohne i-net und rotiere 12h am Tag auf Arbeit...da kommste nach 2 Wochen zur Ablenkung auf Jogging und nach weiteren 2 Wochen tun sich im Kopf Algorithmen auf, wie man bestehende Scripte umbauen könnte^^

Zitat

Edit: Mache am besten direkt einen DllCall zu recv und setzte MSG_WAITALL

ja, gute Idee! Falls sich nicht bestätigt, daß MSG_WAITALL unter XP nicht funktioniert!

Hi,
bin zzt. etwas weit ab vom Schuss, nächste Woche aber wieder öfter online. Da gibts dann auch eine "Speedversion" (ich werde den/die "externen" Packer _LZW_Compress() / Decompress ) komplett in SSE schreiben ggf doch auch mal den Huffmann-Filter probieren )
Dann braucht man die "externe" Windowsfunktion nicht mehr und ich kann mich mal im optimieren austoben....
Leider ist dann der Punkt erreicht, wo ich meinen liebgewonnenen PIII@1,2Ghz nicht mehr zum Testen nehmen kann *schnüff*, da SSE2 und SSE3-Befehle nicht unterstützt werden (wurden)

Zitat

Nachdem der Client connected ist, lässt der Server meinen CPU (leider noch Athlon X2) auf 40-50% laufen.

Da sollte auch noch was zu machen sein, auf meinem Stromspar-Athlon 4850 läuft der Server auch mit ~50%. Das liegt aber an der DO/UNTIL-Schleife im Server, die auf eine Antwort vom Client wartet , schreib da ein sleep() rein, oder besser, ich mach für die nächste Version ein "Minisleep" (irgendwo war da doch ein Script aus dem eng. Forum um kurze Sleeps zu machen...)
Selbst bei 1680x1050 braucht der Asm-teil zur Berechnung der Bilddifferenzen nur ~1 ms...daran liegts also nicht^^

Ja, den Handshake hab ich mir auch vorgenommen, da geht dann auch noch was (Übertragung während der Rechenzeit beim Packen spart bei Full-Video ca. 50-100ms/Frame! )
Weiterhin werde ich mal dem Protokoll per Wireshark auf den Pelz rücken, irgendwas ist bei der AutoIt-TCP-Übertragung faul, angeblich habe ich bei AutoItverbindungen über TCP wesentlich weniger Netzlast, was nur heissen kann, dass die Daten langsamer übertragen werden!? Kann das jemand bestätigen? Also als Test ein 100MB-File auf einen anderen Rechner per AutoIt-TCP dauert länger wie eine "Kopie" im Explorer.

Zitat

Ist es erlaubt euer Script umzuschreiben und in sein eigenes einzufügen, wenn man das Copyright dran lässt?

Ich spreche mal nur für mich....."wer soll dich daran hindern?"
Im Ernst, wenn du sinnvolle Erweiterungen einbaust, stell die Version irgendwo zur Verfügung (ggf auch an uns senden) damit alle davon partizipieren können!
Wenn das Script Teil eines größeren Projekts werden soll , um so besser...dann war die ganze Arbeit doch nicht für die Katz^^

Int2Hex ist das einfachste^^

Du musst nur 4er-Gruppen aus den Bits machen. Beispiel, der Integer 91 ist binär 0101 1011
die erste 4er-Gruppe Bits 0101 ergibt dezimal 5, also 5h
die zweite vierergruppe Bits 1011 ergibt dezimal 11, also Bh
91 dezimal ist also 5Bh

Zitat

Ich werde, wenn die Konsole funktioniert, mal verushcen Zahlen in Strings umzuwandeln um die Zeit anzeigen zu können

Dem Manne kann geholfen werden....
Die Funktion int2ascii (in C gibts das als "itoa" ) hatte ich im Primzahlenprogramm verwendet, um die Integer als "Zahl" darstellen zu können.

Coole Sache!
In den Zeiten, da ein 1€-Handy einen 1Ghz-Prozessor und 1 Gig Ram hat einen DOS-Clone in Assembler zu schreiben hat was^^
Hehe, ich dachte mir schon, wieso macht der sich die Mühe mit dem Emulator, bis ich drauf gekommen bin, dass auuser mir wohl kaum jemand noch ein Diskettenlaufwerk zum Booten hat^^

Zitat

Auf welchen Prozessoren funktioniert dein OS,

ab 8086 jeder x86

Zitat

wv Bit

16

Zitat

und kannst du auch einen Pixel x,y auf den Bildschirm färben, also nicht mit msg ?

schau dich mal u.a. HIER um...
Vorgehenssweise (aus dem Kopf ist 20 Jahre her^^):
Per INT10 Bildschirmauflösung im Grafikmodus einstellen (Achtung imho maximal nur EGA 640x350 in 16 Farben, per VESA gehts dann höher ), der Framebuffer ist dann linear ab Segment A000:0000 angeordnet. Per Pixel dann 4 Bit (2^4=16 Farben)
Beispiel:

Ab damit in den Assembler ergibt diese Datei:
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.
in FILL.COM umbenennen, in irgendein Verzeichnis kopieren
Eingabeaufforderung (CMD) öffnen, ins Verzeichnis wechseln
dort FILL.COM gefolgt von einem Enter eingeben, voila , 35 Bytes um den Bildschirm mit Farben zu füllen^^
Eine Taste drücken um wieder auf die Konsole zu kommen....

Zitat

es geht hier nicht um spiele.

Darum gehts auch nicht....
Es geht darum, WIE deine Software (Mediaplayer) den Fensterinhalt darstellt. Wenn keine Standard-Windows-Funktionen verwendet werden, besteht nur prog@ndy´s Vorschlag, die dll (so eine besteht) des Mediaplayers auseinanderzupflücken, die Funktion zur Darstellung des Bildschirminhaltes auf deine eigene Funktion "umzubiegen" (hooken) und zu versuchen, dort im günstigsten Fall ein "Handle" zu bekommen, dass auf den Fensterinhalt zeigt....
Wenn du dazu nicht in der Lage bist, besteht die Möglichkeit, den Bildschirminhalt über eine Video-Capture-Karte abzugreifen, also Ausgang Grafikkarte in den Eingang der Videokarte. HDMI usw ist da natürlich zu vergessen...analog geht das aber immer^^. Logischerweise funktioniert das nur bei sichtbaren Bildschirminhalten, bei erweitertem Desktop wirds da auch eng.

Hi,
der Code spricht Bände^^
Es wird, das hast du richtig erkannt, ein SPEICHERINHALT von einer Position (Pointer1) im RAM an die andere (Pointer2) kopiert.
$size ist die Anzahl der Bytes die dabei kopiert werden.
Leider hilft dir das bei deinem Problem nicht weiter.
Du kannst ja mal Deskstream testen, damit funktionieren jedenfalls auch Fullscreenübertragungen diverser Spiele.
Leider ist es immer etwas schwierig, Bildschirminhalte von Fenstern auszulesen, da eine der ersten Windows-Direktiven lautet: "Jedes Fenster ist für seinen Inhalt selbst verantwortlich!". Wenn Spieleprogrammierer (und einige andere Programme wie diverse Mediaplayer) einen eigenen Grafiktreiber installieren und darüber den FENSTERINHALT anzeigen, dann bekommt Windows davon überhaupt nichts mit!
Ergo kann man auch nicht "einfach" an den Inhalt dieser Fenster kommen!

Hi,
nur mal kurze Zwischeninfo, ich bin hier weitab vom Schuss ohne AutoIt und ohne Internet

Die übertragenen Daten setzen sich folgendermaßen zusammen:
Ich sags gleich, durch das verdammte little Endian (da hats der Assemblerprogrammierer gut^^) könnte es etwas stressig mit dem dekodieren werden!

Es gibt 3 Sorten von "Paketen".
1. Paket: Es werden aufeinanderfolgende Pixel mit unterschiedlichen Farben zusammengefasst.
Datenformat: 3 Byte Adresse (Offsetadresse in einer 32-Bit-Bitmap), 1 Byte Anzahl Pixel, 2 Byte Farbe, 2 Byte Farbe, 2 Byte Farbe usw.....
Da man für das Offset der Adresse nur 22 Bit braucht, sind Bit 22 und Bit 23 (Bitnummern starten bei null! ) für die Identifikation der Pakete verwendet!
Wenn Bit 22 gesetzt ist (also im gelesenen ersten Dword (4 Bytes)), dann sind Bit 0 bis 21 die Adresse des ersten Pixels.
Die PixelFarbe habe ich auf 16 Bit komprimiert, AA (alpha) ist einfach weggelassen, bei RR(rot) werden nur die 5 höchsten Bits verwendet, bei GG(grün) die 6 höchsten Bits, und bei BB (blau) wieder die 5 höchsten Bits.
Das Word (2 Byte Farbe) müsstest du dann per Bitschiebeoperationen in 32 Bit "extrahieren", also aus den 16 Bit BBBBBGGGGGGRRRRR dann die 32 Bitfarbe AAAAAAAABBBBB000GGGGGG00RRRRR000 machen
So, und jetzt so lange die dekomprimierten Pixel nacheinander in die Bitmap schreiben, bis die Anzahl (s. Datenformat, das vierte Byte) erreicht ist.

2. Paket: Es werden Pixel mit gleicher Farbe zusammengefasst.
Datenformat: 3 Byte Adresse (Offsetadresse in einer 32-Bit-Bitmap), 2 Byte Farbe, 1 Byte Anzahl
siehe oben, allerdings identifiziert sich dieses Paket durch das gesetzte BIT 23 im ersten Dword!
Bit 0 bis 21 sind wieder die Offsetadresse, die Farbe wird wie oben aus den 2 Byte extrahiert und so lange hintereinander in dei Bitmap geschrieben, bis die Anzahl (6. Byte im Paket) erreicht ist.

3. Paket: Nur einzelne Pixel,
Datenformat: 3 Byte Offset (22 Bit), 2 Byte Farbe
wie gehabt, Offsetadresse ermitteln (Bit 22 und 23 sind NICHT gesetzt!), und extrahierte Farbe in die Bitmap schreiben.

Der Server schickt natürlich nur diejenigen Pixel, die sich während 2 Frames geändert haben, wenn sich wenig bis garnichts ändert, sind die Daten entsprechend gering!

Uhhhhhh, bevor man die "rohen" Pakete bekommt, muß man natürlich die durch die zusätzliche Komprimierung verkleinerten Pakete entpacken.
Ich würde es daher zum Testen so machen, daß die Komprimierung (durch die Windowsfunktion _LZW_Compress() imho) erstmal im Server abgeschaltet wird. GGf gibts ja eine Java-Komprimierungsfunktion, die besteht dann sicher auch für Windows, diese könnte man dann einsetzen!

Hab leider zzt kein Internet/AutoIt, da weitab vom Schuss einquartiert, sonst hätte ich die Entpackungsfunktion mal in AutoIt geschrieben^^

Habe mal ein Beispiel in den vorigen Post editiert, wie man Wards Kompressions-UDF in Deskstream verwenden kann um noch ggf einiges an Geschwindigkeit rauszukitzeln.

So wie ich das sehe, nützen HOHE Kompressionsraten bei schnellen Rechnern (Client UND Server! ) und einer eher langsamen Leitung, bei langsamen Rechnern sollte man eher die Kompression niedriger einstellen.

Noch etwas in Sachen Portabilität:
Ich habe einige Demos für JavaScript und den Einsatz der JIT-Compiler bewundert, da ist mir die Idee gekommen, den DeskStream-Client als Javascript (oder ggf in Java direkt) zu implementieren.
Somit könnte man von jedem Browser aus eine Verbindung zum Server herstellen. Ihr könnt ja mal eure Meinung posten. Ich sage aber gleich, dass ich weder Java noch JS beherrsche, Code lesen (eingeschränkt) ja, Code schreiben nein Es würden also JS/Java-Programmierer gesucht....

a propos Ward
Ward hatte HIER einige schöne Kompressionsverfahren in Assembler (auch 64Bit!) vorgestellt. Ich hab jetzt einiges probiert (im lokalen Netz) aber viel reißt es leider nicht!
Entweder sind meine Rechner zu lahm oder mein Netzwerk nicht schnell genug (wahrscheinlich beides) um Unterschiede zu merken...
Wer mag, kann ja mal ne Testreihe basteln. Es müssen dazu lediglich die Ward´schen Kompressions-UDF´s included werden, und im Client und Server die Kompressionsfunktion getauscht werden (im Client noch die folgende Zeile $len=@extended durch $len = binarylen($sdata) ersetzen).
/EDIT/
Beispiel:
Im Server #Include "LZMA.au3" hinzufügen und in der Zeile 222

$sString = _LZNTCompress(DllStructGetData($struct_string, 1)) ;binärstring fertig zum verschicken

ersetzen mit

$sString = _LZMA_Compress(DllStructGetData($struct_string, 1)) ;binärstring fertig zum verschicken

Im Client natürlich auch die Include einfügen und in Zeile 254

$sData = _LZNTDecompress($sData); daten dekomprimieren
$len = @extended ;länge der dekomprimierten Daten

ersetzen durch

$sData = _LZMA_Decompress($sData); daten dekomprimieren
$len = binarylen($sdata) ;länge der dekomprimierten Daten

das wars schon!
Schaut euch mal die Beispiele zur Kompression in Wards UDF an, bei einigen Funktionen kann man auch die Kompressionsstärke einstellen!
/EDIT/

Jetzt hängts eher noch am Ablauf des Protokolls, das war in den ersten Versionen wesentlich schneller, da der Server schon ein neues Frame berechnen konnte, während der Client parallel dazu sein Frame aus den übertragenen Daten extrahiert hat.
Zur Zeit ist das *hust* extrem langsam (alles nacheinander statt parallel)) gelöst, das synchronisieren von Client und Server steht aber ganz oben auf der ToDo-Liste.

Keine Ahnung, ob der OnEvent-Modus auch noch was bringt, oder ob der eingebaute "Delay" in GuiGetMsg() zur Zeit garnicht triggert....

Hi,
@progandy, shame on me....
ich hatte vor ca. 2 Jahren per Wireshark festgestellt, daß AutoIt wohl "automatisch" den Bytemodus verwendet, wenn man einen "0x...."-String verwendet (beim Senden) . Jedenfalls war damals der Inhalt der Pakete identisch....
Das hatte ich im Hinterkopf und daher überhaupt nicht geschnallt, daß bei DeskStream ja garkein "0x...."-String gesendet wird, hätte ich diesmal per Wireshark gesnifft, hätte ichs sicher bemerkt
Daher vielen Dank für den Hinweis!

Hab die neuen Versionen umgeschrieben (string2binary/bynary2string are my friends^^), Sprenger wird sie sicher bald Online stellen! Waren nur 2-3 Zeilen zu ändern....=> doppelte Übertragungsrate jetzt!!!

Hi,
das "Panning", also das Verschieben des vergrösserten Fensterinhaltes hat zzt. noch einen kleinen Schönheitsfehler.
Je nach Vergrösserungsfaktor kann es beim Verschieben mit den Pfeiltasten vorkommen, dass nicht nur in x- sondern auch in y-Richtung verschoben wird. Das ist infolge einer im Server schon verwendeten Funktion, so musste ich im Client nur 2 Zeilen ändern und konnte den Server unverändert lassen^^

Die Fenstergröße kann nun auch am Fensterrahmen verändert werden. Zoomen wie gehabt mit dem Mausrad oder mit den +- Tasten auf dem Numpad (gibts da Probleme/Vorschläge für Notebooks?) @Sprenger, ggf die Panning/Zoomtasten in die INI schreiben.

Aufgrund der laufenden Umgestaltung des Codes (er wird noch stark gekürzt und in den OnEventMode umgesetzt) arbeiten jeweils nur die "passenden" Clients und Server zusammen, d.h. ein Server einer früheren Version ist NICHT zu einem neuen Client kompatibel.

Der Handshake ist nun sehr konservativ und stabiler, die Latenz daher nicht optimiert, aber das sollte nicht weiter stören.

Bitte testen, ob es zu Fehlermeldungen kommt, ich hatte diese Version auf verschiedenen Rechnern im internen Netz und auch über Internet laufen ohne Fehlermeldungen. Bei Fehlern bitte auch die Bildschirmauflösung angeben.

Besonderer Dank geht an Raupi, bei dem ich übers Netz auch den Zwei-Bildschirmmodus testen durfte! (wobei die Leitung bei 1680x2x1050 Pixel x 4 Byte = 14MB fürs erste Bild (ohne Komprimierung)) schon geglüht hat^^. Allerdings lief die Steuerung auch über 2 Monitore sehr flüssig, auch Doppelklicks wurden durchgereicht.

Apropos Doppelklicks, bitte auch testen, wenn es nicht 100%ig funktioniert, müssen wir das per Message abfangen und ein Bit in der Nachricht an den Server setzen.

Hi,
ich kann das PCRE Toolkit empfehlen, es ist komplett in AutoIt programmiert, somit wird automatisch die in AutoIt gültige RegEx-Syntax benutzt.

Wo ist der Bus?