Beiträge von Ealendil

    Mag vielleicht ünnotig sein, aber ich hab ewig und drei Tage gebraucht um zu verstehen was eine for-each Schleife ist. (oder for-in)



    Local $array[5] = [1, 2, 3, 4, 5]
    For $item In $array
    Msgbox(0, "", "$item: " & $item)
    Next


    Ich finds um einiges einfacher damit alle Array-Elemente zu durchlaufen, anstatt immer die typische For-Schleifen (mit Indexvariable) zu verwenden.

    Anstelle von:


    GUICtrlSetData ($h_List3, $a_Inhalt[$i][1])


    Einfach:


    GUICtrlSetData ($h_List3, $a_Inhalt[$i][0])


    Sollte dein Problem lösen.




    Zudem kanst du die


    GUICtrlSetData ($h_List2, "")
    GUICtrlSetData ($h_List3, "")


    weglassen, da du die Daten mit dem jeweils nächsten "GUICtrlSetData()" sowieso neu setzt.

    Zitat

    Und btw wie soll ein server bei so wenig berechnung überlastet werden?


    Ein Fehler im Programm, geschieht jedem irgendwann mal.
    Zuviele Spieler, irgendwas nicht eingeplantes.


    Nur weil es anfangs nicht vorhersehbar ist, heißt es nicht, dass es nicht geschieht.
    Der Programmierer trägt nun mal die Verantwortung, dass selbst unter miesesten Bedingungen kein Fehler auftritt.


    Zitat

    Glaub mir ich bin kein Anfänger.


    Hab ich nie behauptet oder gedacht.
    Ich habe dich lediglich auf einen, mMn., Fehler aufmerksam gemacht.

    Ohne dich ärgern zu wollen, auch wenn es danach ausschaut.


    Selbst wenn es der Server regelt, muss die Bewegung korrekt berechnet werden.
    Was wäre wenn der Server gerade überlastet ist und dasselbe Problem, siehe oberen Post von mir, auftritt.

    Sry, hab mich falsch ausgedrückt.
    Mit "ruckeln" meinte ich nicht geringe Framerate, da kann man nichts ändern.
    Ich meinte, dass sich deine Objekte, im Beispiel "Link", viel zu langsam bewegen würden, da du eine "pro Frame Bewegung" implementiert hast.

    Gute Idee.
    Mir gefällt vorallem, wie du das Framerate Problem gelöst hast.


    Als Verbesserung:
    1) Ich würde dir empfehlen den Code zu kommentieren, da es schnell mal unübersichtlich werden kann.
    2) Was machst du wenn du einen PC hast, der ungewöhnlich lange für das Rendern braucht, also länger als die angegebenen FPS?
    Dann würde deine If Abfrage in _Garfik_Update() nicht mehr anschlagen und die Anwendung würde erst recht wieder ruckeln.
    3) Empfehle ich dir den Zeiger auf die DllStuct in $hGarfik[8] bereits vorzuspeichern, damit du nicht in jedem Update-Aufruf DllStructGetPtr() benötigst.

    name22: Ich meinte die Parameter und möglichen Rückgabewerte von ZwDelayExecution.
    Das eine Funktion, welche "warten" im Namen trägt etwas dergleichen macht, dachte ich mir. ;)
    Trotzdem danke für deine Erklärung.


    @Skincke: Weiß nicht ob du meinst, dass du es durch mich eingebaut hast oder nicht.
    Falls ja, Freut mich, wenn ich helfen konnte.
    Falls nein, sei gewiss ich habs dir nicht gestohlen.


    Hab mir dein Update gerade angeschaut und gleich nen Post in deinem Thread geschrieben.

    name22:
    1)Danke für dein Feedback.
    Kurz ist es, aber mMn. benötigt es nicht mehr.


    2)Versteh meine Frage nicht falsch.
    Inwiefern meinst du ausgefeilter?


    Kannte ZwDelayExecution() nur vom "HörenSagen", habe allerdings noch keine genaue Beschreibung zu dieser Funktion gefunden.
    Kennst du/jemand eine Detaillierte?

    Der enum-Typ wäre nur der Übersicht halber gedacht, so dass man die Zahlen nicht auswendig lernen muss sondern einfach nur der Text (Konstantenname).


    Zitat

    ... in OpenGL wird eh jeder Typ als 32 Bit portiert, da OpenGL auf einer 32-Bit Lib beruht


    Wie meinst du das?
    Wenn du unsigned char return'st ist die Größe des Rückgabewerts 1 Byte groß oder irre mich?


    Da AutoIt den return-Typ "enum" nicht kennt, wie sollte es auch, wäre es wichtig die enum-Größe konstant zu halten (32 Bit als Beispiel).


    DllProgrammierung/Exportierung ist recht einfach:


    In deinem Header:


    In deiner .cpp-Datei:



    Wichtig ist, dass du Funktionen, die als extern "C" deklariert sind, nicht überladen kannst.


    EDIT:
    Ebenso kann es sein, dass manche Compiler trotz extern "C" die Exportfunktionsnamen ein wenig umbennen.
    Aus "MyDllExport" kann also "MyDllExport@4" werden.
    Um trotzdem an die richtigen Namen zu kommen, empfehle ich dir ein Programm, wie DllExplorer, welches dir alle Funtionen einer Dll aufzeigt.

    Hi,


    Vorwort:
    Da mittlerweile die GDI+ Projekte/Programme immer zahlreicher werden,
    sowie mich die Lust gepackt hat dieses Wissen zu teilen, in der Hoffnung
    auf weiterhin gute Skripte.


    Ebenfalls zu notieren:
    Ich habe dieses Thema, bzw. Technik einfach nur so getauft.
    Sie wird weltweit als Render Basis für jedwege Engine verwendet (es gibt auch andere Arten, aber dies ist die Geläufigste).



    Hauptteil:
    Programmiert man ein simples 2D Spiel, in welchem sich einfach nur eine Figur/Sprite
    bewegt.
    So würde man sporadisch gesehen folgenden AutoIt-Code schreiben:



    Obiger Code ist zwar nicht falsch, was mache man allerdings, wenn das Skript nur als decompile-resistente .exe
    vorliegt, sprich der Code nicht mehr veränderbar ist, der Sleep()-Wert konstant ist.


    Wozu Sorgen machen?
    Nun schreibt man ein Programm für einen PC mit 2.0 GHz und alles klappt, stellt sich diese Frage nicht.
    Sollte das Programm allerdings nun auf einen überschnellen PC mit 300.0 GHz ausgeführt werden,
    so wird der Render_Game()-Code entsprechend schneller ausgeführt.
    Aus "lächerlichen" 20 FPS können rasch 200 FPS werden.
    Dies bedeutet nun, dass sich die Spielfigur pro Frame um 5 Pixel bewegt, der Code 10x so oft aufgerufen
    wird. D.h. der Charakter bewegt sich nun statt 100 Pixel (=5*20) um 1000 Pixel (=5*20*10) pro Sekunde.
    Ein Fehler welcher nicht auftreten soll und darf.


    Wie umgehe ich dies?
    In dem man einen Timer in die Schleife einbaut und nach jedem Render() Aufruf prüfe wieviel Sekunden!!!
    vergangen sind.
    Diesen Wert übergibt man dann dem nächsten Render() Aufruf.



    Obiger Code führt dazu, dass die Spielfigur im 1. Frame um 0 Pixel bewegt wird und ab dem 2. Frame um
    $g_fStepCount - Pixel pro Sekunde bewegt wird.
    Wie nun der Teil mit dem Sleep() gelöst wird bleibt jedem selbst überlassen.



    Und nun das Ganze mal mit einem Beispiel:



    Nachwort:
    Diese Technik soll helfen, dass Skripte auf jedem PC gleich "flüssig" laufen,
    also jede Figur sich gleich weit pro Tastendruck oder ähnliches bewegt.


    Ich hoffe ich habe es verständlich erklärt.
    Sollten Fragen auftreten, scheut euch nicht diese zu stellen.



    LG,
    Dennis a.k.a Ealendil


    EDIT: Beispiel hinzugefügt!

    Hi,


    gute Idee.



    Als Verbesserungsvorschlag, bzw. Änderung würde ich dir empfehlen statt int einen
    selbst definierten Typ a la "enum GLEASY2D_RESULT" oder dergleichen zu return'en.


    Wichtig: Falls du vorhast glEasy2D nach AutoIt zu portieren, also per "DllCall()",
    solltest du in die enum einen ungenutzten Wert, z.b. "__GLEASY2D_RESULT__FORCE__DWORD__ = 0x7fffffff" einsetzen.
    Dies führt dazu, dass der Compiler den enum-Typ als 32-Bit Größe kompiliert wird.

    Hi,
    ohne mich sonderlich gut mit Physik-Engines auszukennen stell ich trotzdem mal ein paar (Gegen)Fragen, vlt. helfen sie dir, bzw. jmd. der sich auskennt.


    Inwiefern kommst du nicht weiter, was hast du schon alles?


    Hast du Kollisionserkennung eingebaut, wenn ja, auf welcher Basis (also Kugel-Kugel-Kollision oder Linie-Dreieck-Kollision, etc.)?
    Hat zwar nichts mit Physik am Hut, würde deine Engine allerdings interessanter machen, vorallem wenn sie 2D und 3D unterstützen würde.


    Hoffe dir ein paar Anregungen gegeben zu haben.

    Änder die Funktion folgendermaßen:


    Code
    char* DLLversion(void) {
         string sDLLversion = "0.0.0.1";
         return sDLLversion.c_str();
    }


    Und in AutoIt:


    $return = DllCall ( "Project1.dll", "str", "DLLversion")
    If @error Then
    MsgBox(0,"","Fehlercode : "&@error)
    Else
    MsgBox(0,"",$return[0])
    EndIf


    Du willst ja nur die Zeichenkette an AutoIt zurückgeben, nicht das String-Objekt oder?
    Das Problem bei der Sache ist, allerdings, dass das String-Objekt nach der Funktion wieder zerstört wird
    und somit der C-String(char*) ins Leere zeigt, sprich du müsstest mit "new" oder "malloc" Speicher reservieren,
    und diesen entweder durch einen Ressourcen-Manager, durch eine Funktion oder irgendwie anders wieder freigeben.


    EDIT: Quellcode ausgebessert.

    Bin mit meinem Latein leider am Ende.
    Das Sleep(INFINITE) war einfach nur ein Versuch, allerdings, laut MSDN sollte dieses entfernt, sprich von meiner Seite nicht mitgedacht.


    Das Sleep(10) habe ich deswegen entfernt, da nach einer Fenstererstellung relativ gleich danach die WM_CREATE-Nachricht behandelt werden sollte,
    wobei auch hier, nur ein Versuch, und da mMn, deswegen nicht der Prozessor zum Glühen anfangen sollte.


    Weiterer Versuch wäre, aus PeekMessage ein GetMessage zu machen, bei mir hat es so funktioniert.

    Hi,
    sry, dass ich mich erst jetzt wieder melde.


    Mach aus der Funktion:


    Diese hier:


    Solllte dann funktionieren.

    Okay, danke dir.
    Das Problem liegt daran, dass GetMessage() die Nachrichten aus dem Message-Queue, des Threads holt, der auch das Fenster erstellt hat.
    In deinem Fall der main-"Thread".
    Als Lösung fällt mir zurzeit nur ein, dass du deinen _Handler-Thread so erweiterst, dass dieser immer wieder eine Variable testet und schaut ob diese "true" oder sonstiges ist,
    und gegenfalls ein neues Fenster erstellt, usw.
    Kann man beliebig verändern/erweitern.