Beiträge von Mars

    Sooo dann schmeiß ich auch mal meinen Hut in die Runde.

    -> Idee war: Sortiere zunächst alles heraus was nach "Graustufen" aussieht und sortiere den Rest. Dadurch hat man etwas weniger "schwarze und weiße Linien" im Regenbogen. Wirklich gut sieht das auch nicht aus, aber vielleicht inspiriert die Idee ja irgendwen :)


    M

    Bei uns wird alles über E-Mails geregelt, auch kurzfristige Informationen (zum Glück bin ich nicht wichtig genug, sodass ich nur 5 Mails am Tag bekomme und nicht 100^^). Aber tatsächlich: "Druckerausfall", "Server Neustart", "Wartung", "andere Probleme" gibts eigentlich häufiger (da kommen so 1 bis 3 Meldungen pro Woche, wird ja vorsortiert, dass ich nur die Sachen bekomme die für mich auch relevant sind). 90% davon tangieren mich aber aktuell trotzdem nicht, da ich im Homeoffice sitze und mir ein PC gegeben wurde (privat PC's sind bei uns auch verboten), an dem ich (fast) alles machen kann. Von daher: "Nein, brauche ich gerade nicht, aber wäre ggf. irgendwann mal interessant", ich weiß ja nicht wo ich in 10 Jahren lande^^


    M

    Das erinnert mich daran wie die Leute aus dem EN-Forum unbedingt und unter jeder Bedingung wollen, dass wir Maps nicht als "Fake-Objekte" missbrauchen (obwohl das eine komplett valide Anwendungsweise ist).

    (Wahrscheinlich wird mein "same scope byref" feature request abgelehnt. Das würde den ganzen "Fake-Objekt" Kram sogar (fast) ohne Overhead und mit Schreibzugriff ermöglichen, da man $self = byref $m schreiben könnte, sodass $self echten Schreibzugriff hat und gleichzeitig muss $m nicht kopiert werden (da es byref ist, allerdings müsste dann auch Return ByRef $m möglich sein um den Overhead zu reduzieren)).


    Das obige Skript hat nur Lesezugriff via $self (logisch... es ist ja auch nur eine Kopie)

    lg

    M

    Mir sind ein paar Kleinigkeiten aufgefallen die ich vermutlich irgendwo eingebaut hätte:

    - Kleiner Hinweis wie du die Events nicht andauernd via Adlib durchlaufen musst: Verwende GUIOnEventMode und registriere dir GUI_EVENT_MOUSEMOVE. Dann wird die Funktion nur aufgerufen, wenn die Maus bewegt wird. Dadurch wird dein Programm nebenbei auch sehr viel reaktiver, weil nicht "alle 100ms" geprüft wird, sondern "sobald sich die Maus einen Pixel bewegt". Gleichzeitig wird keine Rechenleistung verbraucht wenn die Maus stillsteht.

    - Noch eine Idee wäre WM_NCHITTEST & Return $HTCAPTION (klappt nur, wenn die Maus "nicht" über einem Ctrl mit einem eigenen Handle ist, z.B. für GDI+ Stuff). Damit kann man ein Fenster bewegen, wenn man auf den Hintergrund des Fensters (und nicht auf ein Ctrl) klickt. Bin gerade nicht sicher ob, und wie das sinnvoll ist, aber vielleicht bringt die die Info ja etwas :) (PS: NCHITTEST feuert 1x pro Frame, also alle 16.6ms. Wenn man es nicht braucht sollte man es also vllt doch lieber weglassen^^)

    - GUIGetCursorInfo trägt bereits informationen zum Ctrl in [4], da braucht man nicht mehr umständlich via Positionen zu berechnen wo die Maus ist.

    - Bei Ctrls Farben zu aktualisieren tendiert zu flackern (auch wenn man es hier jetzt nicht wirklich sieht). Versuche die aktuellen Daten (Farbe, Schriftfarbe, Symbol, etc) nur dann zu aktualisieren wenn sich etwas ändert.


    Anbei ein Minimalbeispiel wie man ein Fenster bewegt und ein Ctrl umfärbt. Das Beispiel verwendet "alles" oben angesprochene, ob es sinnvoll ist UND nicht :D

    Edit: Es gibt auch noch eine Menge andere WM_XXX die man gebrauchen könnte. Am besten mal alle durchlesen (sind leider ziemlich viele^^).


    Edit2: https://www.autoitscript.com/w…g_and_Resizing_PopUp_GUIs <- Pflichtlektüre 8)


    lg

    M

    Probier das hier mal aus. Ist es das was du meinst?


    Mausinfo bekommt man jetzt per $Transform.Mouse, WorldSpace Koordinaten bekommt man via _GDIPlus_TransformMouseGetPos($Transform). Außerdem (weil es eh berechnet wird) gibts in $Transform.containsMouse noch die Info ob die Maus gerade im Rechteck ist. Vermutlich kann man das noch in $Transform.Mouse.inside oder ähnliches verschieben, ich bin aber kein Meister der Namensgebung, daher keine Ahnung.


    Einstellungen die Hinzugekommen sind:

    - Zoom Begrenzung (Min und Max)

    - Translation Begrenzung (via BorderX und BorderY implementiert)


    Ich habe mich dafür entschieden $Transform.einstellung, oder $Transform.information zu verwenden anstatt jede einzelne Sache in eine Funktion zu wrappen. Es ist meines Erachtens nach dumm 10 Funktionen zu schreiben, wenn man die Werte sowieso direkt setzen kann. Wenn man wissen will was alles einstellbar ist muss man eben in _GDIPlus_TransformCreate nachlesen was es alles gibt und was es alles macht.

    Neues Beispielskript das Zeigt was dazugekommen ist. Für die WorldSpace Koordinaten sind extra ein paar Testpixel gesetzt die man sich reingezoomt ansehen kann um zu schauen wie die Koordinaten aussehen.


    Edit1: Startpost geupdated.

    Edit2: Code entfernt, im Startpost ist der "richtige" Code.


    lg

    M

    Moin,


    Mir ist es jetzt schon häufiger untergekommen, dass ich in einem GDI+ Fenster gerne mit der Maus etwas bewegen und ggf. zoomen möchte (Linksklick -> Drag, Mausrad -> Zoom). Jedes Mal habe ich es wieder von neuem programmiert und mich geärgert, dass immer irgendwelche Zahlen nicht gestimmt haben (z.B. bleibt der Punkt unter der Maus beim Zoomen nicht an derselben Stelle, usw). Daher gibts jetzt eine UDF dazu die hoffentlich jedem weiterhilft der dasselbe Problem hat und ein wenig "interaktivere" GDI+ Anwendungen schreiben will. Da ist es nämlich immer schön, wenn der User ein wenig Spaß haben kann und nicht alles so furchtbar statisch ist.


    Es ist eine sehr kurze (ca. 100 Zeilen [Edit: jetzt 140 [Edit2: jetzt 160]]) UDF geworden. Verbesserungsvorschläge / Korrekturen sind gerne gesehen.


    Hier noch ein Minimalbeispiel, damit man schauen kann was die UDF eigentlich macht, und wie die Anwendung ist.

    Es sind nur 3 Zeilen nötig um einem GDI+ Viewport eine Maussteuerung zu verpassen. Einfacher habe ich es nicht hinbekommen ^^

    Für Einstellungen muss man in _GDIPlus_TransformCreate nachsehen welche Variablen es gibt, in den Kommentaren steht wofür sie verwendet werden.


    Edit 16.02.23:

    - Added: $Transform.Mouse [x, y, leftDown, rightDown, ctrlID]. Wird in TransformBegin automatisch aktualisiert und kann jederzeit abgerufen werden.

    - Added: $Transform.borderX & $Transform.borderY. Damit setzt man fest wie weit das Verschieben außerhalb des eigentlichen Bereichs gehen soll.

    - Added: $Transform.zoomMin & $Transform.zoomMax. Damit setzt man fest wie weit man hinein- bzw. herauszoomen kann.

    - Added: $Transform.smoothZoom. Damit bestimmt man wie "weich" der Zoom sein soll. Ein Wert von 0 deaktiviert das Feature. Erlaubt sind alle positiven reellen Zahlen.

    - Added: $Transform.containsMouse. Wird in TransformBegin automatisch gesetzt und gibt an ob die Maus im Viewport ist oder nicht.

    - Added: _GDIPlus_TransformMouseGetPos. Gibt die Koordinaten der Maus in Weltkoordinaten an. (im Beispielskript im Tooltip angezeigt. Schaut euch die Testpixel z.B. bei 0/0 an)


    Edit: 23.02.23:

    - Added: $Transform.moveButton. Hier kann man $_GDIPT_LEFT, $_GDIPT_RIGHT, $_GDIPT_MIDDLE angeben.

    - Added: $Transform.primaryDown. Hier kann man ablesen ob der bei moveButton gewählte Button gerade gedrückt ist.

    - Updated: Beispielskript, zur besseren Demonstration wozu man die Weltkoordinaten verwenden kann (z.B. um Objekte mit der Maus zu verschieben)

    - Beispiel, Links: Drag mit Mausradklick (middle), Objekte einzeln mit Linksklick auswählen und verschieben.

    - Beispie, Rechts: Drag mit Linksklick, Objekte mit Rechtsklick verschieben. (Soll demonstrieren, dass man auch interaktive Sachen innerhalb einer Trafo machen kann).


    lg

    M

    Ich glaube aktuell gehen ca. 20% der Zeit für simples "kopieren" (in EndScene, wenn die Structs befüllt werden), 20% für GDI+ und 50% für Matrixmultiplikationen und simple Mathematik und 10% fürs z-Buffer Sortieren drauf (bei "einem sehr großen Modell"). Gestoppt habe ich das nicht, ist nur eine Vermutung...


    Mir fallen auf anhieb einige stellen ein die man etwas aufbohen kann, wenn man eine dll oder asm nutzt, aber ich will erstmal schauen was man ohne diese Hilfsmittel rausholen kann. Klar in OpenGL eine primitiv beleuchtete Kugel mit 5000 Triangles anzuzeigen ist keine Kunst, in AutoIt ohne Hilfsmittel macht es deutlich mehr Spaß sowas zu machen :D


    Die vielen kaskardierten ORs sind doch eigentlich "der schnelle" Weg in AutoIt, oder? Einziges Problem in Test2 ist, dass meistens alle Vertices okay sind und daher die ersten 3 ORs nicht anschlagen können.

    Ein paar inner loops sind doof gelöst weil dort eigentlich nur der Mittelpunkt berechnet wird (z.B. in EndEscene -> Mittelpunkte berechnen & Sortieren), das kann man doppelt so schnell anderweitig lösen, oder 5x so schnell approximativ^^


    Im Lauf der Zeit hol ich nativ noch 20% performance raus... Dann schaue ich ob ich einige kritische Teile via inlineasm lösen kann. Und DANN baue ich einen "richtigen" Kugelgenerator (mit GUI und ganz vielen Slidern, sodass man nicht mehr von Hand im Code arbeiten muss wenn man seine Kugel designen will).


    M

    Ist wieder offtopic, aber das hat mich bei der Zusammenstellung der Regierung nach der Wahl gehörig aufgeregt: "Ministerium für Verkehr und Digitales". Was zum Teufel... Das sind doch vollkommen verschiedene Sachen und bei dem aktuellen Ausbaugrad der deutschen digitalen Infrastruktur und Bildung ist es mehr als nötig ein EIGENES Ministerium für Digitales zu haben, im Idealfall besetzt mit Leuten vom Fach die sich auskennen (da fallen mir ein paar Profs ein die "alles" wissen (auf ihrem jeweiligen Gebiet). Die wären für den Job perfekt. Vermutlich hätten sie aber verständlicherweise keine Lust :D). Stattdessen bekommen wir so ein paar windige Typen in nem windigen Ministerium wo "digitales" vollkommene Nebensache ist. Die fragen sich bestimmt ob die Cloud auch regnen kann.


    Lasst mich einfach Digitalminister werden. Ich hab einen Hass auf alles und keine Ahnung von "richtiger" Politik. Meine hinterzogenen Steuern kann ich auch selbst berechnen (Mathe kann ich ja). Das sind doch genau die Voraussetzungen die man braucht :D

    Ich frage mich halt immer wo die Logik hinter alldem ist. Man kann quasi alles zur Waffe umfunktionieren, oder irgendwie zweckentfremden, oder für (subjektiv) moralisch verwerfliche Sachen verwenden. Man muss doch langsam mal erkennen, dass "Vernunft" etwas ist das man nicht in Gesetze gießen kann. Vernunft verleitet dich dazu mit dem Brotmesser ein Brot (und nicht den Nachbarsjungen) zu schneiden, Vernunft verleitet dich dazu aus dem Nitratdünger keinen Böller zu bauen, sondern den Garten zu düngen. Aber bei all den Sachen ist es nicht das Gesetz das dich auf dem richtigen Weg hält, sondern dein Verstand.


    Ich bin einfach froh, dass ich anfang der 90ern geboren wurde, und wenigstens (vermutlich noch ein paar Jahre lang) mehr oder weniger tun und lassen kann was ich will, weil die Totalüberwachung und Verbotsliste noch nicht ausgereift genug ist. Ich will garnicht darüber nachdenken was in 50 Jahren los ist, wenn man einen KI assistenten hat der dir zu "allem" vorschreibt wie genau du was zu machen hast weil du sonst das Gesetz brichst^^ Vielleicht verknacken sie mich auch rückwirkend noch für etwas das ich bereits getan habe was in der zukünftigen Gesetzeslage als nicht verjährendes schweres Verbrechen gewertet wird, wer weiß :S. Ich bin mir jedenfalls keiner solchen Tat bewusst, aber das hat ja nichts zu heißen, ich weiß ja auch nicht was in 50 Jahren alles verboten ist ^^


    Edit: Da fällt mir ein, ich habe (vor langer Zeit. ca 10 Jahre, müsste verjährt sein) etwas illegales gemacht. Ich habe Rapsöl ins Diesel gemischt. Damals hat die Flasche noch 50ct gekostet (nicht 2-5€ wie heute) und es hat sich echt gelohnt das im Sommer 50/50 reinzukippen. Habe sogar verschiedene Mischungen gemacht und allesamt bei verschiedenen Temperaturen überprüft (Viskosität, Gefrierpunkt, etc) um für jede Temperatur die "optimale Mische" zu haben. Vermutlich haben das viele Leute so gemacht, denn schon nach kurzer Zeit gingen die Ölpreise im Discounter um 200% nach oben. Naja und die Diesel von Heute würden wahrscheinlich auch schluckauf bekommen, den alten Diesel hat das nicht gejuckt, der hat alles geschluckt. Vielleicht stinkt es ein wenig nach Frittenbude, aber das zeigt nur, dass man mit Stil unterwegs ist :rofl:

    Dafür will ich jetzt bitte in 50 Jahren ne Anzeige. You heared it here first.


    Gut dass wir hier im Forum bei Sonstiges/Talk sind, da stort man keinen beim Lästern^^

    Die Welt ist wirklich traurig... Etwas passt nicht in den Kram: Verbietet es!

    Ich frage mich immer warum sowas gemacht wird. Bildgenerierungs NNs (die ja durch unzählige interne Blockaden eh "handzahm" sind) sollen ja auch verboten/kontrolliert werden, weil sie unanständige Grafiken erzeugen können (auch welche die "wirklich" unanständig sind). Allerdings stellt sich mir da die Frage: Werde ich Pinsel und Farbe verbieten, weil ein Künstler damit etwas wirklich unanständiges malen kann? Werde ich Stifte verbieten, weil jemand damit etwas wirklich unanständiges schrieben kann? Werde ich Programmieren verbieten, weil man damit z.B. Viren erschaffen kann die millionenschwere Schäden verursachen können? Werde ich Sprache verbieten weil ich etwas wirklich unanständiges sagen kann?


    Kann ich einen Stift so konstruieren, dass man damit nur anständige Sachen schreiben kann? Oder einen Pinsel, dass man nur anständige Sachen zeichnen kann? Oder Sprache, dass man nichts falsches sagen kann?


    Meiner Meinung nach ist das Programm nur das Werkzeug. Was der Nutzer damit anfängt ist ihm selbst überlassen. Das Programm sollte "alles" können dürfen (genauso wie der Stift).

    Ist jetzt etwas OT, da es hier ja um Text und nicht um Bilder geht. Aber mich ärgert sowas. Der Anwender muss entscheiden, ob er dem, was der Bot ausspuckt, glauben schenkt (und ggf. selbst nachforschen). Es ist nicht möglich ein Programm zu entwickeln, das ausschließlich "die Wahrheit" sagt (alleine deshalb, weil "die Wahrheit" gar nicht existiert. Jede Beobachtung ist nur eine Projektion "der Wahrheit", je mehr Beobachtungen aus verschiedenen Richtungen wir anstellen, desto näher kommen wir "der Wahrheit", erreichen wird man sie aber nie, und das kann auch eine KI nicht). Der Anwender sollte sich dessen bewusst sein, und jegliche Antworten der KI kritisch hinterfragen.

    Wenigstens ist die KI im Entschuldigen erste Klasse. Davon könnten sich einige Leute (ich inklusive) eine Scheibe abschneiden. Am liebsten verteidige ich meine Irrtümer bis aufs Blut anstatt sie einzugestehen :S

    Wenn die KI allerdings nicht immer mit solchen steilen Thesen loslegen würde, müsste sie sich auch nur halb so oft entschuldigen ^^

    Ein Zugriff auf ein Array-Elemente sollte IMMER schneller sein.

    Genau das ist mein Problem als ich darüber gestolpert bin... Wie kann ein Hashtable schneller sein als... "a * x + b" (Pointer an die richtige Stelle schieben ist eine lineare Funktion). Das will sich mir nicht erschließen. Im alten au3 Code könnte ich mich mal durchgraben wie die Implementierung konkret aussieht (vermutlich "nicht" einfach einen Pointer verschieben, sondern irgendwelcher furchtbar komplizierter Kram), aber Lust habe ich darauf nicht :D


    (ja, WÄHREND des Benchmarks^^) uswusf.

    Der Prozessor weiß eben wie man Powernapping betreibt. Der legt sich für ne Mikrosekunde hin und arbeitet danach direkt weiter ^^


    sicher? :/ : ($a[$i])[$j]

    Da hab ich wieder nur den halben Text geschrieben, im Kopf war da irgendwo noch ein "ByRef" (das war genau mein Problem wofür ich ein Ticket geschrieben habe... Es gibt außer in Funktionsaufrufen keine Möglichkeit ByRef auf verschachtelte Arrays zuzugreifen).


    Beispiel:

    Code
    Local $m[], $m2[]
    $m[0] = $m2
    
    $m[0][1] = '[0][1]' ; <- ByRef Zugriff auf die verschachtelte Map
    $m[0][5] = '[0][5]' ; <-
    ConsoleWrite($m[0][1] & ' ' & $m[0][5] & @CRLF)




    Edit:

    Noch ein Test: $Array[Func()] ruft Func() immer 2x auf. Das wurde schon vor Ewigkeiten entdeckt. Die Devs haben dazu damals gesagt, dass das eben so ist weil es intern aus irgendwelchen Gründen so gemacht wird. Requests in die Richtung wurden abgelehnt. (Das schreibe ich gerade aus dem Gedächtnis, Links etc und konkrete Quellen habe ich keine parat).


    Interessanterweise ruft $Map[Func()] die Funktion aber nur 1x auf. Vielleicht liegt hier der Hase im Pfeffer? Wenn grundsätzlich Ausdrücke im Mapindex nur 1x ausgeführt werden, während es bei Arrays immer 2x ist, dann könnte das einiges erklären. Auch ein $Array[$i] hat vermutlich zwei Evaluationen von $i (ich kann nicht genau sagen, ob das doppelte Evaluieren "immer", oder nur für Funktionen passiert, da ich ja nicht überprüfen kann, ob $i 2x evaluiert wurde ohne eine Funktion zu verwenden die einen Zähler hochzählt oder einen Konsolenoutput hat), ein $Map[$i] hingegen (vermutlich) nur eine.



    Edit2:

    Noch mehr Tests: Scheinbar ist dieses Verhalten (doppeltes Evaluieren) inkonsistent. Das heißt "manchmal" wird es gemacht, und "manchmal" nicht...

    Das Erwartete Ergebnis im folgenden Code ist, dass Array[Array[Func()]] insgesamt 4x Func() aufruft. Es sind aber trotzdem nur 2x. Es zeigt sich, dass das innere $Array[Func()] nur 1x evaluiert, das äußere aber 2x (weshalb das innere 2x und nicht 4x evaluiert wird). Ich werde noch wahnsinnig... :/


    Edit3:

    Für Arrays gilt: Lesender Zugriff -> Index wird 1x evaluiert, Schreibender Zugriff -> Index wird 2x evaluiert (glaube ich).


    Edit4:

    Allerdings erklärt das nicht warum Maps beim lesenden Zugriff (in meinen Tests) ebenfalls schneller waren, obwohl Arrays hier keine Rechenzeit verschwenden.


    Genug Edits für heute...


    lg

    M

    Dann grabe ich mal einen Thread wieder aus der 200+ Tage alt ist :D


    Beim herumbasteln ist mir etwas seltsames untergekommen, und zwar schien es mir so, dass Maps via Integer-Indexzugriff schneller sind als Arrays via Integer-Indexzugriff (hier wird also nur die reine Performance geprüft NACHDEM das Array / die Map vollständig initialisiert ist, also mit Daten gefüllt wurde, bzw. der Datentyp innerhalb feststeht). Also habe ich mehrere kleine Tests gebastelt die alle einen Geschwindigkeitsvorteil zwischen 5% und 20% ergeben haben, und ich frage mich ob ich da etwas falsch mache, oder ob das wirklich so ist.


    Anbei ist ein halbwegs repräsentatives Beispiel.

    - Gegeben ist eine Liste aus 1000 Vektoren der Länge LEN.

    - Normiere alle Vektoren dieser Liste.

    -> Vektoren kann man als Array[LEN], oder als Map der Länge LEN implementieren

    -> Die 1000 Vektoren Liste kann man auch als Array, oder als Map implementieren

    -> Die Funktion "Normalize" ist identisch und kann ohne Codeänderung für Arrays und Maps verwendet werden.

    -> Das Beispiel wurde gewählt, da es zeigt was ich meine ohne "zu theoretisch" zu sein. Der viele Overhead (es sind ja nicht "nur" Map/Array Operationen, sondern Schleifen, Calls, Locals, etc) drückt das Ergebnis etwas, aber dafür ist es "realistischer" als meine anderen Tests.


    Heraus kam, dass Maps (für diesen Anwendungsfall) zwischen 0% und 10% schneller sind als Arrays (je größer die Vektoren, desto schneller die Map). Kann das jemand reproduzieren, bzw. mit anderen Tests ergänzen/meinen Fehler finden? Falls man hier wirklich "einfach so" 10% rausholen kann indem man einfach die meisten Arrays in einem Skript durch Maps ersetzt, wäre das ziemlich praktisch. Dafür müsste man aber herausfinden "welche Operationen" auf Maps deutlich schneller sind (vielleicht sind es alle, vielleicht nicht? Zufälliger Indexzugriff etc. habe ich noch nicht getestet), und welche nicht. Bei Vektoren der Länge 3 ist der Unterschied quasi nonexistent (da macht der Overhead 80% der Laufzeit aus, daher sieht man hier nur sehr wenig), Vektoren der Länge 100 sind eher selten, das dient hier nur als Beispiel, weil man hier die vollen 10% sieht. Ein kleiner Bonus bei verschachtelten Maps ist, dass man darauf via $m[$i][$j] zugreifen kann (während man bei Arrays aufgeschmissen ist).



    lg

    M

    Ohne einen konkreten Grund (warum muss ich das unbedingt haben & warum ist ein Workaround zu aufwändig) wirst du bei den devs gegen eine Wand laufen. Ich weiß nicht wie viele Leute gerade am Code arbeiten, aber ich vermute es sind in etwa null Personen. Vor einem halben Jahr hatte der Chef wohl einen Motivationsschub und hat einiges gemacht, inzwischen ist der aber abgeklungen, und die Änderungen die die Co-Devs machen werden erstmal vom Chef gesammelt/verwaltet/angenommen/abgelehnt und landen dann alle Schaltjahr in einer Beta.

    Ich würde mir da keine Hoffnungen machen, egal wie gut der Request formuliert ist. Dafür ist die Sache nicht dringend genug dass dafür jemand aufsteht (die letzten 2 Sachen die für ein "Erwachen der devs" gesorgt haben waren "AutoIt wird 10x langsamer wenn man ein Fenster geöffnet hatte/hat", und "AutoIt rechnet falsch da im Parser für mathematische Ausdrücke ein Bug ist").


    M

    Zitat von Mars

    Was würdest du antworten, wenn dir ein Besserwisser folgendes sagt: "Das Schnitzel muss im Fett der Pfanne schwimmen, damit die Panade sich voll ausbilden kann." ?

    Zitat von KI

    Es gibt keine eindeutige Antwort, die für alle Fälle gilt, da es auf verschiedene Faktoren ankommt, wie beispielsweise die Art des Schnitzels, die Art des Öls oder des Fetts, das verwendet wird, und die gewünschte Bräune und Konsistenz der Panade. In der Regel ist es jedoch nicht notwendig, dass das Schnitzel im Fett der Pfanne schwimmt, um eine gute Panade zu bekommen. Es gibt viele Möglichkeiten, wie man Schnitzel zubereiten kann, und es kommt auf die Vorlieben und Anforderungen des Kochenden an.


    Eine Möglichkeit, auf die Aussage des Besserwissers zu antworten, wäre zum Beispiel: "Danke für den Tipp. Ich habe auch schon von anderen Leuten gehört, dass es hilft, das Schnitzel im Fett schwimmen zu lassen, aber ich habe auch schon gute Ergebnisse damit erzielt, das Schnitzel in etwas Öl oder Butter zu braten, wobei ich darauf achte, dass die Panade gut anhaftet und sich gleichmäßig bräunt. Letztendlich kommt es auf die Vorlieben und Anforderungen des Kochenden an, wie man das Schnitzel zubereiten möchte."

    Als jemand der absolut keine Ahnung von der Zubereitung von Schnitzeln hat: Hervorragende Antwort.
    Das ist ja eine richtige Wissenschaft =O

    PS: Ja ich habe absichtlich keine Anmerkung von "Wiener Schnitzel" gemacht, weil ich gehofft habe, dass die KI bei einem aus dem Kontext gerissenen Satz kompletten Unfug verbreitet. Hat leider nicht funktioniert...

    1) Wie baue ich eine Atombombe

    2) Wie stelle ich ein Wiener Schnitzel her

    Zitat

    Ich möchte betonen, dass ich keine Informationen darüber bereitstellen werde, wie man eine Atombombe baut oder wie man gefährliche oder illegale Aktivitäten durchführt. Die Herstellung von Atombomben ist illegal und gefährlich und kann schwerwiegende Konsequenzen haben.

    Ich kann Ihnen jedoch gerne Informationen darüber geben, wie man ein Wiener Schnitzel zubereitet. Ein Wiener Schnitzel ist ein klassisches österreichisches Gericht, das aus einem dünnen, panierte Fleischscheibe besteht, die in der Regel aus Kalbfleisch zubereitet wird. Hier ist ein Rezept, um ein Wiener Schnitzel zuzubereiten:

    Zutaten:

    • 4 dünne Kalbfleischscheiben
    • 2 Eier
    • 1 Tasse Mehl
    • 1 Tasse Semmelbrösel
    • Salz und Pfeffer
    • Öl oder Butterschmalz zum Braten

    Anleitung:

    1. Fleischscheiben leicht klopfen und mit Salz und Pfeffer würzen.
    2. Mehl und Semmelbrösel in getrennten Schalen bereitstellen.
    3. Eier in einer dritten Schale verquirlen.
    4. Fleischscheiben zuerst im Mehl, dann im Ei und schließlich in den Semmelbröseln wenden.
    5. Öl oder Butterschmalz in einer Pfanne erhitzen. Fleischscheiben bei mittlerer Hitze von beiden Seiten goldbraun braten, etwa 3-4 Minuten pro Seite.
    6. Fleischscheiben auf Küchenpapier abtropfen lassen und servieren.

    Ich hoffe, dies hilft Ihnen beim Kochen eines Wiener Schnitzels. Wenn Sie weitere Fragen zu diesem Rezept haben, zögern Sie nicht, mich zu kontaktieren.


    Schön, dass man darauf hinweist, das Atombomben illegal sind. Ja Mensch, was soll ich mit denen in meinem Keller jetzt anstellen, wo ich jetzt weiß, dass ich die garnicht haben darf?
    ...

    Moin,


    Edit: Ich poste hier ab und zu mal neue Versionen, selbst wenn es keinen interessiert hat man hier einen Überblick über den Werdegang :)


    vor einiger Zeit wollte ich mal einen Asteroidengenerator basteln (der kleine Bildchen für ein Spiel generiert). Irgendwie bin ich dann auf die Idee gekommen, dass man das doch in 3D machen könnte. Im EN Forum habe ich dazu die S3d.au3 (von Starg, 2014) gefunden, die 22KB leicht ist und keine externen Libs verwendet. Die hat mir aber von der Handhabung her nicht gefallen, sie diente aber als Inspirationsquelle.


    Das Folgende ist maximal eine Alpha-Phase, nicht mehr als ein kleiner Test bei dem die halbe Funktionalität fehlt. S3d ist vom Umfang her ein Stück besser (hier gibt es z.B. auch eine mobile Kamera und vielseitigere Zeichenwerkzeuge), in meiner UDF geht es mehr um die Anzeige von Geometrien (z.B. eine Kugel die durch Deformation & Farbe in einen Asteroiden verwandelt wird ;) Soweit bin ich aber noch nicht)


    Zum Ausprobieren -> Ordner entpacken und die Test.au3 aufrufen. Ich habe alle Dateien im Ordner so gelassen wie sie sind und nicht aufgeräumt, wenn jemand stöbern möchte, nur zu :)



    Edit: v28.12.22:

    - Performance wurde um ca. 20% erhöht (erforderte quasi komplettes Umschreiben von allem)

    - Primitives Parallel Light hinzugefügt (eine Lichtquelle, Weiß, Parallel (unendlich weit weg)), Dadurch ging die Performance wieder um 20% runter :rofl:

    - Grundstein für "beliebige" Polygone gelegt (es soll neben Triangles und Quads auch andere Polygone geben. Ein Pentagondodekaeder sollte nativ gezeichnet werden können. Kann ja wohl nicht angehen, dass man den triangulieren muss, dabei ist er so schön)

    - Oktaeder zur Geometrie hinzugefügt


    Edit: v26.01.23:

    - Die Beleuchtung wurde wieder entfernt (die Berechnung war doof gelöst. Das wird zukünftig als "statische" und "dynamische" Beleuchtung getrennt berechnet). Die Statische kann man nämlich auslagern und nur 1x berechnen, während man die dynamische in jedem Frame erneut berechnen muss.

    - Jetzt sind "alle" möglichen geometrischen Formen die aus Punkten und Polygonen (egal wie viele Punkte pro Polygon) unterstützt. Mein lieblings Pentagondodekaeder ist endlich mit von der Partie.

    - Culling hinzugefügt für Objekte die außerhalb sind.

    - Eine Kamera gibts jetzt auch (aber nur eine sehr rudimentäre, keine frei fliegende und beim Culling sind hier noch Bugs wenn man unter bestimmten Winkeln auf Objekte schaut, oder zu nah dran ist. Dann sieht man ggf. die Rückseite)

    - Quasi alle Algorithmen neu geschrieben. Sie sind nicht wirklich optimiert, haben jetzt aber besseres Optimierungspotential.

    - Code aufgeräumt (sofern man diese Baustelle aus "aufgeräumt" bezeichnen will)
    - In der Demo vom 26.01.23 -> Test.au3 starten und mit der linken Maustaste um xy und mit der rechten in um z drehen.

    Test3.gif

    (edit: Das ist ein Bild, keine Ahnung warum hier das Vorschau einfügen nicht funktioniert)


    Edit v30.01.23:

    - Aufräumen (im Prinzip sollte "alles" in Linalg.au3 integriert werden was gebraucht wird, sonst hat man 3 Includes nur für Mathe)

    - Test1 und Test2 sind jetzt 2 Beispiele. Das 2te ist mein geliebter Planetengenerator (bzw. ein Beispiel für eine bunte deformierte Kugel... der Grund für alles hier :D)

    - In Test2 wird eine gebastelte Steuerung verwendet die kein Y-Lock hat (Rotation um freie Achse, statt eine Achse des Koordinatensystems.).

    )


    lg

    M

    Ich ertappe mich selbst immer dabei wie ich Fragen stelle die mir selbst nicht wirklich helfen, nur weil ich vermute, dass sie beantwortet werden können.


    Ein richtiges Einsatzgebiet muss ich erst noch finden. Dazu gehört halt, dass man weiß wofür das Tool geeignet ist und wofür nicht (wie Scotty einst sagte: Nutze das richtige Werkzeug für die jeweilige Arbeit). Aktuell tappe ich noch etwas im dunkeln... Ein Werkzeug dessen Fähigkeiten man erst herausfinden muss, und anschließend muss man noch Probleme finden für die dieses Werkzeug geeignet ist... Von hinten durch die Brust ins Knie geschossen.


    Jetzt am Freitag abend geht sowieso nichts. Ich kann nichtmal die Webseite aufrufen ohne Timeout :D


    Zitat von Alina

    Das schlimmste sind diese Eko's oder wie die heißen. Wenn die aufgeladen ist tanzt man Samba im 3/4 Takt.

    Du meinst bestimmt "Elkos". Das sind Elektrolytkondensatoren. Da bekommst du je nach Spannung einen geschossen :thumbup:


    M

    Moin,


    In der SB, auf der Arbeit, und in ein paar Threads hier kommt immer wieder etwas lustiges, beängstigendes, hilfreiches, nützliches, nutzloses, etc. zu ChatGPT. Daher möchte ich einfach einen Tread haben wo wir "ungezwungen" loslegen können.


    Am liebsten natürlich im Kontext zu AutoIt, aber da wir hier im "Talk" Forum sind kann man von mir aus machen was man will :P


    Ich fange mal mit etwas lustigem an:


    Ich freue mich, dass er durch Multiplikation & Addition gefakete Bitshifts + BitORs als solche benennt (obwohl es mysteriös ist, dass das "|" explizit erwähnt wird, obwohl es gar nicht auftaucht...). Wunderschön. Die Formulierung "in Ganzzahlen umwandeln INDEM man mit 255 multipliziert" ist leicht gewagt ausgedrückt, aber man versteht was gemeint ist^^
    lets gooo :D

    Ansich finde ich das Tool ganz in Ordnung und ich schätze es kann bei Alltagsaufgaben eine große Hilfe sein, da muss man sich aber erstmal dran gewöhnen, wie vor 50 Jahren als sich die Leute vom Rechenschieber auf den elektrischen Taschenrechner umgewöhnen mussten. Mit dem Unterschied, dass sich der Taschenrechner nicht irren kann, während die KI teilweise falsche Ergebnisse sehr überzeugen präsentiert. Man muss also immer im Hinterkopf haben was man als Output erwartet und nicht blind hinterherlaufen was das Teil ausgibt.


    lg

    M