Beiträge von Andy

Zitat

Der Zweck des Effektes ist es, glatte Übergänge zu haben,

DAS ist richtig!
Das aber mit Anti-Aliasing gleichzusetzen, DAS ist falsch.
Du lässt das Aliasing garnicht erst zu (wenn du die "Auflösung" verfeinerst), ergo kannst du auch garkein ANTI Aliasing darauf anwenden!
Anti-Aliasing ist ein Verfahren, dass ein bereits bestehendes Bild im NACHHINEIN so bearbeitet, dass es diese "glatten Übergänge" bekommt!
Wenn das Bild schon im Vorfeld keine (sichtbaren) Treppenstufen hat, dann bewirkt ein AA-Algorithmus bestenfalls nichts...außer Performance zu fressen...

Zitat

Select und Switch (das wird in Tidy immer versemmelt).

Kann ich nicht bestätigen, bei 1.79 läuft das mit Tidy einwandfrei

Hi,
der Effekt ist fein, aber

Zitat

Die Effizienz deines AA Algorithmus ist... unkonventionell

ist noch *hust* stark untertrieben, da das Ganze absolut NICHTS mit Antialiasing zu tun hat
Bevor man etwas ANTI-aliased muss es vorher erstmal aliased sein

Schon mal vielen Dank, wir werden das ausprobieren!

Hi,

Zitat

Und wie soll das gehen (z.B. bei user32.dll?). Bitte ein Beispiel geben!

Ich habe dieses Verfahren schon in mehreren Scripten verwendet, wenn dich das Thema so interessieren würde, wären dir diese Scripte bekannt, oder du hättest in den entsprechenden Threads die Anwendung der verwendeten Funktionen nicht verstanden und dort nachgefragt.
Auch im "blauen" Forum hättest du reihenweise Informationen bekommen, such dort mal nach Subrogation.
Weiterhin liefert die Anfrage bei der Suchmaschine deiner Wahl tausende von Treffern incl. Beispielprogrammen!

Es wäre auch bestimmt kein Problem gewesen, nach DllCallAddress() zu suchen, aus welchem Grund denkst du, ist dieser Befehl überhaupt in AutoIt umgesetzt worden?
Die Win-API wurde auch größtenteils in AutoIt umgesetzt, bissl stöbern in MSDN schadet sicher nicht. Da stößt man dann zwangsläufig nach einigen Minuten u.a. auf

_WinAPI_GetModuleHandle()

und GetProcAddress().

Und nein, ich lege nur ungern jemandem den Arm aus der Sonne....

Zitat

Im Taskmanager habt ihr ja sicher geschaut, ob die Excel.exe am Laufen ist...

ja, das ist ja das seltsame....Excel läuft lt. Taskmanager.
Was ich herausgefunden habe, ist dass es, wie du schon bemerkt hast, Probleme gibt bei Anzeigen wie einer msgbox bspw. Dann bleibt das Script auch stehen, daher habe ich es prophylaktisch mal als CUI kompiliert, half auch nichts.
Ich vermute, Excel startet und zeigt irgendein Fenster an, welches wir ja nicht sehen, da aus dem Taskmanager gestartet wird.
Wir haben auch schon eine Batch erstellt, in der das Script aufgerufen wird. Das Batchfile von Hand gestartet läuft, aus dem Taskmanager gestartet bleibt es stehen...

Hi,
Danke für die Antwort.

Zitat

Läuft der Taskplaner nicht mit Systmerechten?

Muss ich prüfen, wäre aber ein Ding, da auch andere Tasks problemlos zumindest diese Excel-Dateien kopieren...

Zitat

Hat das "System" (der Server selbst) Berechtigungen auf diese Excel-Dateien zuzugreifen?

Es wäre schon schön, wenn vor dem Zugriff auf die Datei Excel erstmal starten würde^^

Zitat

Falls der Zugriff über einen (Netzwerk-)Share auf die Excel-Dateien erfolgen soll, muss der Server die Berechtigung bekommen darauf zuzugreifen.
Dafür ist es nötig den Gruppen Network und Domain Computers (in einer Domäne) zumindest Leserechte auf diesem Share zu erteilen.

Das hatten wir überprüft und auf Dateien zugreifen wollen, die nicht freigegeben waren. Da dort aber kein COM-Error auftritt, bin ich auf das "Debugging" mit den Textdateien gekommen.

Bei Zugriff auf nicht freigegebene Dateien (im User-Context) wirft das Script einen ganz "normalen" Excel-Fehler (Zugriff wg fehlender Rechte verweigert)

Hi,
ich hole diesen Thread nochmal nach vorne weil ich heute bei folgendem Problem nicht weiterkomme.

Habe ein AutoIt-Script erstellt, welches über COM auf div. Excel-Tabellen zugereift. Dieses Script läuft tadellos in meinem und in anderen (u.a. Admin-) Usercontext.
Nun kam unser Admin auf die Idee, dieses Script per Taskplaner auf dem Server 2008 zu starten, nachdem er sich (als Admin auf dem Server) per Doppelklick zum Starten davon überzeugt hatte, dass alles einwandfrei läuft. Das Script als EXE-Datei startet, die Excel-Files werden bearbeitet, alles schick.
Also das Script in den Taskplaner des Servers eingetragen, testweise aus dem Taskplaner gestartet und das Script läuft nur so lange, bis die COM-Verbindung zu Excel hergestellt wird. Dann bleibt das Script ohne Fehlermeldung und ohne COM-Fehler einfach stehen.
Wir haben schon mit den Rechten experimentiert und sämtliche Möglichkeiten in den Einstellungen des Taskplaners durchprobiert.
Ich habe schon die #RequireAdmin eingebaut, das Script unter x86 und x64 compiliert. Wie gesagt, von Hand gestartet läuft es einwandfrei, im Taskplaner bleibt es genau an der Stelle an der

Filewrite("Test1.txt"," ") ;Datei wird erstellt, testweise
$oExcel = ObjCreate("Excel.Application") ;hier bleibt das Script stehen
Filewrite("Test2.txt"," ") ;Datei wird nicht erstellt

aufgerufen wird, stehen.
Bei der Abfrage des COM-Error schreibe ich auch in der ersten Zeile eine Testdatei, aber dort kommt das Script nie an.

Hat jemand die Möglichkeit, dieses Phänomen auf Server 2008 zu testen oder weiss jemand, an was das liegen könnte?

@Make-Grafik,
war mir doch klar...

Hi,

Zitat

Echt klasse was ihr immer aus AutoIt raushaut und umsetzt! (Naja, auch wenns bischen ASM gecheatet ist )

"Gecheatet" würde ich das nicht nennen, lediglich das Erkennen von Defiziten und deren Umgehung. An ASM ist in keinster Weise etwas irregulär oder gar unmoralisch oder betrügerisch!
Mal angenommen, das Script würde 1:1 nach C++ übersetzt, so würde eine ähnliche Framerate entstehen. Dieses Script in ein beliebiges C++-Forum gestellt und nach Hilfe zur Beschleunigung gefragt, wäre ich mal SEHR gespannt auf die Beiträge der qualifizierten User.
Da sämtliche GDI+-Funktionen nicht zu beschleunigen sind, bleibt also nur noch der Rest....also das, was eukalyptus in ASM-Code umgesetzt hat, und das sind Berechnungen.
Und die zu optimieren, dafür braucht es das KnowHow, und nicht einen "schnellen" Compiler! Letztendlich würden einige Handvoll C++-Cracks den vom Compiler fabrizierten Code profilen und disasseblieren, und irgendwann käme einer daher und würde die letzten 3-4 FPS über einige Zeilen Inline-ASM rausholen. Dann wäre er kein "Cheater", sondern ein von allen vielbeachteter Programmierer!
Wenn jemand dasselbe in AutoIt macht, ist er ein "Cheater"?

Und für die Idee und deren Umsetzung (s.UEZ´s viele tolle Beispiele) braucht es viel Phantasie und noch mehr Gehirnschmalz....beides etwas, was ich 99,9% aller c&p-"Cheater" abspreche!

UEZ,
für eukalyptus reicht ein einzelner smilie nicht, ich hatte eher an so etwas gedacht: [Blockierte Grafik: http://sarpbc-forum.birk-gollin.de/images/smileys/betengros.gif]

Hi,

UEZ,
sehr sehr nice

eukalyptus
DAS nenne ich mal ein schickes Stück Code!!! *wieso gibts eigentlich keinen "verbeug"-smilie*
Habe mir den ASM-Teil natürlich disassembliert und mal drübergeschaut, weil die Funktion _PW_Warp() doch relativ lange läuft. //EDIT// uups, meinen Text viel zu lange editiert und posten verpennt, der ASM-Code ist schon da! Btw, auch sehr schön kommentiert!

Versuche mal, den Teil im Stack, in dem du die XMM-Register speicherst, an einer 16-Bitadresse zu alignen. Das hat den Vorteil, dass du diese Adressen per MOVDQA statt MOVDQU lesen/schreiben kannst.

Dann habe ich festgestellt, dass du den größten Vorteil bei SSE, nämlich das parallele Ausführen von Code, nicht genug nutzt.
Ja, das ist auch teilweise schwer, Abhängigkeiten bleiben halt nicht aus.
bsp:

Zitat

movdqa xmm0,xmm1 ;xmm0 bearbeiten
mulps xmm0,xmm3 ;xmm0 stall, wartet darauf, dass der vorige Befehl abgearbeitet wurde
movdqa xmm4,xmm5 ;andere Register bearbeiten

schneller:

Zitat

movdqa xmm0,xmm1 ;xmm0 bearbeiten
movdqa xmm4,xmm5 ;läuft in der instruction Pipeline parallel zur zeile vorher, da keine dependencies
mulps xmm0,xmm3 ;xmm0 muss nicht auf den vorigen Befehl warten, schneller

das bringt idR dann etwas, wenn diese Zeilen im inner loop sehr häufig durchlaufen werden.

Wenn wir schon beim Inner Loop sind, Code Aligning ist sehr wichtig!
Vor die Loops gehört ein "align 16" (habe ich jetzt nicht geschaut, ob du das gemacht hast, finde aber auch keinen Hinweis, dass du es gemacht hast^^)

Auch die AutoIt-Structs, aus denen du Daten liest/schreibst gehören 16-Byte-aligned!Da das align16 innerhalb von dllstructcreate nicht zuverlassig funktioniert, habe ich mir eine Funktion dafür geschrieben

Wenn du die Möglichkeit hast, dann bau die Struct direkt so, dass du immer 16-Byte Blöcke holen kannst.
Wenn du 2 Structs mit Datenpaaren hast (Erste in Struct1, Partner in Struct2) dann schreib statt
Struct1=X1,X2,X3,X4,X5...
Struct2=Y1,Y2,Y3,Y4....
eine Struct mit
Struct=X1,Y1,X2,Y2,X3,Y3......
das reduziert massiv die Cache-Misses beim lesen!
Apropos....per Prefetch lässt sich der Cache mit Daten "vorladen".

Das profilen des Codes bzw. Ausstoppen der Laufzeiten mache ich mit einem simplen RDTSC am Beginn und Ende des Loops....

Aber ansonsten absolut super!
Ich wäre echt mal gespannt, was ein C-Compiler aus dem Code gemacht hätte, vielleicht erbarmt sich ja mal jemand und compiled den Algorithmus mit /SSE-Flag...

Hi,

Starten von DLL-Funktionen aus dem Speicher ist möglich.
Dll-"Inhalt" per dllstructcreate() usw. in Speicher schreiben und die Funktionen dort per DLLCallAddress() aufrufen.
Die Adressen bzw. Offsets kann man sich per _WinAPI_GetModuleHandle() holen....

Hi,

Zitat

Und zwar möchte ich einen beliebigen String in ASCII Codes konvertieren und die ASCII Codes ins Dualsystem befördern.

verstehe ich und kann das auch nachvollziehen...
Was ich absolut nicht verstehe ist der Umweg über die Arrays.
Ein String IST bereits ein Array....zwar nicht ein zweidimensionales wie bei dir^^, aber ein Array!
Wie du ja seltsamerweise in deiner Lösung per StringMid() gezeigt hast, ist dir dieser Befehl ja bekannt.

Ok, hier nun mein Lösungsvorschlag.
Als Standard wird ein 3-Bit-"Array" zurückgegeben, wenn man als zweiten Parameter eine Ziffer von 1 bis 8 eingibt, erhält man das entsprechende Array.

Hi,
sehr gut, das hilft weiter! Die Buffer werden nicht richtig initialisiert.
Es sieht dann wohl so aus, als ob das Problem nicht bei CL, sondern (wie ich schon seit einem Jahr vermute) bei GL liegt!
Also eher weniger bei GL direkt, sondern bei AutoIt, das irgendetwas im Hintergrund macht, was nicht so astrein ist.
Ich habe auf dem WIN7-Laptop teilweise nämlich sehr seltsame "Kamm-Artefakte", die ab und zu , wenn das Script kompiliert wird, nicht auftreten.
Denn wenn ich die CL/GL-Beispiele der SDK´s mit C++ kompiliere (VS2010) läuft alles einwandfrei. Ich habe die Beispiele, welche ja auch nur die GL-API aufrufen, 1:1 nach AutoIt portiert und dort gibt es teilweise Anzeigefehler...

Hi,
wie schon gesagt funktionieren deine Scripte auch unter Win7 (die meisten jedenfalls^^), allerdings im "Win7"-Style.
Wenn du, aus welchen Gründen auch immer, unbedingt auf XP angewiesen bist, oder Fenster in diesem Style brauchst (oder Fenster in diesem Style "bearbeiten" musst *husthust*) dann erstelle dir entweder eine Virtuelle Maschine VM und benutze darin einfach deinen "alten" Rechner (Image erstellen und reinkopieren), oder probiere in Win7 Ultimate das integrierte (auch in einer VM laufende) XP.
Ich würde das integrierte XP verwenden, dort installierte Programme hast du sogar im Startmenü von Win7....

Orion,
Alda, dem is ULTRAKRASS!
Sehr cool, was eure Grakas alle so darstellen....wenn ich das richtig sehe, ist das ein Teil des Hintergrundes, der auf die Würfeloberflächen projeziert wird?!
Welche Hardware hast du?

@TheShadowAE,
danke fürs Testen!
Ich werde wohl nicht drumrum kommen, alle verfügbaren Platforms abzuklappern und dort nach einem Device zu suchen, welches eine GPU ist....
Dann wäre das zumindest schon einmal geklärt.
Solange die sich drehenden Würfel dargestellt werden ist es ja schonmal halb fertig^^

Hi,
frag dich mal, aus welchem Grund jemand x-mal in der Sekunde haufenweise Buttons und anderes Gedöns in ein Fenster "zeichnen" sollte, obwohl sich in diesem Fenster garnichts tut?!
Wieso zeichnest du nicht die Buttons in ein Fenster und stellst es EINMAL dar und fragst dann nur noch die Buttonevents ab?

Fürs waagrechte Scrollen einen kostenlosen Speedtip^^:
Erstelle eine Bitmap mit der Größe (Gesamtbreite x HöheScreenx0.9). Die Gesamtbreite ist die von dir vorgegebene Größe des scrollbaren Bereichs, sagen wir mal 10000 Pixel.
In diese Bitmap zeichnest du deine zu scrollenden Buttons.
Jetzt musst du nur noch mit einem BitBlt() den vom Slider angegebenen Bereich, also gewissermaßen einen Ausschnitt deiner Grafik (die Buttons) in das Fenster blitten.
Die HöheScreen wird nur mit 0.9 (oder 0.5 oder 0.4) multipliziert, da du nur den Streifen brauchst, den du scrollen willst, im Extremfall also nur einen Streifen von der Höhe der Buttons.

Du kannst natürlich auch einfach jeden einzelnen Button aus einer Bitmap heraus in dein Fenster blitten, aber alles ist schneller, als den Button jedes mal neu zu zeichnen!

Hi,
@TheShadowAE,
lt. deiner Console müsste es durchlaufen, sowohl GL als auch CL werfen keine Fehler....

Zitat

Wieso benutzt du GLCL_easy nicht bei den Würfeln? Da hatte ich die ganze Zeit getestet )

weil ich ein fauler Sack bin....
Nein, ich dachte mir schon, dass es bestimmt nicht auf Anhieb glatt läuft (Intel/Nvidea), dafür habe ich mich zu lange mit dem Dreck beschäftigt
Also CL läuft nun auf deiner Grafikkarte, das ist schon mal gut, nun müssen wir das nur noch hinbekommen mit der "richtigen" Grafikausgabe im Fenster.
Die Würfel scheint es ja schon mal zu zeichnen^^, ggf kann minx mit dem Bild was anfangen....

Hmmm, anhand der FPS und der Kerneltime könnte es sein, dass doch deine CPU verwendet wird^^
Probier mal in Zeile 66 testhalber von setGLCLautokernel() in

setGLCLautokernel("CPU")

und wenn das nicht funzt dann nochmal in Zeile 107 zurück zu $num....=1

Zitat

Also ich hatte mir den Code von hier nicht mehr geladen, sondern mir eine eigene SDK zusammengezimmert, da Andy mir immer nur Bruchteile geschickt hat .

was heisst Bruchteile, das war alles....mehr braucht man auch nicht.
Und wenn man jetzt einen x-beliebigen Benchmark startet, der im Fehlerfall einfach abbricht bzw. "geht nicht" anzeigt, dann kommt man auch nicht wirklich weiter...

Zitat

Die neuen Treiber lassen sich hier laden: http://www.geeks3d.com/

DAS ist genau der allergrößte Fehler!!!
IdR empfehle ich auch die neuesten Treiber, allerdings ist das bei der Interoperability von OpenCL und GL (gerade bei AMD) nicht immer vorteilhaft. Die neuesten Treiber sind IMMER schnell zusammengestrickte, auf die letzte Rille fertig gewordene Konstrukte bei denen man HOFFT (nicht weiß ! ), dass die allerneuesten Features der allerneuesten Grafikkarten unterstützt werden.
Jedenfalls habe ich mir schon mit neuen Treibern auf dem Laptop massiven Ärger, und nicht nur in der Grafikdarstellung, sondern auch mit Blackscreens nach dem Aufwachen aus dem Standby/S3+4 eingehandelt. Mit dem alten Treiber lief alles wunderbar, nur bekomm mal einer den neuen Treiber komplett aus dem System geschmissen...
Wenn jemand eine 3 Jahre alte Grafikkarte hat und mit dem damals aktuellen Treiber der Rechner problemlos läuft, dann besteht auch kein Grund, ohne Not den Treiber zu updaten!
Übrigens ist die verwendete CL/GL Version bzw. deren SDK sehr eng mit den Treibern verknüpft, wenn, dann sollte man schauen, dass beides zusammenpasst, siehe Seite (Text auch mal durchlesen ^^ ) hier ganz unten!

Trotz allem sollte man die bei minx´s geposteten CL-Benchmark-Link auf der rechten Seite die Hinweise beachten!

//EDIT// Ich spreche solche "Kleinigkeiten" an, wie die unter den Tisch gekehrte Mitteilung von bspw. AMD, dass mit Runterladen der allerneuesten Treiber und CL (Version 1.2 )-SDK´s keine 32-Bit-Betriebssysteme mehr unterstützt werden!
Wer also Open CL und GL zusammen auf z.B. XP32 benutzen möchte (was einwandfrei funktioniert! ) muss die passenden Treiber und das CL-SDK Version 1.1 installieren!
Wie das Bei Nvidia/Intel aussieht sollte man dort abgleichen!

Die Frage ist, wieso bei einigen Usern mit Nvidia-Karte die CL- und auch die GL-Beispiele jeweils einzeln einwandfrei funktionieren, aber in Zusammenarbeit (Interoperability) dann Probleme auftreten...

Die Kombination OpenCL auf CPU und OpenGL auf (wie auch immer GPU) ist sowieso schwierig. Ich vermute da einfach weniger Probleme in der API, als fehlerhafte oder komplett fehlende Unterstützung in den Treibern! Siehe auch diverse Forenbeiträge zu diesem Thema bei den Linuxern, dort wird die Kombination CL/GL sehr gerne verwendet!