Skocz do zawartości

Snake

Użytkownicy
  • Postów

    1 445
  • Dołączył

  • Ostatnia wizyta

Odpowiedzi opublikowane przez Snake

  1. Nawet jak w kolejnej wersji wprowadzi się chociaż 1 bugfix to większość kodu w runnerze się przemieszcza, więc nie widzi mi się analizowanie wszystkiego co kolejny update :)

     

    Co do GMAPI to mam tam już zrobione automatyczne szukanie adresów i kilka ficzerów, ale trochę jeszcze zostało do zrobienia a teraz nie mam czasu by się tym zająć, w dodatku niedługo wyjeżdżam za granice gdzie nie będę miał dostępu do kompa, więc trochę to potrwa zanim jakiś update wydam. Póki co możesz użyć "GMAPI" z linku który podałem wcześniej w temacie, PsichiX.

  2. Mi też to GUI jakoś nie pasuje :P Gierka skojarzyła mi się z

    z NES-a, jeśli byłoby to coś w tym stylu (z takim widokiem w grze też) i jeszcze online, to byłbym wniebowzięty :D
  3. Opcjonalnie można by też użyć params, żeby wygodniej korzystać z tej metody (jak w GM-ie). Nie trzeba by tworzyć tablicy przy wywołaniu, chociaż jeśli byłaby taka potrzeba to też można ją przekazać. Czyli w sumie coś takiego:

    GML
    class Program {

    static void Main( string[] args ) {

    var random = new Random();

     

    for ( int i = 0; i < 10; i++ ) {

    Console.WriteLine( random.Choose( "hello", "world", 123, 123.123 ) );

    Console.WriteLine( random.Choose( new object[] { "hello world", 321, 321.321 } ) );

    }

    }

    }

     

    public static class RandomExtensions {

    public static object Choose( this Random aRandom, params object[] aParameters ) {

    return aParameters[aRandom.Next( aParameters.Length )];

    }

    }

  4. GMK Assembler

    Aktulna wersja: 0.1.0 (23 kwietnia 2011)

     

    O programie:

    GMK Assembler służy do rozkładania projektów gier Game Makera na osobne pliki danych i umożliwia odbudowanie projektu na ich podstawie. Aktualna wersja obsługuje wersje plików GM od 8.0 do 8.1.71. Program dopiero jest rozwijany i na razie umożliwia jedynie eksport/import plików XML w trybie "Accurate". Projekt jest open source, wydany na licencji GPL.

    Do czego to może się przydać ?

    Pliki utworzone po "deasemblacji" gry można przeglądać i edytować w edytorach tekstu czy programach do obsługi formatu, w którym zapisano dane. Może więc się nadać np. do przeszukania projektu gry czy jakiejś masowej edycji zasobów. Albo można wykorzystać te pliki do napisania jakiegoś własnego narzędzia do GM :P GMK Assembler jeszcze miał znaleźć zastosowanie przy
    i porównywaniu plików gier, niestety aktualna wersja niezbyt się do tego nadaje, jako że nie zaimplementowałem jeszcze trybu "Independent", w którym eksportuje się zasoby porzucając dane o identyfikatorach, odbudowując wszystko na podstawie systemu plików. Zdecydowałem się zaimplementować tryb Accurate jako pierwszy, by program obsługiwał wszystkie pliki GMK, w sensie że nazwy zasobów mogą się powtarzać i zawierać nieprawidłowe znaki. "Independent" znajdziecie w następnej wersji :)

    W przyszłych wersjach:

    • Możliwość eksportowania zasobów w trybie "Independent"
    • Dodatkowe opcje formatów danych, np. wyłączenie komentarzy w XML, użycie CDATA zamiast encji przy niektórych wartościach
    • Eksport do formatu JSON i kawałków danych w formacie GMK
    • Możliwość wybrania z drzewa zasobów, które masz zamiar wyciagnąć z gry
    • Wersja konsolowa programu
    • ...

     

    Download:

    (wymaga .NET Framework 4.0; instalator powinien wykryć czy go posiadasz i umożliwić pobranie jeśli go nie znajdzie, ale jak coś to możesz też pobrać go
    )

     

    Kod źródłowy
    :

    Screenshot:

    gmkassembler.png
  5. klient nie może nie wczytać pierwszych 2 lini buffora ponieważ to nie jest UDP a TCP. TCP jest liniowy, pakiety nie przychodzą pomieszane ORAZ mają swój protokołowy hash który zapewnia że pakiet dotrze w całości (choć może być niby podzielony na części) to jednak dotrze "cały".

    Tak, TCP zapewnia, że wszystkie wysłane dane dotrą w postaci niezmienionej, ale nie że w jednym momencie. TCP to protokół strumieniowy -- operujesz na danych gdy tylko jest to możliwe, a nie gdy dojdą już wszystkie pakiety składające się na twoje dane. Podział wiadomości musisz implementować sam. Te 2 bajty zawierające rozmiar wiadomości _mogą_ zostać nie wczytane w całości przy pojedynczym receive, chociaż jest to mało prawdopodobne by osobno dotarł pakiet z tylko jednym bajtem, to jednak możliwe. A 39dll najwidoczniej ma błąd.

     

    Oznajmiłeś, że świadomie nie napisałeś dzielenia danych odebranych od klienta na pakiety/wiadomości, chociaż jest to poważny błąd, który praktycznie uniemożliwia korzystanie z silnika. Uznałem więc, że wcześniej nie wiedziałeś że i dlaczego należy je dzielić :P

  6. Ten "uproszczony silniczek" to Twoja pierwsza aplikacja sieciowa z wykorzystaniem socketów?

     

    Co do dzielenia pakietów, jestem tego świadom... ale nie spodziewam się by ktoś wysyłał 16000 bajtów za 1 razem

    Małe wiadomości też mogą nie dojść w jednym kawałku. Co więcej, jeśli recv nie wczyta tych "2 pierwszych bajtów w CBuffor" a 1 to bardzo źle się skończy. Ponadto, gdy klient wyśle kilka wiadomości kolejno po sobie w małym odstępie czasu to wszystkie na raz mogą zostać wczytane przy jednym wywołaniu recv na serwerze, co poskutkuje porzuceniem wszystkiego, co znajduje się za pierwszą wiadomością w buforze. Podobnie jest z wysyłaniem danych -- wysyłasz nieblokującym gniazdem bufor i nie sprawdzasz nawet czy wszystko zostało wysłane.

     

    Co do tego kodu powyżej, to wychodzi podobnie co przy metodzie ze sprawdzaniem rozmiaru otrzymanych danych przy blokujących gniazdach -- jak zaczniesz wczytywać te dane w drugiej pętli to przymuli resztę klientów i tak po kolei przy każdym obsługiwanym połączeniu (w dodatku jak ktoś dostanie "laga" albo nastąpi jakiś błąd połączenia to zamuli jeszcze bardziej).

  7. edit: jak ktoś mi wytłumaczy dlaczego bufforki są odwrócone, to pogadamy ;)

    Kolejność obliczania wartości dla parametrów przekazywanych do funkcji. W standardzie C++ nie ma ustalonej żadnej standardowej kolejności -- kompilatory używają takiej, która w danym momencie jest najbardziej optymalna. W tym przypadku przy tym drugim "printf" metody readbyte były wywoływane od prawej do lewej, dlatego bufory wyglądały na odwrócone.

     

    EDIT: Jeśli serwer ma być skalowalny to model I/O sieci, który użyłeś w swoim silniku się raczej do tego nie nadaje. Może lepiej obsługiwać sockety metodą z "select()", + ew. z podziałem na niewielką ilość wątków? Też jeden z prostszych sposobów napisania serwera i przy tym wydajniejszy. Chociaż nie programowałem jeszcze socketów pod linuxem, więc nie jestem pewien jak by się to sprawowało. Poza tym zdaje się, że w ogóle nie napisałeś obsługi pakietów i wczytujesz dane do bufora jak leci, po czym natychmiastowo je przetwarzasz, co będzie się kończyć błędem jak wiadomość od klienta nie dotrze w jednym kawałku (co zdarza się praktycznie cały czas, jak nie testujesz na localhoście czy jak pakiet będzie większy niż te parę bajtów). Mogę być w błędzie, ale przeglądając klasę CBuffer na szybko niczego nie zauważyłem w stylu dzielenia bufora na osobne pakiety itp. :P

  8. Sprawdź, czy ktoś dostał bana za używanie frapsa na grach z VAC, o ile dobrze kojarze to ten używa hooków na D3D. Co do programu to ciekawie się zapowiada, mam nadzieję że ujrzy światło dzienne :) A interfejs IMO fajny, bo prosty :D

×
×
  • Dodaj nową pozycję...