Beiträge von Andy

nein, habe sowohl eine amd 4850 @2,8 ghz als auch einen Intel PIII mit 1,2 ghz
Bei Bekannten mit Intel-Laptops funktioniert es jedenfalls....

hmmmm, seltsam, der eigentliche Code wurde nicht geändert, der war in 5 min auf den Fasm angepasst, erweitert wurde nur AutoIt-Code
Jedenfalls läuft der Assembler einwandfrei durch, sowohl Oscars als auch Funkeys Bytecode sind genau wie meiner...schade schade, da werde ich wohl jemanden nerven müssen, der mit mir zusammen den Fehler sucht^^
Freiwillige Vor^^

die fasmdemo.au3 funktioniert aber?

thx fürs testen, ggf könntet ihr auch mal ausprobieren, ob es hilft, die Zeile 480

$ret=MemoryFuncCall("int:cdecl", FAsmGetFuncPtr($AsmObj), "ptr", dllstructgetptr($asmstack)) ;Assembler aufrufen und Code starten

zu aktivieren und dafür die Zeile 489 auszukommentieren...

und wenn man schon dabei ist^^, die folgenden Zeilen 282-287 auch gleich auskommentieren, sie regeln den Funktionsaufruf der AutoItfunktion aus dem Assembler heraus....

FasmAdd($AsmObj, " fsave [ebp+40h] ");alle Coprozessorregister und den Copro-stack sichern
FasmAdd($AsmObj, " pushad ");alle Prozessorregister sichern
FasmAdd($AsmObj, " mov eax,dword[EBP+34h] ");Adresse der AutoItfunktion in eax laden, evtl Parameter vorher auf den stack pushen
FasmAdd($AsmOBj, " call eax ");AutoIt-Funktion aufrufen, erlaubt einen Interrupt, ansonsten wäre das Fenster während der gesamten Berechnung blockiert
FasmAdd($AsmObj, " popad ");Prozessorregister alle wiederherstellen
FasmAdd($AsmObj, " frstor [ebp+40h] ");coproregister und coprostack wiederherstellen 60

Und für die Hardcoretester, funktionieren denn die Beispielfunktionen in der fasmdemo.au3?

Upps, sorry, mein Fehler! Da zzt. nur die 32-Bitversion unterstützt wird, bitte als 32Bit testen!
Das hängt mit der Verwendung der explizit erforderlichen 64Bit Register, der 64-Bit-Übergabeparameter usw zusammen.
aber mit Blick auf die "neuen" DLL- bzw Struct-typen

Zitat von Hilfe zu DllStructCreate()

INT_PTR, LONG_PTR, LRESULT, LPARAM 32 or 64bit signed integer (Je nach dem, ob die x86 oder die x64 Version von AutoIt benutzt wird)
UINT_PTR, ULONG_PTR, DWORD_PTR, WPARAM

kann man da ggf. etwas machen.

Btw, muß man den Pfad zu den 32-Bit-Dll´s (falls verwendet) in einem 32Bit-Script(auf 64Bit-System) angeben, oder nimmt Autoit bzw das BS "automatisch" den richtigen?

UPDATE 24/03/2010
Nun ist dank Ward aus dem engl. Forum ein völlig moderner Assembler in AutoIt und auch in das Apfelmännchenscript eingezogen!
Nun ist auch ein "Flug" bis hin zur prozessorabhängigen Genauigkeit von 2e-17 (80Bit) möglich, dabei kann das Fenster in der Größe verändert werden sowie eine andere Farbpalette.

Viel Spass!

Vielen Dank an die "Nachteulen"! (man beachte die Uhrzeiten der Postings)

Hi,
folgendes Problem:
Ein Contextmenü wird erstellt und der aktuelle Menüeintrag bekommt mittels GUICtrlSetState(Menüeintrag, $GUI_CHECKED) ein Radiobutton.
Nun kann man per Maus die anderen Menüeinträge auswählen und der Radiobutton wechselt auf den angeklickten Eintrag, so soll es auch sein.

Jetzt möchte ich aber diesen Radiobutton innerhalb des Menüs nicht nur per Mausklick in das Menu ändern, sondern auch innerhalb des Scriptes.
D.h., sobald eine bestimmte Funktion aufgerufen wird, soll die Position des Radiobuttons geändert werden.
Mit GUICtrlSetState(Menüeintrag, $GUI_CHECKED) funktioniert das aber nicht, dann sind beide Menüeinträge angehakt.

Gibt es eine Möglichkeit den Radiobutton zu setzen(so daß der andere verschwindet), OHNE die damit verknüpfte Funktion aufzurufen.
Die Orgie, sämtliche Positionen zu disablen, und den einen dann zu setzen würde ich gerne vermeiden, da ich viele verschachtelte Menüeinträge habe.
Diese gesuchte Funktion gibt es bei den _GuiCtrlMenuCheckRadioItem(), funktioniert so leider nicht bei "normalen" Contextmenüs.

Zitat

Keine objektorientiere Programmierung.

Falsch, da "objektorientierte Programmierung" ein von einer Sprache völlig unabhängiger Programmierstil ist. Die "neuen" Sprachen unterstützten den Programmierer nur besser bei der OOP .
Btw. ist es mit AutoIt sehr wohl möglich, mit "Klassen" zu arbeiten

Ein wesentlicher Unterschied ist die Portabilität. AutoIt ist nur auf Windowssystemen lauffähig, während C-Code von so gut wie jedem BS unterstützt wird (für das es einen C-Compiler gibt).

Zitat

mit dem Compiler von AutoIt erstellen.

Das ist auch ein Unterschied, AutoIt "compiliert" den Code nicht, sondern speichert ihn zusammen mit einem Interpreter in der EXE-Datei ab, daher ist in einigen Bereichen AutoIt auch nicht so schnell wie "richtig" compilierte Programme.

Hi,
habe 2 Varianten am Start, eine listet die 100000 Primzahlen in "native AutoIt" zzt in 5 Sekunden @2.5Ghz mit "handelsüblichen" (String)-Befehlenund die andere, öhhm, mit Hilfe von 82 Bytes in einer AutoIt-Struct in unter 20 Millisekunden, unoptimiert...mal sehen, was sich da noch rausholen lässt....

Zitat

klar aber wie gesagt die haupt idee ist das du änderungen über ftp machen kannst udn über ftp kannst du nix starten aber ne datei abändern

Verstehe ich ehrlich gesagt nicht.....
1. Du hast ein Programm 24/7 am laufen, dann kannst du DLL´s, Includes und wasweisichnichtalles ändern, "sauber" bekommst du dort kaum geänderte Funktionen rein.

2. Das Programm (oder Teile davon, z.B. Includes) wird per FTP upgedatet, startet daraufhin neu (ggf Benutzerhinweis) und nach einigen Sekunden ist alles auf dem neuesten Stand.

/EDIT/ zu 1.
mit einer dll sollte das klappen, dll uploaden, das Programm bemerkt die neue dll, entlädt die alte dll, kopiert die neue uber die alte und lädt die dll wieder....

mal ohne Witz, wenn man das Gerät zwangsweise über eine Herstellerwebsite einrichten muß, haben die dann nicht vollen Zugriff auf das Teil und auch auf das Netzwerk?
Die Daten die REIN kommen, gehen ja auch auf demselben Weg wieder raus. Oder habe ich da jetzt einen Denkfehler?
Da man für die Anmeldung ein Loch in die Firewall bohren muss, könnte das Dingen sogar fröhlich unbemerkt "nach Hause telefonioeren"....Sachen gibts.....

Hi, wieso langsam?
Ein sleep(50) in der Schleife zeigt erstmal, was gemacht wird, ansonsten dauert die Animation bei mir nur ca 1 sec. Das ist dann ca 1 Schleifendurchgang pro Millisekunde, eigentlich ganz ok!
Ansonsten sind die GDI+ Funktionen für den "Hausgebrauch" schnell genug. Brauchst du mehr Speed, dann kommst du um eigene Funktionen nicht herum. Ich bearbeite z.B. lieber die Grafik(Bitmap) direkt im Speicher und blitte sie dann in den Grafikspeicher bzw das Window. Aber auch das blitten ist nicht gerade üppig schnell, das hat leider auch mit den Grafiktreibern zu tun, welche absolut nicht mehr auf 2D optimiert sind (werden).

Zitat

- einmalig: Die Stora bei Netgear registrieren, User anlegen, PW vergeben
- bei Aufruf der Konfigurationssoftware: Anwahl https://autoit.de/www.mystora.com, Username und PW eingeben (ja, wirklich - immer über Internet!)
- nach erfolgreicher Authentifizierung Redirektion mit Sitzungs-ID auf die Stora
- und nun erst hat man Zugriff auf die Konfig-Oberfläche

denk dran, der 1.April ist erst in 2 Wochen!
Mal Ernst beiseite, so etwas hab ich ja noch nie gehört! Was das für einen sittlichen Nährwert haben soll bleibt mir verschlossen....Wenn das Ding einen "DAU-Modus" hat, dann reicht doch ein DHCP-Server völlig aus oder etwa nicht?
Kabel rein, 20 sec warten, Daten draufschieben, fettich....
OK, wenn gänzlich jungfräulich, dann per Browser noch einrichten. Aber es soll Geräte geben, die infolge einer ordentlichen Benutzeroberfläche garkein Handbuch brauchen.....

Zitat

Wer sich das wohl ausgedacht hat?

...die Putzfrau....

Zitat

Das ist Zufall und den kann man nicht beeinflussen oder berechnen, oder?

Das eine hat mit dem anderen nichts zu tun! Du kannst eine Münze 30x werfen und immer fällt sie auf "Kopf", trotzdem ist die Wahrscheinlichkeit, daß sie auf Zahl hätte fallen müssen, jedes Mal 50% gewesen^^

Schnuffel
hehe, gesetzt den (Zu)Fall, das Gewinnerscript würde "nur" einen 4er erreichen, die Hölle würde losbrechen^^
Das Problem hatten wir schon vor 20 Jahren in der Schule, es gibt Zahlen, die signifikant oft gezogen wurden, und Zahlen, welche unterdurchschnittlich oft gezogen wurden. Die Frage des Tages ist nun: Ist die Wahrscheinlichkeit höher eine der "oft" gezogenen Zahlen zu ziehen, oder eine der "weniger oft" gezogenen?

so etwas ähnliches....

Bild auswählen und die Farben werden mit denen einer selbst erstellten Palette (Farbverlauf) ersetzt

Thx für den Link, bin zzt an einer SSE2/3-Version, die berechnet 4 Pixel auf einmal, das optimieren der cachelines muss aber noch rein....
Jedenfalls ist es ziemlich flott, allerdings nicht mehr mit dem "Inline"-Assembler zu machen. Aber als Assembler-DLL sollte auch der 64-Bitmode funktionieren.
Allerdings ist das alles nichts gegen eine Demo, welche per CUDA (als superschön lesbarer C-Code) auf einer Nvidia-Grafikkarte läuft. Durch heftigstes Parallelisieren (macht der Compiler selbsständig) und völlig fehlender Hauptspeicherzugriffe (alle Daten liegen auf der Graka) ist der Code dort 40-50x schneller als ein hochoptimierter Code auf einer CPU. Das ist der Hammer!

Aber den Inline-Assemblercode bekomm ich auch noch doppelt so schnell wie zzt^^, dann fehlen nur noch ca.10000% bis zu CUDA...

Zitat

edit: man bin ich heut langsam

...und hast genau wie ich auch noch den Hinweis auf

_choosecolor()

vergessen

Hallo,
ja, das System ist relativ einfach. Kommt nur darauf an, auf was man sich einigt^^
Im 32-Bit-Farbsystem werden die einzelnen Farben als (hex) AARRGGBB oder AABBGGRR dargestellt
Dabei sind die 2 Byte AA der Alphakanal (für die Transparenz), BB 2 Byte für Blau, GG 2 Byte für Grün und RR 2 Byte für Rot

also ist (im RGB-Format) 00FF0000 ein Rot und 000000FF ein volles Blau.

$hgui=guicreate("")
GUISetBkColor(0xFF0000,$hgui) ;RRGGBB
guisetstate()
for $i=1 to 0xFFFFFF
GUISetBkColor($i,$hgui) ;RRGGBB
next

Do
until guigetmsg()=-3

Zitat

Einige Seiten überlagern sich allerdings ohne den natürlichen Weg des Lichts zu berücksichtigen.

das meinete UEZ mit der Z-Achse. Beim "transparenten" Würfel ist es egal, ob von hinten nach vorne oder von vorne nach hinten aufgebaut wird. Da sieht man nur die Kanten. Beim "texturierten" Würfel ist das Problem, die hinteren Flächen zuerst aufzubauen, damit sie anschließend von den vorderen, sichtbaren Flächen überdeckt werden. Bei 3D-Programmen kann man daher sehr viel Rechenzeit sparen, wenn man die hinteren (unsichtbaren) Flächen erst garnicht darstellt (Z-Buffer),