DangBean

Narysowałem sobie prosty rysunek w InkScapie - buźka i dwa oczka, a następnie przekonwertowałem do SWF. Taki rysunek jak go się podgląda np w Foxie lub Operze nie wygląda może atrakcyjnie, ale identycznie jak w Inkscapie. Bez problemu zaimportowało do GMS, ale ... buźka i jedno oczko. Drugie oczko wcięło. :blink: Jak zaczęłem obiekt z takim spritem przesuwać po roomie to zostawiał za sobą smugi, tworząc węża, którego głową była buźka z jednym oczkiem. Czy ja coś robię źle, może te wektorowe trzeba jakoś inaczej, czy grafika wektorowa w GMS to na razie tylko chwyt marketingowy i lepiej sobie odpuścić? Jest ktoś na tym forum, kto by próbował albo używa grafiki wektorowej?

Wydaje mi się, że są dwie metody: 1. Przesuwać ten obiekt jakkolwiek, ale rysować jak zaproponował I am Lord, niezależnie od jego x,y w evencie draw gui 2. Przesuwać ten obiekt w evencie end step, po tym jak się ustawią inne obiekty, w tym bohater i view, a potem rysować normalnie

Dzięki Gnysek! Niewielu już pamięta jak to drzewiej bywało. Barżo dobra starożytna metoda. Nazywa się polling. Powinno działać. Może być tylko problem jak ktoś szybko klika na "brzuszek pajacyka". W nocy wymysliłem jeszcze jeden sposób. Ale bardziej desperacki. W obu gml-owych funkcjach dodaję na początku zmienne: GML var tmp="brzydkie słowo ok"; //w pierwszej var tmp="brzydkie słowo not ok"; //w drugiej</span> W wywołaniu javascripta piszę po chamsku: GML jsAPI_donate("donate_ok", "donate_not_ok"); Kompiluję do HTML5 i otwieram wynik w notepad++. znajduję "brzydkie słowo" i już wiem jak się nazywają obie funkcje callback. Znajduję string "donate_ok" i ręcznie podmieniam wynikowy js na obfuscatowane nazwy skryptów. Tylko to wymaga takiej akcji przy każdej kompilacji. Jestem leniem, wiec Twoja metoda lepsza :rolleyes: . Z drugiej strony i tak trzeba za kazdym razem ręcznie miętosić ten javascript aby odblokować klawiaturę... Nie mniej poczekam do 06.11 z implementacją. A nuż...

Wybacz Gnysek ale albo ja Ciebie nie rozumiem, albo Ty mnie. W czym ma mi pomóc jesli zrobię np.: script_map[? "callback_script"] = callback_script; ? Będę miał ds_map, który dla ozdoby będzie sobie w programie. Z poziomu Javascript extension: iD skryptu jest bezużyteczny, nazwa skryptu taką jaką mam w GML-u też się na nic nie przyda, a i do script_map się nie dostanę. Funkcja javascript API jest asynchroniczna - nie zwraca żadnej użytecznej wartości. Czy nastąpił sukces czy nie - do tego jest potrzebny callback - dlatego parametrami w tym API są nazwy funkcji. Ale jak się przekompiluje GML do HTML5, to nazwa "callback_func" zamienia się w "_d17" albo w jakieś inne "_H7g". Aby callback zadziałał trzeba w parametrze API podać własnie to "_d17" , a nie "callback_func". I do tego właśnie służy script_get_name(). Bo script_get_name zwraca nam właśnie string "_d17". Przykład (trochę uproszczony, ale wszystko wyjaśnia) działający w FF, Chrome i Opera, ale lecący w kosmos na IE: 3 Skrypty w GML-u: GML ///donate_ok(); show_message("Dziękujemy za podarunek."); ///donate_not_ok(); show_message("Dziękujemy, ale nie przyjmujemy Marek NRD."); //odwołanie się z GML-a do javascripta: jsAPI_donate(script_get_name(donate_ok), script_get_name(donate_not_ok)); Funkcje interface w Javascript extension (to nie jest GML): function jsAPI_donate(onSuccess, onFailure){ //tu wołamy zewnetrzne API - nie wiemy jak ono działa - znamy tylko składnię initiateDonateFunction( function () {jsAPI_callBack(onSuccess)}, function () {jsAPI_callBack(onFailure)} ); } //callback to GML function jsAPI_callBack(f_n){ try{ eval( f_n + "()" ); } catch(err){} } Tam jeszcze powinno być oczywiście rozpoznawanie czy to nie jest debug_mode, ale dla przejrzystości wywaliłem. Pytanie - gdzie tu mam wsadzić ową ds_map i w czym ma ona pomóc?

Zapisać w kontenerze można, ale najpierw trzeba znać nazwę tego skryptu. Jesli napiszesz skrypt, który nazwiesz np. GML score_error_callback_service(), to po przekompilowaniu do HTML5 będzie się on nazywał np. _G14x albo _J23 :rolleyes: . Taką wartość zwróci GML script_get_name(score_error_callback_service), co pozwala zaimplementować callback z javascript extension do GMLa. Niestety to nie działa na IE, bo GM używa javascriptowej metody replace, która w Microsofcie musi działać po swojemu, a nie po bożemu (tak sobie troszkę popodglądałem implementację w skompilowanym javascripcie :chris: ). No i qpa.

Wielkie dzięki Gnysek! Się człowiek namęczy, a tu takie buty. No i zawsze wszystkim mówię - dokładniej czytać, czytać dokładniej... Lustro se muszę kupić :mellow: . BTW przydałaby się lista rzeczy, które nie działają w HTML5. Masz problemy w programie => QQ na listę i wiesz. Z moich (niezbyt bogatych) doswiadczeń to: - mp_linear_path_object() - draw_getpixel(x,y); - Opera, IE - draw_text - na domyślnym foncie w FOXie - script_get_name() - IE - draw_roundrect_color() - obsługa klawiatury z poziomu javasript extensions - networking Szczególnie bolesne jest to script_get_name, ale obiecali, że kiedyś naprawią. Może ktoś zna jak obejść niedziałające script_get_name?

Lightiego mam postawionego lokalnie na kompie. W przeglądarce grę odpalam przez localhost:8080 (tak mam LightTPD skonfigurowany). Tak na chłopski rozum to powinno działać.

Jeśli skompiluję grę do windows to networking ładnie hula. Można grać na dwa kompy. Jeśli skompiluję do HTML5 - ni hu hu. :boxed: Może jakiś trick potrzebny?

Kiedyś takie coś robiłem. Biblioteka była za duża i ze stroną wchodził loader, a reszta dynamicznie. Na LAN to działało, ale na słabym łączu czasem wciągało się nie po kolei, fragmenty się nie wciągały itp. W kazdym razie pod onreadystatechange trzeba było podczepić funkcję, która w zależności od statusu różnie reagowała. To samo trzeba by zrobić tutaj. Tylko, że jeśli w extension zdefiniujemy np funkcję js_load_lib(), to parametrem tej funkcji powinna być GMLowa funkcja obsługi działająca w zależności od otrzymanego statusu HTTP (obsługa eventu mówiąc po GMLowemu). Jeśli jako parametr javascriptu użyjemy funkcji GMLowej, to na bank nie zadziała. Nie próbowałem, ale w GML użycie nazwy funkcji, to nie jest wskaźnik na tą funkcję. To zresztą ciekawe pytanie czy dałoby się jakimś trikiem przekazać funkcję GML jako parametr do JS. EDIT: DA SIĘ - jakby kogoś interesowało, mogę napisać jak. W każdym razie to nie rozwiązuje problemu. Wyobraźmy sobie, że mamy dwa serwery dwóch baaardzo kochających się firm. Dostajemy od nich dwa api np.: api_pepsi.js oraz api_innacola.js. W powyższym rozwiązaniu, w GM mamy oba extensions i oba js ładujemy na serwer, a program dynamicznie rozpoznaje, które js załadować na stronę klienta. Ale na serwerze są oba. Chyba, że przy każdej aktualizacji na stronę pepsi nie wgramy api_innacola.js i vice versa. Sobie nie wyobrażacie jaka chryja może być jak się za którymś razem zapomni wykasować i corposecuriti na stronie innejcoli znajdzie api pepsi :D .

Chciałbym wygenerować dwie różne wersje gry HTML5 i postawić każdą na innym serwerze. Oba serwery mają inne api do logowania użytkownika i do rejestracji score. Napisałem dwa extensions do jednego i do drugiego serwera, ale nie wiem jak zrobić, żeby w jednej konfiguracji było dołączone jedno extension, a w drugiej - drugie. Obejściem problemu jest zdefiniowanie stałej o innej wartości w każdej z konfiguracji i w zależności od tej stałej wywoływanie funkcji z odpowiedniego extension. Tylko, że oba extension muszą być dokompilowane w obu wersjach, a swoje ważą. Szukałem w dokumentacji i na forach i nic. Może ktoś zna jakiś trick?

Wydaje mi się, że problem polega na tym, iż kolejne roomy muszą być ustawione tak samo jak pierwszy, a tego pierwszego nie da się ustawić za pomocą room_set_view - "can be used to define a view within any room in your game except the current one". Trzeba siermiężnie: GML view_xport[0] = 0; view_xview[0] = 0; view_yport[0] = 0; view_yview[0] = 0; view_hport[0] = w_h; view_hview[0] = w_h; view_wport[0] = w_w; view_wview[0] = w_w; view_enabled = true; view_visible[0] = true; window_set_size(w_w, w_h); surface_resize(application_surface, w_w, w_h); //a teraz kolejny room: room_set_view(room_game, 0, true, 0, 0, w_w, w_h, 0, 0, w_w, w_h, 0, 0, 0, 0, -1); room_set_view_enabled(room_game, true); //itd.</span>

Wielkie dzięki Gnysek! Tego mi brakowało: GML surface_resize(application_surface, display_get_gui_width(), display_get_gui_height()); :) Teraz romb wyglada jak romb, a nie jak zęby od piły!

Niestety w wersji 1.2 GMS zmiana rozmiaru działała, od 1.3 kaszani produkując zmętnienie obrazu. Nie da się przeskalować view tak aby rozmiar się zmienił, a jeden piksel pozostał jednym pikslem - zawsze cośtam interpoluje. Zgłaszałem buga, ale mają inne pilniejsze. Trzeba czekać...

Myślałem, że znajdziesz błąd w mojej przeróbce i wszystko będzie pięknie... Niestety to nie tylko problem z odnajdywaniem własnego IP. Jeśli którys z graczy ma zainstalowany VirtualBox to UDP broadcast w ogóle nie będzie mu działał - wszystko pójdzie w powietrze. Zostaje TCP. A teraz ciekawostka: wywaliłem (tymczasowo) driverka od VirtualBoxa i zapuściłem Twój (zmodyfikowany) programik. I tu zdziwionko: pokazał, że mam dwie karty sieciowe - obie z identycznym adresem, co nie jest prawdą, bo ich IP różnią sie ostatnią cyfrą. Nie mniej bez VirtualBoxa gra, która piszę może mi zadziała.

Niestety broadcast robi tylko na jednej masce. Zmieniłem w następujący sposób: w create event: GML _ip = ds_list_create(); w networking event: GML ds_list_add(_ip, ds_map_find_value( async_load, "ip" )); //_ready = true; //event_user( 0 );</span></span> dodałem draw event: GML var i, ile_ip; ile_ip = ds_list_size(_ip); for(i=0; i<ile_ip; i++){ draw_text(16, i*16, ds_list_find_value(_ip, i)); } User event - już niepotrzebny. Niestety jest tylko jeden wynik - IP VirtualBoxa. Obu moich kart sieciowych - nie widzi :( . Trochę to dziwne bo jak puszczę ipconfig /all to mi pokazuje, że w chwili obecnej tylko karta wifi jest aktywna - tej karty lokalne IP powinien pokazywać.

Fajny pomysł. Na pierwszy rzut oka powinien działać. Odpaliłem - nie zadziałało. OK - sprawdziłem porciki - zajęty. Zmieniłem port i zadziałało :rolleyes: , ale szczena mi opadła bo mój globalny IP to 83.23...., lokalny IP to 10.34...., a GMS pokazało ni z gruszki ni z pietruszki 169.254.188.19 :blink: . Poszukałem w kompie i okazało się, że jest to IP dla VirtualBoxa, który nawet nie był uruchomiony podczas testu! Ciekawe jak GMS to wygmerał? Z UDP hole punching może nie pójść tak łatwo :( .

w 39dll była funkcja tcpip(), którą można było pobrać IP komputera, na którym działa gra. W GMS czegoś takiego nie widzę. Zna ktoś jakiś trick?

Bardzo przejrzyście opisane :) , ale wkradł się mały błąd: zgodnie z dokumentacją pierwszym argumentem network_create_server jest "The type of server to create", a nie nr socketu. Czyli w przypadku hosta network_craeate_socket jest niepotrzebny, wystarczy: GML ServerSocket = network_create_server(network_socket_udp, 30666, 32); Druga uwaga: powyższy kod wysyła cały bufor (1024 bytes), lepiej wysyłać tylko dane, bez śmieci - do tego służy buffer_tell: GML network_send_packet(GameSocket, DataBuffer, buffer_tell(DataBuffer));

Dzięki. Działa. Ale to trochę wiocha, bo jak piszę komentarz, to skupiam się na treści, paluszki same piszą i... zonk :blink: . Komu i do czego jest potrzebne w GM aby alt-o otwierało folder programu? Z drugiej strony nie ma co narzekać - mogli przecież zrobić alt-C skrótem na formatowanie dysku C:. Dzięki Ci o Durszlaku, że nie zrobili.

Tylko kiedy wpisuję "ó" to zamiast tej zacnej literki pojawia mi się okienko z zawartością katalogu game maker studio :crying: . Można wpisać w notatniku i przekopiować, niestety mam upierdliwy obyczaj pisania komentarzy i co chwila mi taki zonk wyskakuje. Jeszcze fajniej działa "ź".