Snake

Holy shit! Zdecydowanie jedna z najlepiej prezentujących się gier na gmclanie. Mam nadzieję, że będzie wersja na PC :) Powodzenia w produkcji!

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.

Pominięcie sprawdzania wersji nic nie da, bo GMThreads potrzebuje adresów pewnych funkcji w "runnerze" by mógł w ogóle funkcjonować. A że teraz update'y GM-a wychodzą częściej niż kiedyś to musiałbym wprowadzić automatyczne wyszukiwanie tych adresów, żeby nie aktualizować DLL-a co nową wersję GM.

GMThreads już nie będzie uaktualniane z racji że używanie wątków z GM za dużo problemów sprawia. Jak ktoś tak bardzo potrzebuje to może spróbować użyć tego: http://gmc.yoyogames.com/index.php?showtopic=519138 i napisać funkcje w DLL, która wywoła execute_string w wątku. Chociaż nie wiem jak to się będzie sprawować.

Można jeszcze wydajniej to wyliczać pewnym strasznie wyglądającym algorytmem:: GML argument0 -= ((argument0 >> 1) & $55555555); argument0 = (((argument0 >> 2) & $33333333) + (argument0 & $33333333)); argument0 = (((argument0 >> 4) + argument0) & $0f0f0f0f); argument0 += (argument0 >> 8); argument0 += (argument0 >> 16); return (argument0 & $3f); source

Mój łysy łeb na tle fantastycznych magnesów lodówkowych:

W tym momencie w wolnym czasie pracuje nad finalną wersją GMAPI, więc gmkasm musi na razie poczekać :P

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

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 )]; } }

Po drobnych poprawkach powinno trybić pod Mono -- w kilku miejscach użyłem funkcji z WinApi :P Rejestru pewnie też tam niema.

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 systemach kontroli wersji 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: GMK Assembler v0.1.0 (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 tutaj) Kod źródłowy: https://github.com/snakedeveloper/GMK-Assembler Screenshot:

Nujabes - Kumomi

Pewnie false-positive. Wyślij ten plik na VirusTotal i sprawdź czy inne AV też to wykrywają, jak chcesz się upewnić.

Thx cpt. obvious.

Eh, ale grafika 2D dawała ten wyjątkowy klimat! Przywróćcie z powrotem dwa wymiary, dużo czasu wam to nie zajmie. :P

Google naprowadziło mnie na algorytm zwany "średnią Bayesa". Korzystają z tego m.in. na IMDB (pod listą jest opisane jak to wyliczyli). A tu: http://www.animenewsnetwork.com/encycloped...tings-anime.php można porównać wyniki tego algorytmu z średnią ważoną :P

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

Ten "uproszczony silniczek" to Twoja pierwsza aplikacja sieciowa z wykorzystaniem socketów? 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).

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

Hm, Xenon Core na pewno nadaje się do listy najlepszych silników 2010 ? Z tego, co kojarzę, to on powstał wcześniej niż 2010 rok :psichix: Albo myli mi się w tym momencie z innymi PsichiXa projektami z "xenon" w nazwie :)

Spróbuj tego: http://support.microsoft.com/kb/307545

Kofel.

Bardzo fajne, tylko czemu aplikacja cały czas obciąża w 100% CPU ? Przydałoby się to poprawić. Poza tym tak samo jak w tym przezroczystym GUI z Xenona na oknie robią się "glitche" na Win7 z wyłączonym aero. :ranmus:

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

Prawdopodobnie kompilujesz ten kod jako aplikacje Windows/GUI a nie jako DLL. Nie wiem czego używasz jako IDE, ale w opcjach projektu powinno dać się przestawić. Dev C++: http://www.ibm.com/developerworks/webspher.../devcppOpts.gif Code::Blocks: http://www.noquarterarcade.com/system/file...gets_dialog.png (menu "Type" z prawej strony) Albo utwórz nowy projekt z szablonu DLL.