Beiträge von UEZ

  • VU-Meter auch für FMOD.dll?

    Zitat von Cape-City

    Bringt das denn
    nachher etwas beim Compilieren oder ist die EXE deswegen auch nicht viel kleiner, wenn der UPX drüber gelaufen ist?

    Da der Code intern die Daten als Strings speichert, bläht sich natürlich der Code auf. Ideal wäre es, wenn man die Exe so klein wie möglich halten will, die Dateien als Ressourcen in die Exe anhängt. Um zu testen, müsste man aber den Code immer kompilieren.

    Wie schon alpines schrieb, reagieren die AV Programme sehr sensible gegen UPX gepackte AutoIt Executables. Die Exe wird zwar kleiner, aber die AV Programme werden dadurch eher nur angetriggert.

    Mir persönlich ist mittlerweile die Exe Größe egal.

  • VU-Meter auch für FMOD.dll?

    Zitat von Cape-City

    Den Part "_FSOUND_GetCurrentLevels@12" in der DLL hatte ich auch bereits im Internet gefunden, wusste aber nicht, wie ich das entsprechend aufrufen muss.

    Mal das Help File zu FMOD im Anhang.

    Und hier die Funktionen:

    Happy Intro Coding. :D

  • VU-Meter auch für FMOD.dll?

    Hier ein kleine Erweiterung der FMOD Memory UDF:

    AutoIt
    Func FSOUND_GetCurrentLevels($F_Channel = 2)
	Local $tLeft = DllStructCreate("float l"), $tRight = DllStructCreate("float r")
	Local $F_RetValue = MemoryDllCall($F_DLL, "int", "_FSOUND_GetCurrentLevels@12", _
				              "int", $F_Channel, _
				              "struct*", $tLeft, _
				              "struct*", $tRight)
	If Not $F_RetValue[0] Then Return SetError(1, 0, 0)
	Local $F_LEVELS[2] = [$tLeft.l, $tRight.r]
	Return $F_LEVELS
EndFunc

    Kleiner Flimmer Beispiel als Anhang.


    Ich sehe, dass du auch "Demo / Intro" begeistert bist. :thumbup:

  • Fertiges AutoIT Skript funktioniert nur richtig, wenn AUTOIT installiert ist!

    AutoIt
    Dim $var2 = RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\UNINSTALL\"&$var, "DisplayName")
	ConsoleWrite($var2&@CRLF)
	If @error then ExitLoop

    @error bezieht sich in diesem Fall auf ConsoleWrite und nicht auf RegRead, sprich die For/Next Schleife läuft zwangsmäßig bis 999, da ConsoleWrite nie einen Fehler zurück gibt.

    Ansonsten kann ich beim Überfliegen nichts weiter erkennen.

  • Assemblercode - Noch optimierbar?

    Test System (CPU): Intel(R) Core(TM) i5-4300U @2,5 GHz

    Mars:

    Code
    Benötigte Zeit [ms]:  86
                 PI:  3.1415925535897933


    Andy:

    Code
    : $pi Leibnitz = 3.14159255358581
: Time [ms] = 28.442786194246


    UEZ:

    Code
    1) VS2015_C++_Leibniz-PI_x64
Pi: 3.1415925535897915  53.861474000000001 ms for 10000000 iterations.
2) VS2015_C++_Leibniz-PI_x86
Pi: 3.1415925535897915  54.446914999999997 ms for 10000000 iterations.
3) FB_Leibniz-PI_x86
PI: 3.141592553589792       127.8968800324947 ms for 10000000 iterations.

  • Assemblercode - Noch optimierbar?

    Zitat von Mars

    Einen Grund kann ich dir sagen: das pow(-1, k) frisst. Selbst wenn das intern effektiv gehandelt wird hast du damit mehr Rechenaufwand als wenn du eine Vorzeichenvariable einführst.

    Stimmt! =O
    Bezgl. FB: hätte nicht gedacht, dass die Laufzeit von 1136ms auf 136ms sinkt, wenn ich das so mache wie du es gemacht hast.


    Edit: mit VS2015 habe ich 56ms hinbekommen.

  • Assemblercode - Noch optimierbar?

    Komisch, dass ich mit FB so bescheiden abschneide.

    Mit VS2015 bekomme ich immerhin 328ms.

    Ich habe absolut keinen Plan, wie ich den C++ Code optimieren kann geschweige denn, wie ich VS optimal einstellen kann.

    Hier der C++ Code:


    Keine Ahnung, wie ich die Zeit als x64 messen kann...

    Wenn interesse besteht, kann ich die kompilierte EXE hochladen.


    @Andy: auf meinem Schleppi -> Intel i5 @2,5 GHz

    Code
    : $pi Leibnitz = 3.14159255358979
: Time [ms] = 71.4103606789976

  • Assemblercode - Noch optimierbar?

    Mit FreeBasic komme ich auf 1136.025325860828 ms für 10.000.000 Iterationen -> Intel i5-4300U @ 2594 MHz

    Der generierte Assembler Code:


    FB Code:

  • Neulich in der Kneipe..."Compiler sind die besseren Programmierer"?!

    Meine Meinung ist, dass ein Compiler nur so gut ist, wie sein Programmierer und somit schließt sich der Kreis wieder.

    Wenn ich ein Programm schreibe und die Exe "schnell" genug arbeitet, dann hat der Compiler seine Arbeit ordentlich erledigt. Für die meisten Fälle trifft das auch zu.
    Begibt man sich z.B. in die "brotlose Kunst" (grafische Datenverarbeitung), so ist noch potential vorhanden den Code mit eigenen Assembler Routinen zu optimieren. Das habe ich gemerkt, wie ich in FreeBasic einiges gebastelt und einige Funktionen direkt in Inline ASM hinzugefügt habe -> mit relativ wenig Aufwand einiges an Performance herausgeholt.

    Ich weiß nicht, ob man den optimalen Compiler bauen kann, der je nach Anwendung den effizientesten Code produziert, aber wird auch nur für spezielle Anwendungen eher nötig sein. Ich kenne mich kaum in Compilerbau aus...

    Abgesehen davon gilt noch das Mooresche Gesetz und warum soll man da noch den Code optimieren denkt sich der eine oder andere Coder!?!

    Wenn ich z.B. mit einer Interpreter Sprache wie AutoIt Applikationen schreiben, die relativ "schnell" arbeiten, dann benötige ich nicht zwingend einen hoch optimierten Code, der einige Millisekunden schneller arbeitet.