Beiträge von Andy

Hi,
ich konnte leider das Script nicht starten.

"C:\Program Files (x86)\AutoIt3\Include_Eigene\FASM.au3" (127) : ==> Subscript used on non-accessible variable.:
Func FasmGetLastError()
Func FasmGetLastError^ ERROR

Vermutlich benutze ich nicht die aktuelle FASM.AU3 (warum wohl^^). Daher würde ich die von dir verwendete FASM.AU3 mit in die Zip packen.

Was mir sofort aufgefallen ist, wieso benutzt du nicht AutoIt-Variablen für die Pointer usw. innerhalb des ASM-Codes zur Vereinfachung?

Zitat von Tweaky

Falls ihr mal wieder eine aktualisierte Deutsche Hilfe wollt

die 3.3.8.1-Hilfe (und die von früheren Versionen) ist für mich ausreichend....passend zur "damals" aktuellen AutoIt-Version. Dafür möchte ich dir, und auch den anderen "Hilfe"-Protagonisten, herzlich danken!

...wird immer besser
Und das Jammern erfolgt auf immer höherem Niveau!s.u.

Wenn in der Msgbox von "GR_MSG_CANNOTDOWNLOAD=kann nicht heruntergeladen werden und wird deshalb ausgelassen.", ein Timer sitzen würde, dann könnte das Script sogar nach einigen Sekunden selbstständig mit dem download der anderen Titel fortfahren

Zitat von minx

Es versteckt sich manchmal zwischen anderen Fenstern.

wegen mir, solange der Prozess wenigstens existieren würde, oder versteckt der sich dann auch?
Der Prozess existiert ca. 3 Sekunden, dann wird er beendet.
Ich kann ja wg dem blöden Packer nicht mal die EXE debuggen...bzw. will nicht!

minx,
die EXE läuft bei mir nicht Win7/64 + AMD A6
Wird geladen und gestartet, bricht aber dann ohne Fehlermeldung nach ca. 2-3 Sekunden ab. Bild/Fenster ist dabei keins zu sehen.

UEZ,
gerade die prozeduralen Grafiken sind recht einfach zu vergrößern/verkleinern, wenn man die Grenzen innerhalb der Funktionen beachtet!
ich versuche das Script mal umzuschreiben

Danke!

Die einzelnen Funktionen nun per Wasweisich-Compilersprache als bspw. DLL-Funktion zur Verfügung gestellt (dort kann man den ASM-Code am einfachsten extrahieren), erweitert durch "bewegtes" Wasser , dazu noch ein aus der Sonne auf den Betrachter zukommendes, drehendes 3D-Autoitlogo, und fertig ist die erste 1k-Demo

Los gehts

Ja, natürlich ist die 4K-Grenze nur mit einem compilierten und ggf. auch noch gepacktem Code möglich.
Die Frage ist, wie man dort hin kommt....

Natürlich haben wir einige AutoIt/ASM-Varianten am Start, welche davon letztendlich benutzt wird, bliebe jedem natürlch selbst überlassen!
Diese AutoIt/ASM-Umgebung würde ich allerdings fürs Testen der Funktionen verwenden, einfach aufgrund der problemlosen Entwicklung.
Genausogut könnte man Blitz/Power/Free-Basic oder C++ / Pascal usw. verwenden.
Zur Not die HLL-Entwicklung mit diesen Programmen durchführen, und den vom Compiler erstellten Code handoptimieren! Wobei DAS natürlich eine Möglichkeit wäre

Das letztendliche Programm müsste dann sowieso als "Standalone" durch den Assembler gejagt werden!
Mir geht es in erster Linie darum, möglichst viele Leute mit unterschiedlichsten Vorlieben einer Entwicklungsumgebung/Sprache zusammen EIN Programm erstellen zu lassen!
Gerade die Erstellung prozeduraler Grafiken kann in VIELE kleinere Funktionen (Filter usw) aufgeteilt werden.
Jede diese Funktionen könnte von jedem Mitglied des Teams verändert/optimiert werden, ohne dass die anderen in ihrer Arbeit eingeschränkt werden.
So könnte derjenige, der gerade eine tolle Idee für "Nebel" hat, diese Funktion abändern/erweitern, mit seiner individuellen Umgebung bearbeiten und diese Funktion allen anderen zur Verfügung stellen.
Alle Funktionen liegen online und werden einzeln geladen und vom fertigen Programm zusammengefügt und ausgeführt.
Zur Not kann man natürlich auch AutoIt native für die Programmierung einer Funktion verwenden, dann dauert der Aufbau der Grafiken etwas länger

minx, stell doch mal bitte diese tolle Grafik (Sonnenuntergang) online, damit klar wird, wie ich mir das mit den "vielen Funktionen" so vorstelle^^. Ich denke, dieses Beispiel ist als AHA-Effekt geeignet..

Hi,
StdoutRead funktioniert entgegen deiner Threadüberschrift einwandfrei!
Auch dein Script funktioniert mit einigen von mir ausprobierten "Programmen" fehlerlos!

Zitat

und gibt mir dann die ersten 8 Zeilen des Streams aus aber eben nicht die folgenden die vom Programm erzeugt werden.

welche Zeilen werden ausgegeben, welche nicht?
Du hast weder gepostet, was du in deiner "Programm.exe" versteckst, noch welche Ausgaben von diesem Programm getätigt werden.
Ich gehe also davon aus, dass wieder einmal halbseidene Software verwendet oder erstellt werden soll.

Da bleibt wieder mal nur, einen Modcall bzgl. Threadclose abzusetzen wegen
- unqualifizierter, weil nicht zutreffender Überschrift
- absichtlichen Vorenthaltens explitit nötiger Informationen, welche zur Lösung des Problems unumgänglich sind
- hoffentlich eintretendem Lerneffekt

Hi,
die Konzepte sind (soweit ich das beurteilen kann) durchaus fähig, eine Demo zu erstellen. Ich habe bei "Demo" aber maximal das 4K-Format im Auge.
Das was definitiv fehlt, ist ein COMPILER!
Und das nicht mal für sämtliche API-Funktionen, sondern lediglich für die Berechnungen.
Denn das, was die Zeit kostet, ist der von mir auch bei der Entwicklung von AssembleIt()/OpenCL-Wrapper angepeilte "inner Loop". Was GDI(+)/OpenGL/Direct3D können, sollte man damit auch machen. AutoIt ist ideal, die "Umgebung" bereitzustellen, d.h. Darstellung der Fenster usw.
Auch die Syntax ist simpel.
Klar könnte man als Zwischenschritt die Berechnungs-Funktionen in Assembler/C(++)/FreeBasic-Dll´s auslagern, aber das ist, ehrlich gesagt, eine Krücke!
Viel schöner wäre doch, wirklich EINFACHE Schleifen und Berechnungen im AutoIt-Code direkt in den Speicher zu compilieren und dort auszuführen, ein "Mini-Compiler" sozusagen. Aber das ist wohl etwas viel verlangt, aber was meint ihr?
Wobei ein Compiler, welcher CPU-Code erzeugt, um Grafiken darzustellen, imho völlig daneben ist....

Also doch OpenCL/GL in C++?

Hi,

Zitat

ist das nur n fehlalarm meines scanner oder habt ihr auch diese meldung bekommen?

Denk mal GENAU darüber nach, was du hier überhaupt fragst...
Bzw. was du gedenkst, hier als Antwort zu erhalten.

Mal zum Nachdenken:
20 User sagen "Schaff dir nen ordentlichen Virenscanner an!"
20 User sagen "Hab keinen Alarm bekommen"
20 User sagen "Hab nen Alarm bekommen"
20 User sagen "Scite braucht kein Mensch"
20 User sagen "Auch wenn alle Virenscanner KEINEN Virus anzeigen, kann trotzdem ein Virus enthalten sein"

Somit hast du 100 Antworten und ALLE haben Recht! Und nun? Hilft dir das nur ansatzweise bei deinem Problem weiter?
Und wenn nicht, wieso startest du dann hier diesen Thread?
Mit dem Hintergrund, dass die ca.3000 Ergebnisse bei google nach "scite4autoit virus" das Thema mehr als eindeutig beantworten!

Hi,

in einer OnEvent-Umgebung könnte man @GUI_CtrlId als Index des Contol-Array´s nutzen.
Rechtsklicks, Linksklicks und Doppelklicks fange ich bei vielen Controls in etwa so ab:

unkommentiert....http://hugi.scene.org/online/hugi35/…0was%20born.htm

AutoIt wäre natürlich der Knaller
Man müsste nur die Demo von der Idee her so gestalten, dass sie problemlos in AutoIt machbar wäre. Beispielsweise eine kleine Geschichte mit sich bewegenden/tanzenden Strichmännchen, die während der Demo eine sich im Hintergrund aufbauende prozedurale Landschaft kommentieren....ein "umpft umpft umpft-Sound" in einer Handvoll Bytes,der im Hintergrund dudelt, sollte dabei auch noch machbar sein.

Zitat

wobei es dafür auch noch ASM gibt, aber dann am besten gleich richtig).

eben....da nämlich sowieso nur Shader bzw die GPU über deren Treiber bzw. Direct3D/OpenGL/CL programmiert werden, fällt eine "normale" Programmiersprache imho raus, da selbst für einfachste float-Berechnungen (sin, cos, sqrt usw.) nicht die nativen und schnellen CPU-Befehle benutzt werden, sondern die "sicheren" Bibliotheken.

Und wenn einer sagt, _intrinsic-functions wäre die Lösung, ja dann muss ich lachen....eine "Hochsprache" zu verwenden, in der dann Prozessorbefehle gewrappert werden...DAS ist der echte Fortschritt!!! Die Frage bleibt, warum ich als Programmierer solche Krücken benutzen muss, und der Compiler das nicht von sich aus hinbekommt
Für 1K bis 4k ist Assembler imho eine sehr gute Wahl, darüber wird es dann wieder aufwändiger und spezielle Bibliotheken für "Hochsprachen" gibts ja mittlerweile auch schon

Zitat von YaeroxXO

aber was ich noch nicht ganz verstanden habe, was macht man dort.

Genau dasselbe, wie in einem Fussballstadion, einem Zirkus/Zoo, auf einer Rennstrecke, beim Skatturnier uswusf...
All das hat absolut keinen sittlichen Nährwert! Trotzdem machen das Millionen Leute...

Sinn ist, die Leistungsfähigkeit der Hardware zu DEMOnstrieren! Und da ist völlig egal, um welche Hardware es sich handelt! Hauptsache, man erstellt grafische/musikalische Effekte, die niemand diesen Geräten zugetraut hat(te).
Wenn man vor 20 Jahren die von UEZ verlinkten VIDEOS gezeigt hätte, wäre niemand auf die Idee gekommen, dass das eben keine Videos, sondern in Echtzeit gerenderte Full-HD- Grafiken mit lediglich 64kB Code seien! Damals war man froh, mit einigen FPS die Grafiken eines Spiels mit 256 Farben in 640x480 Pixel darstellen zu können....
Jedes einzelne Frame der heute in Millisekunden erzeugten Grafiken hätte damals genauso "prozedural" berechnet werden können, allerdings in Monaten!

Die Zeit der Berechnung bzw. die "Rechenvorschrift/Formel" einer prozeduralen Grafik (hier, hier, oder auch hier (die mathematischen Hintergründe ( ! )) ist abhängig von der verwendeten Hardware. Und da muss man schauen, was man in Echtzeit ( ! ) aus dem jeweiligen Gerät herausbekommt.

Hi,

StringRegExp()

wird dir weiterhelfen!
Allerdings ist es aussichtslos, anhand deiner Beschreibung ein Muster und somit ein Suchpattern zu erstellen!
Poste eine Testdatei und gib an, welche Daten gelöscht werden sollen, bzw. wie das Endergebnis auszusehen hat!

Zitat

Vielleicht lässt sich ja auch mal die eine oder andere Demo aufstellen, gemeinsam!

Meine Rede^^
Aus dem Bauch raus würde ich sagen, eine gute Idee wird vom Publikum stärker honoriert als die technische Umsetzung, Chance für frischen Wind, hehe

Zitat

und auch nur wenige der 4k/8k (8k ist ne MENGE Platz) konnten überzeugen.

Von 8K war ich auch enttäuscht, nicht von den technischen Möglichkeiten, sondern von den Ideen.
Übrigens wurde imho in diesem Jahr SEHR vielmehr auf Sound Wert gelegt wie sonst, da hab ich allerdings keinerlei Plan von.....
Aber einige haben doch gezeigt, wo der Hammer hängt! Kein Wunder, alles "alte Hasen"

Hi,
es geht natürlich NOCH kürzer/schneller, aber wen juckt das...

Anbei Kodierer/Dekodierer (der Dekodierer besteht aus 25 BYTES Code )

AssembleIt braucht man natürlich nicht mehr, wenn man per $_ASSEMBLEIT_FLAG = 0 assembliert und den Code direkt ausführt.
Dann sieht das so aus...

Errorhandling sollte man tunlichst hinzufügen, denn wenn der Text länger ist, als das Bild Pixel hat, gibts nen Crash^^
Aber das kann jeder selbst zusammenpfriemeln

Es bleibt natürlich offen, die Textbits statt -------- -----RRR -----GGG ------BB bspw. als -------- ------RR -----RGG -----GBB abzuspeichern, oder nur in jedem 5. Pixel. Oder nur 1 Bit in jedem 7. Pixel...
Sehr einfach in ASM zu realisieren ist das tauschen der Bits, das käme noch einer internen Verschlüsselung gleich, also aus -------- ------RR -----RGG -----GBB würde dann bspw. -------- ------RB -----GRG -----BRG
Der Phantasie sind keine Grenzen gesetzt!

Zur Not kann man die Bilder auch als PNG speichern, dann sind sie etwas kleiner, aber immer noch verlustfrei komprimiert Oder man verwendet libjpeg um verlustfrei in jpg zu transformieren.
Btw. wird mit ca. 500MB/Sekunde kodiert/dekodiert! Was bedeutet, dass 500KB Text in einer Millisekunde in einem Bild verschlüsselt/entschlüsselt werden! Das entspricht ca. 6 Prozessortakten pro verschlüsseltem Buchstaben!

Wer mag, kann natürlich auch binäre Dateien "verstecken", ich würde dann einfach einen Integer mit der Länge der Daten in die ersten 4 Pixel packen, und so lange kodieren/dekodieren, bis dieser Wert erreicht ist! Oder direkt Base64 verwenden...

In diesem kleinen Kerl steckt übrigens auch ein Text -> Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Beschränkt man sich auf Bitmap-Dateien (*.BMP), kann man sogar komplett auf GDI(+) verzichten und direkt in die "Pixel"-Daten schreiben.
Das wäre extrem leicht in jeder anderen Computersprache (und jedem anderen Gerät) umzusetzen!

Den "Aufkleber" hatte ich, infolge mangelden Druckers, von Hand auf der Fahrt nach Saarbrücken gekritzelt.
Davon ausgehend, dass das Schild auf dem Bauzaun eine "normale" Größe hat, dachte ich, die Breite einer DIN A4-Seite sei ausreichend....
Vor Ort angekommen hat UEZ die Security abgelenkt und ich den Zettel auf dem RIESENGROSSEN Schild (ca. 50x20cm) plaziert
Leider war der Stream meistens offline...

Trotz allem wars klasse! Kaffee gabs in SEHR guter Qualität in beliebiger Menge umsonst, Futter und Getränke zu SEHR gemäßigten Preisen und die Stimmung war (auch bei Massen von angetüdelten Nordländern ) entspannt.
Das was als "Musik" bezeichnet wurde (eigentlich gabs nur BASSSSSS) , kam in voller Lautstärke auf die Ohren, Gehörschutz in Form von den (guten) Einweg-Ohrstöpseln gabs kostenlos dazu^^
Von Neugeborenen über (grösstenteils mit Gehörschutz ausgestatteteten) kleine Kindern war das Publikum (auch erstaunlicherweise ca. 10% davon Mädels) in allen Altersklassen (auch >60 ) vertreten )

Letztendlich bleibt als Fazit:
Es müssen mehr Leute von uns zusammen dorthin, mindestens 2 Tage, und natürlich Rechnerequipment als MUSS!
Und T-Shirts mit AutoIt-Logo natürlich

Seeehr schick^^
Dein Code ist jetzt kürzer, es geht aber noch wesentlich einfacher. Du musst nicht immer das Byte aus dem Speicher laden, mit den Schiebebefehlen kannst du einfach die RRR GGG BB trennen...

_("Pixel:") ; Beginn der Schleife für jeden Pixel

_("movzx edx, byte[esi]") ; edx ist das erste Byte des Binärstrings, wird nur 1x aus dem Speicher gelesen
;(binär EDX: 00000000 00000000 000000000 RRRGGGBB)
_("shl edx, 11") ;(binär EDX: 00000000 00000RRR GGGBBB000 00000000) komlett nach links schieben
_("shr dx, 5") ;(binär EDX: 00000000 00000RRR 00000GGG BB000000) nur DX shiften
_("shr dl, 6") ;(binär EDX: 00000000 00000RRR 00000GGG 00000BB) nur lowbyte shiften

_("mov eax, dword [edi]") ; Farbe des Pixels (= Wert an edi-Position) in eax Form: #AARRGGBB
_("and eax, 0xFFF8F8FC") ; Pixelfarbe mit 11111111 11111000 11111000 11111100 verknüpfen -> die Bits, die überschrieben werden auf 0 setzen
_("or eax, edx") ; und mit den neuen Daten per OR verknüpfen
_("mov [edi], eax") ; Farbwert in der Bitmap speichern

Genauso kannst du natürlich auch beim "Auslesen" die Bits zusammenfassen....
-------- -----RRR -----GGG ------BB
low-byte 6 nach links shiften
-------- -----RRR -----GGG BB-----
high- und lowbyte zusammen (AX,BX, usw) 5 nach links
-------- -----RRR GGGBB--- --------
alles 11 nach rechts
-------- -------- -------- RRRGGGBB
voila

Insgesamt könnte man noch einige Zeilen sparen, aber so ist es lesbarer

Weiterhin läuft dein Programm nun alle Pixel der gesamten Grafik durch, du könntest beim Ende des Strings abbrechen!
Die Struct, in der dein zu verbergender String steckt, müsste nur ein Byte (= NULL) größer sein als der String.

Auch beim Aufrufen per Call reicht es, wenn du die Adresse des Bildes und die Adresse des Strings übergibst! Abbruchbedingung ist das Nullbyte am Ende des Strings!
Die Abfrage, ob der String größer als die Anzahl der Pixel des Bildes ist, würde ich in eine Zeile AutoIt packen^^

Zitat

Also ich habe auch Win7/64 Bit und die Version 3.3.10.2, aber zumindest folgendes Debug-Beispiel von dir funktioniert bei mir:

Natürlich funktioniert bei mir der Debugger auch, man sollte seine eigenen Programme auch bedienen können...