Grafik Engine Erstellen

    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.

    Ein Server hat maximal 8-12 Spieler und Pro spieler Position und Kollisionsberechnung

    Hi,

    Zitat

    Wenn du ein schnelleres Script hast, dann immer her damit


    hab mir den asm-Code mal disassembliert, ich glaube absolut nicht, dass dieser Code schneller ist als die GDI-Funktion TransparentBlt(), die genau dafür gemacht ist. Den ASM- Code zu beschleunigen, z.b per SSE (SIMD) 4 Pixel gleichzeitig zu berechnen, sollte das Problem nicht sein

    Aber ich stimme Ealendil zu, die "pro Frame Bewegung" funktioniert nicht. Eine "alle XX Millisekunden Bewegung" allerdings schon. Flüssige Bewegung völlig unabhängig von der aktuellen Framerate ist das Ziel. Dann ist auch völlig schnuppe, ob der Server oder die Übertragung mal "hustet", denn dann kann der Client anhand der "nächsten" Position die Zwischenbilder berechnen. So machen das sämtliche MMORPG´s.....nicht ohne Grund.

    Zitat von Andy

    Aber ich stimme Ealendil zu, die "pro Frame Bewegung" funktioniert nicht. Eine "alle XX Millisekunden Bewegung" allerdings schon. Flüssige Bewegung völlig unabhängig von der aktuellen Framerate ist das Ziel. Dann ist auch völlig schnuppe, ob der Server oder die Übertragung mal "hustet", denn dann kann der Client anhand der "nächsten" Position die Zwischenbilder berechnen. So machen das sämtliche MMORPG´s.....nicht ohne Grund.


    In AutoIt ist das aber nicht so einfach zu schaffen. Um Darstellung und Berechnung vollständig zu entkoppeln würden 2 Threads benötigt. Einen um Eingaben zu verarbeiten und die Berechnungen durchzuführen und einen zweiten um die Bilder zu erstellen.
    Edit: Über einen Timer-Interrupt (_Timer_SetTimer, evtl. auch Adlib) lässt sich das aber schon akzeptabel lösen denke ich.

    Edit2: Hmm, ich glaube ich bin gerade auf dem falschen Dampfer. Bewegungen immer nach der altbekannten Formel s = v*t berechnen ;) (s = Bewegung seit letzter Berechnung, v = Geschwindigkeit, t = Zeit seit letzter Berechnung) Beschleunigte Bewegungen sind etwas schwerer aber auch zu schaffen.

    Einmal editiert, zuletzt von progandy (6. Mai 2012 um 21:04)

    Andy: Wann hast du Meinen Code disassembliert?
    Zur Zeit funktioniert die Tranzparenz nur Mit BitBlt ohne eine Andere Funktion...

    Hi,

    Zitat von smincke

    Andy: Wann hast du Meinen Code disassembliert?

    sofort nach deinem ersten Posting^^
    Hab mir, bevor ich den Debugger ins AssembleIt integriert hatte eine Funktion gemacht, die den von Fasm generierten Bytecode an IDA übergibt, wenn man will kann man auch den Ollydbg benutzen, wobei der kein SSE und 64Bit-code kann, deshalb fällt Olly für mich als Debugger flach :thumbdown:
    Dein asm-Code hat definitives Beschleunigungspotenzial, schau dir mal die diversen Seiten von Agner Fog oder Mark Larson an zum Thema "Optimization". Generell lohnt ASM- code nur dann, wenn man wirklich Speed rausholen kann, zzt habe ich ein Alphablend in der Mache, dass 3 bis 4x schneller ist als die API-Funktion. Auf einem Tablett sogar sehr viel schneller!

    Daher sollte man so weit es geht die API-Funktionen (in deinem Script eben TransparentBlt() ) nutzen und das AutoIt-Script "profilen" und die Zeiten der einzelnen Funktionen ausstoppen um den wirklich langsamen Teil (im inner loop) zu finden.
    Eher selten hängt es dabei erfahrungsgemäß an den API-Funktionen :rolleyes:

    Zitat von progandy

    Edit: Über einen Timer-Interrupt (_Timer_SetTimer, evtl. auch Adlib) lässt sich das aber schon akzeptabel lösen denke ich.

    so mache ich das idR.
    Btw, da die kurzen ASM-Codes so gut wie immer Threadsicher sind, ist "echtes" Multithreating in AutoIt machbar, jedenfalls hab ich hier einige Beispiele, bei denen Bildbearbeitung (da hab ich die meisten Funktionen^^ ) auf mehreren Cores gleichzeitig abläuft. Ich glaub, da ist bald mal wieder ein TUT fällig^^

    Ich benutze aber kein ASM mehr zum zeichnen... Sonern nur um schnell am anfang des Scriptes eine Maske zu erstellen. Mit einer Maske kann sogal BitBlt arbeiten...