Snake
-
Postów
1 445 -
Dołączył
-
Ostatnia wizyta
Typ zawartości
Profile
Forum
Wydarzenia
Odpowiedzi opublikowane przez Snake
-
-
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::
GMLargument0 -= ((argument0 >> 1) & $55555555);argument0 = (((argument0 >> 2) & $33333333) + (argument0 & $33333333));
argument0 = (((argument0 >> 4) + argument0) & $0f0f0f0f);
argument0 += (argument0 >> 8);
argument0 += (argument0 >> 16);
return (argument0 & $3f);
-
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:
GMLclass 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 przyi 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:
-
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
-
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
-
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 razemMał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).
-
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
-
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
-
-
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.
mechFox
w Zapowiedzi
Opublikowano
Holy shit! Zdecydowanie jedna z najlepiej prezentujących się gier na gmclanie. Mam nadzieję, że będzie wersja na PC :) Powodzenia w produkcji!