gnysek

Pierwszy post został edytowany po wstawieniu, więc stracił sens

Jest jakaś taka funkcja sound_is_playing albo podobna i sprawdź z jej pomocą czy się załączył. Popatrz też na audio_create_stream to chyba obecnie lepsza funkcja. Jak siądę do PC spróbuję popatrzeć na problem, z telefonu ciężko.

sound_delete usuwa całkowicie zasób. sound_discard nie powinni być używane bo ma status "przedawnione" i usuwało bufor z RAMu, ale to dotyczy tylko kawałków które są skompilowane razem z grą a więc w pliku data.win. Ponowne odtworzenie ładowało je znów do pamięci. Tych dodanych w czasie gry to nie dotyczy, bo utraci też ich źródło.

A co ma kasowanie do odtwarzania? Jak się nie odtwarzają, to może nie są prawdziwymi wav.

4000+ graczy na raz, nie spadło poniżej 2000 jak na razie, to chyba niezły wynik.

Czy to jest takie The Sims, w którym Simy robią co chcą a my mamy kilka domów na raz ?

A czemu nie enum herostate { idle, walk } set = [scrHero_idle, scrHero_walk]; Wtedy 0,1,...,n samo zostanie ustawione kolejno ? Btw. w 2.3 skrypty nie są po kolei z drzewkiem i reszta zasobów też nie.

sound_delete po odtworzeniu

Nie piszesz nic o usuwaniu po pobraniu dźwięków, więc zakładam, że tego nie robisz, więc załadowanie wszystkich plików w projekcie gry na start dałoby ten sam efekt. Co więcej, tak mi coś wygląda, że w ten sposób który tutaj pokazałeś, niektóre dźwięki załadujesz ponownie pod nowym ID i będą zamulać niepotrzebnie RAM pamiętaj o zwalnianiu zasobów.

. @Wojzax na razie typowe HM, mam parę koncepcji co więcej można zrobić, ale jeszcze nie mogę się zdecydować, staram się mierzyć siły na zamiary i nie przesadzić z wdrażaniem rzeczy, które zajmą miesiące. Mam jeszcze jakiegoś buga przy kodzie odpowiedzialnym za powtarzanie akcji na przytrzymanym klawiszu, korzystam z "if keyboard_check_released(vk_any)" i potem "keyboard_lastkey" i jak w jednej klatce obrazu puszczę dwa przyciski, to kod wykrywa tylko jeden, dlatego na koniec kamera zjechała na sam dół

Przerażające jest to, że autor ma 27, być może nawet dom i dzieci, a wtedy miał 16 lat

11 letnia nekromancja na forum, nieźle.

OK, nie ma polskich znaków i domyślnie wyświetlają "bold", pewnie dlatego przegapiłem tego fonta robiąc research Ale ogonki można dorobić, muszę się jej przyjrzeć, dzięki za cynk

A ja tak z ciekawości zapytam - jak się nazywa font użyty na interfejsach ?

Sporo grafiki to wciaż robota odręczna, na szybko, lub nawet w paincie (budynek gorących źródeł), ale na razie skupiam się na działaniu silnika i żebym po prostu widział, czy coś działa czy nie, a dopasowywaniem i faktyczym wyglądaniem zajmę się, jak całość będzie działać (a silnika mam już tak z 50-60%). Do końca marca chciałbym już móc wypełniać grę prawdziwym contentem, zamiast jedynie generować zapchajdziury w ramach testów

Dokładnie tak. A przed chwilą próbowałeś pod jedną wartością mieć dwie zmienne - i liczbę i tablicę jednocześnie. Tablica w tablicy to generalnie stara tablica 2D, jedyna różnica teraz, to że za każdym razem możesz mieć inną ilość elementów jeśli chcesz, ale jak się pilnujesz, to używasz je tak samo (i nawet zapis grid[1, 2] powinien działać).

Ja nie bardzo rozumiem co tu się dzieje, ale: jeśli napiszesz grid[0][0] = 1, to tak samo jakby napisać grid[0] = [1]; jeśli dodasz grid[0][1] = 2, to mamy grid[0] = [1, 2]; Mam wrażenie, że kasujesz sobie tablicę 2D.

O UDP mówią, że jest jak krzyczenie na ulicy. Wiesz, że krzyknąłeś, ale nie wiesz, czy ktoś słyszał NIe bawiłem się w obecny gmowy networking, ale wątpię, żeby pakiety były łączone - wtedy byśmy je nazwali buforem, a nie pakietami. Kiedyś obieraliśmy wersję, że pozycję można wysyłać przez UDP, bo utracenie pakietu niewiele zmieni, natomiast itemy, czy fakt np. użycia umiejętności wysyła się TCP. Możesz połączyć pomysły i np. wysyłać pozycję + jakiś zakres danych które nie muszą być tak często odświeżane (np. jakąś strefę mapy widocznej przez gracza), zapewne jeśli jest tam sporo nieruchomych przedmiotów, to nawet wysłanie raz na 1-3 sekundy synchronizacji skrawka mapy nie będzie powodować po stronie gracza jakichś zauważalnych problemów. Można też wtedy ustawić, że jak przez np. 5 sekund nie przyszły dane, to się dana rzecz sama usunie. Zawsze jednak wszystko wychodzi dopiero w praniu i przy obciążeniu, więc testy to najlepsze rozwiązanie.

Ale jak uniesz tą linijkę, to sie nie wykonuje reszta kodu. Zatem display_set_gui_maximize nie musisz uzywać, tak by wychodziło. Co do application_surface i viewów... no to tak jak sobie chcesz zrobić, tak musisz to ustawić, ja nie będę za Ciebie zgadywał. Musisz sam ustalić, czy na pełnym ekranie gra ma być powiększona czy 1:1, tak samo w trybie okienkowym. I samemu przeskalować to, przeliczyć proporcje itd. Nie jestem wróżką, żeby wiedzieć co chcesz osiągnąć, a application_surface, viewy i gui to trzy różne warstwy które mogą mieć różne rozmiary. Do tego application surface samemu powinno sie w jakimś post_draw rysować i wtedy też można to robić z innym rozmiarem niż 1:1, więc za dużo tu jest czynników i trzeba pod siebie wszystko ustawić po prostu, spokojnie to rozrysowując i przeliczając na kartce papieru.

Dresiarski Geralt.

Zjadłeś alarm[0] = 10 w step, bez tego alarm sie nigdy nie wykona. Nie wiem też po co zmieniasz application_surface, to się powinno zmieniać tylko jak zmianie ulega rozmiar renderowanego okna gry i tylko jak używasz application_surface, a nie wiem czy go w ogóle używasz.

Za dużo tego, żeby ktokolwiek czytał. Jeśli chcesz zadawać pytania, to musisz konkretnie, a nie ścianę kodu. Jeśli zmieniasz rozmiary okien, to musisz umieć dzielić i mnożyć, żeby ustalić proporcje. Poza tym korzystasz z GMS 1.4, które nie jest wspierane już trzeci rok, więc tam rzeczy działają inaczej i już nie bardzo nawet mam ochotę się cofać do różnic z wersją obecną, a akurat na tym tle są. Rozmiary okien, widoków, skalowania można ustawiać na różne sposoby - im więcej tym mieszasz, tym łatwiej wpaść w tarapaty, wiec zawsze, ale to zawsze sprawdź jakie są wartości wszystkiego i czy są odpowiednie proporcje - odpowiedzi powinny wtedy przyjść same. btw. if (window_get_fullscreen()) { options[|2]=("Fullscreen") } else { options[|2]=("Window") } Przecież napis się nie zmienia, bo go ustawiasz na sztywno w create (tworząc zawsze nową mapę) a zmieniasz tylko jak klikasz enter, wiec oczywiste, że się nie zmieni sam, bez kliknięcia.

Dobra, wiem gdzie jest pies pogrzebany. window_get_size() przez pierwsze kilka klatek po wyjściu z pełnego ekranu nadal zwraca wielkość ekranu na fullscreenie i dlatego jest błąd. Poprawiłem go tak: // create display_set_gui_size(1280, 720) full_screen = -1; // step if (full_screen != window_get_fullscreen()) { full_screen = window_get_fullscreen(); alarm[0] = 10; } // alarm0 if (full_screen) { display_set_gui_maximize( 1, 1 ); } else { display_set_gui_maximize( window_get_width()/1270, window_get_height()/720 ); } // moje draw GUI: draw_set_halign(fa_center); draw_text( window_get_width()/2, 20, "Pause"); Wystarczyło za pomocą show_debug_message wyrzucić sobie co zwraca window_get_width() .

nie, dwa ostatnie 0,0 - zajrzyj w końcu do dokumentacji i przeczytaj opis funkcji! Poza tym, jeśli tylko jeden element jest źle, a reszta ok, to znaczy, że coś po drodze zmienia rozmiary. Muszą być albo wszystkie źle, albo wszystkie dobrze, nie może być pół na pół.

Nie wiem co mam odpowiedzieć, bo to nie są screeny z gry. Widać, że fonty mają ten sam rozmiar, wiec nie wiem co się dzieje w Twojej grze. Zalecam wypisanie sobie na ekranie wszelkich wartości i sprawdzenie, czy faktycznie są dobre proporcje (dlaczego w ogóle 720 i 360?). Dla pewności, jako 3 i 4 argument w display_set_gui_maximize możesz podać 0,0, żeby się offset nie robił - co oczywiście jest w dokumentacji. Wciaż też twierdzisz, że tryb okna i pełnego ekranu maja tę samą rozdzielczość co nie jest możliwe