Beiträge von Andy

So, kurze Rückmeldung....

Hab bissl Trouble mit der Transformation in die "Schiefheit". Zum Vergleich, das linke von eukalyptus(soll das so sein?), das rechte meins(soll das so sein?).
Hab mal mehrere mathematische Varianten durchgespielt und als AutoIt-Script laufen lassen. Auf Pixelebene bin ich in AutoIt so schnell wie die Eukalyptus´sche Orginalfunktion beim High Precision Rendering. Um mal ne Hausnummer zu nennen, in Assembler sollte Faktor 100 beim Speed drin sein .
Bin zzt. ziemlich eingespannt, dazu kommt noch zeitweise Gehirnkrampf (altersbedingt ), wäre daher für Tips/Funktionen/Infos dankbar....Welche Variante
_IconNameToID.au3 Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Glücklichen Herzwunsch und alles alles Gute dir und deiner Familie!

*mitschnief* (Video geguckt!)

Hi,
such mal hier im Forum nach PushTheButton
dieses Programm wurde für den Anwendungsfall Terminal erstellt.

Naja, natürlich wäre es möglich, einen Treiber in AutoIt zu schreiben, genau wie ein Betriebssystem. Können kann man alles, abhängig vom Aufwand!
Das ABER ist lediglich die Verwendung des RICHTIGEN Werkzeugs für eine Aufgabe! Du kannst ein Haus abreissen, indem du eine Stichsäge am Kabel gegen die Wände schleuderst. Nach 12000 verballerten Stichsägen und 6.5 Jahren maloche liegt das Haus in kleinen Trümmerteilen vor dir....Aufgabe erfüllt! Eine Abrissbirne erledigt diese Aufgabe in 10 Minuten...

Denn Treiber kann man übrigens nichtmal mit Assembler schreiben.Oh doch, man kann^^. Da man sämtliche in C++ einbindbaren Dateien (Funktionssammlungen, mehr ist das nicht) auch in Assembler einbinden kann (Falls es diese nicht in "native" Assembler gibt), obj-files ftw!
Aber man kann auch mit den entsprechenden technischen Unterlagen und dem nötigen KnowHow direkt in Assembler einen Treiber erstellen. Wobei wir wieder bei der Frage mit dem richtigen Werkzeug wären!
Ein Treiber ist nichts weiter als ein "Übersetzer", der eine allgemein gehaltene Funktion z.B. aus einem Betriebssystem oder einem Programm in eine wesentlich tiefere Ebene (Kernel/Hardwarezugriff) transferiert, auf die man sonst keinen Zugriff erhält. Treiber für selbst gebaute Hardware schreiben macht immer am meisten Spass Wer mal eine Platine mit diversen Chips zusammengestellt hat, der weiss idR auch, wie er diese zu programmieren hat

Greenhorn hat recht, da AutoIt-Funktionen per se nicht threadsicher sind. Prog@ndy hatte da mal schöne Beispiele, um das zu demonstrieren^^

Ich hatte im Umfeld des ASM-tuts auch "echte" Multithreading-Programme vorgesehen. EINE Funktion, die beliebig oft während ihrer Laufzeit aufgerufen werden kann. Funktioniert einwandfrei. Allerdings spielt das dann wirklich schon auf einem anderen Stern...
Threadsicherheit ist das Problem in AutoIt!

Zitat

Die Beispiele hier haben auch nichts mit Multitasking oder -Threading zu tun.

Das kommt noch dazu
http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx

Zitat

Die Symbiose von GDI+ und ASM würde den Turbo einschalten, aber muss man erst mal ASM können...

naja, da das Bitmapformat ziemlich einfach ist, bietet sich das "üben" in ASM natürlich an. Ich breche mir auch hin und wieder einen ab, aber im grossen und ganzen braucht man wirklich nur 10 Befehle. GDI+ ist ja nur deshalb so "langsam" weil wirklich idiotensicher und universell. Wenn man das gesamte "Fehlermanagement" in die Wrapperfunktion auslagert, bleibt die eigentliche Pixelmanipulation extrem schlank und damit auch schnell. Ich setz mich mal dran....

Gerade für 3D-Darstellungen würde sich natürlich die Trapez/Dreieck-Transformation anbieten! Inwieweit sich damit zu D3D oder OpenGl aufschliessen lässt? Schaumamal...wenn die Flächen nicht zu gross werden, sehe ich darin eigentlich kein grösseres Problem

Hi eukalyptus!

Zitat

Nun hab ich eben solch eine Funktion geschrieben, allerdings ist sie nicht gerade die schnellste

kann ich nicht bestätigen! In deiner Demo wird das Trapez bei Bewegung der Eckpunkte in Echtzeit nachgezeichnet. Bei höherer "Empfindlichkeit" ruckelt es etwas, aber das wirkt sich nur bei extrem flachen Betrachtungswinkeln aus...
Mal schauen, die "inner Loops" lassen sich mit einer Handvoll Assemblerzeilen sicherlich beschleunigen. Wird Zeit für ein 64Bitsystem bei mir, dann baue ich so um, dass die ASM-Beschleunigungen auch auf 64Bit funktionieren/compilieren.

Zitat

_GDIPlus_GraphicsDrawImageRectRect() sollte doch das gleiche können ?

Sollte, macht aber leider nicht.....das "Rectangle" besteht nur aus 2 Punkten, damit ein Trapez zu beschreiben fällt....äääähmmmm...etwas schwer^^

Alles Gute AutoBert!

...und immer dran denken:"Männer werden nicht älter, Männer werden besser!"

Welche Info fehlte?

#AutoIt3Wrapper_Change2CUI=y

"setzt" den Haken "Create CUI statt GUI" ....

Zitat

Klar, ist ja logisch - "Word = unsigned 16 Bit integer"

Klassiker, man "setzt" die richtigen Bits und Bytes, aber was man "ausliest", das steht auf einem ganz anderen Blatt! Dazu kommt noch das Intelsche Little Endian, und die Verwirrung ist komplett^^. Hat mich früher auch schon einige Nachtschichten gekostet, daher kann ich das nachvollziehen

Auch von mir glücklichen Herzwunsch zum Geburtstag!
Leute wie Xeno sind eine echte Bereicherung! Lass es richtig krachen, und geniesse deine "Jugend" (harhar)!

Techmix, wie "Netzwerkkarte verloren"?
Die "MAC ändern" brennt keine neue Daten in den Chip (EEprom), lediglich beim Auslesen werden die auszulesenden Daten durch "geänderte" ersetzt. Die MAC ist jedenfalls in allen mir bekannten Karten in HARDWARE gegossen, wäre es anders, wäre das System unnütz. Bei steckbaren Netzwerkkarten stand die MAC früher im BootROM, heute ist sie vielleicht in einem anderen Chip vergraben, aber sicher nicht durch ein 08/15 Programm hardwaremässig zu ändern.
Vgl. http://de.wikipedia.org/wiki/Locally_Administered_Address und http://de.wikipedia.org/wiki/Universal…istered_Address
Ich kenne Admins, die Ihr Netzwerk statt nach IP-Adressen nach (eigens zusammengestellten) MAC-Addressen sortieren da werden dann die MAC-Adressen den IP´s "zugeordnet", so kann man auch auf den untersten Layern schnell erkennen "wer" da mit "wem" spricht .

Irfanview kann doch auch ohne weiteres aus x-beliebigen Bildern Schwarzweissbilder machen
dazu in der Batchdatei /bpp=1 angeben....
oder im Programm direkt bei "Bild/Farbtiefe reduzieren/2 Farben (Schwarzweiss)"

benenne die Autoit-Datei (die *.EXE) mal um,
CMD.EXE startet einen neuen Kommandointerpreter im aktuellen Verzeichnis. Wenn das AutoItscript CMD.EXE heisst, wird es vom System wie ein Kommandointerpreter behandelt.
Bei mir im XP gibts da kein Problem, es wird einwandfrei in die Konsole geschrieben! Aus

;cmd.exe
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_UseUpx=n
#AutoIt3Wrapper_Change2CUI=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
CONSOLEWRITE(@crlf&"HALLO, hier ist AutoIt!"&@crlf&@crlf)

und

echo off
cls
echo Jetzt kommt die AutoIt-Nachricht
cmd.exe
pause

wird Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

/EDIT/ START startet den Kommandozeileninterpreter, übergibt im ein Programm und kehrt dann sofort wieder zurück, je nach Rechner geht das so schnell, das bekommt man garnicht mit....

Zitat

Als Retro-Deko?

Nein, dafür ist er mir zu schade, aber "alte" (richtige) DOS-Spiele und auch "ernsthafte" Anwendungen (die direkt auf Ports und auch Hardwarebausteine zugreifen z.B.) laufen dort ohne Umbauarbeiten!
Wenn er mal gebootet hat (in der zwischenzeit Kaffee kochen gehen ist locker drin ) arbeitet sich echt angenehm, tolle Tastatur, übersichtlicher Bildschirm....und man definiert "schnell" und "gut" auch wieder ganz anders. Schreibt man einen Brief schneller oder fehlerfreier oder mit besserer Ausdrucksweise auf einem 40x "schnelleren" und wesentlich moderneren Rechner?

Reduktion aufs wesentliche FTW!

Oscar , hab mal nachgeschaut, Baujahr 1997/98
Der Savage 3D war innovativ, ist aber u.a. an/wegen der miesen Treiber gescheitert. Noch Fragen?
Habe zwar früher mal Grafiktreiber programmiert/optimiert, aber erstens ist das lange her und zweitens sehe ich keinen Sinn darin,

Zitat

nen funktionierenden xp treiber hab ich hier rum liegen

umzuschreiben bzw völlig neu zu schreiben! Von der Beschaffung der notwendigen Datenblätter mal abgesehen.
Wobei aber auch MS das Treiberkonzept von Win7 gegenüber XP völlig über den Haufen geworfen hat, "bissl umschreiben" fällt daher komplett aus!

Meine Tochter hat ein 120 Mhz-Toshiba Laptop von 1996 mit Win98 in "Gebrauch", der erfüllt seine Aufgaben immer noch einwandfrei, ich käme da nie auf die Idee, ein anderes System draufzuspielen.

Zitat von i2c

Mit dieser Aussage im Hinterkopf stellt sich mir die Frage ob es nicht einfacher und sinnvoller wäre, das Betriebssystem zu wechseln.

Was wäre an einem "anderen" BS besser als an einem funktionierenden XP? Würden die "Gimmicks", die jeder Laptopbauer damals in seine Produkte integriert hat, auch funktionieren? Damals wurden die Geräte mit Treibern für eine bestimmte Windowsversion ausgeliefert, fertig. Wer ohne Herstellersupport "Upgraden" wollte, hatte schon reichlich Probleme, das Gerät überhaupt zum laufen zu bekommen. Wie sagte mal ein Hersteller zu mir? "Die Treiber sind unser Dongle für die Hardware!" (wer die neue Software benutzen will, soll gefälligst auch die neue Hardware bei uns kaufen!)

war zu langsam mit dem Edit im vorigen Post^^
lt MSDN können die Sampler wohl auch während der Laufzeit bestimmt werden und sind, falls nicht "definiert", einfach "leer", d.h. ohne Filter/Textur

http://msdn.microsoft.com/en-us/library/bb509677(VS.85).aspx
beschreibt die tex2D()-Funktion (mehr schlecht als recht)
Wenn ich das richtig verstanden habe (bin kein C-fuzzi), dann werden die x-Koordinaten der Vektoren(Pixel) mit tex bezeichnet
In dem Fall ist mit r das rechte Pixel und l das linke Pixel (tex.x/2) gemeint (side by side)
Die resultierenden Farbanteile werden aus diesen beiden Pixeln berechnet:
red = links.gruen * 0.7 + links.blau * 0.3
green = rechts.gruen
blue = rechts.blue

so seh ich das^^ aus 2 Bildern wird eins gemacht, pixel für pixel

/EDIT/
tex2D ignoriert den z-Anteil (Buffer)
s0 ist ein sog. Sampler, der sowohl eine Textur, als auch eine Mischung aus diversen Filtern sein kann. Der Sampler wird dann auf das Pixel angewendet.

Hi, ich hatte mich auch schon mit diesem Thema auseinandergesetzt, allerdings wurde mir das aufgrund fehlender "ernsthafter" Problemstellung zu aufwendig!
"Just for fun", da stehen bei mir andere Sachen vorne auf der Prioritätenliste!

Zunächst unterscheidet man Vertex- und Pixelshader. Um mit Vertexshadern zu arbeiten braucht man zunächst ein 3D(Gitter) Modell. Vertexshader werden eingesetzt um diese Gitter-Modelle zu bewegen wie z.B.drehen, verformen, Wellen im Wasser zu generieren o.a. Ein/mehrere 3D-Modeller und das dementsprechende Know-How sind also Pflicht. Transformationen von BewegungsPfaden/Vektorrechnung sollte man beherrschen!

Die Pixelshader sind dafür da, die Gittermodelle mit Texturen zu versehen und diese mit Filtern (Beleuchtung, Nebel, Spiegelungen) zu bearbeiten. Filterfunktionen, Transformationen usw sind hier Vorraussetzung!
Der große Vorteil der Shader ist, dass die Graka selbstständig je nach aktueller Auslastung diese Berechnungen beliebig parallelisieren kann!

Was bei der Programmierung von Shadern vorausgesetzt werden muss ist HÖHERE Mathematik. Wer meint, bissl Sinus und Cosinus reicht, kommt nicht weit! Ob es sinnvoll ist, sich ein 3/4 Jahr den Ar*** aufzureissen, damit sich einige "schwebende Würfel" über einer spiegelnden Ebene drehen können, lasse ich mal dahingestellt! Aber im Endeffekt sieht es genau so aus.....

Eine meiner Lieblingsseiten zu diesem Thema ist übrigens schon seit langem http://www.iquilezles.org/www/

Hard stuff is our daily Job! In diesem Sinne. HAUT REIN! Und lasst euch nicht entmutigen...