Temat zbiorczy na drobnostki

[lew_leo]

39dll jest tak wiekowy, ze juz 3 lata temu by Cie wytrzaskano za jego uzycie.

 

Wez uzyj albo wbudowanego albo faucet networking

 

dzięki zobacze ale nie o to akórat pytałem :X a dll jest mi potrzebna do gm8.1 nie studio

 

pytanie ciągle aktywne

[lenin]

Chcę żeby wróg uciekając omijał przeszkody i żebym widział drogę którą sobie obrał

Taki oto kod zrobiłem napisałem

 

GML

ucieczka=path_add()

mp_potential_path(ucieczka, instance_nearest(x,y,enemy_safezone).x, instance_nearest(x,y,enemy_safezone).y, 1, 8, false)

draw_path(ucieczka, x, y, true);

 

niestety, wróg kieruje się wtedy w stronę enemy_safezone i gra się zacina :(

Co robię nie tak?

a rysuje Ci tego patha? zapisz mp_potential_path do zmiennej i sprawdź jej wartość. może nie znajduje ścieżki i gdzieś zapętla i wiesza się.

 

 

[Wojzax]

GML

ucieczka=path_add()

wartosc=mp_potential_path(ucieczka, instance_nearest(x,y,enemy_safezone).x, instance_nearest(x,y,enemy_safezone).y, 1, 80, false)

path_start(ucieczka, 1, 0, false);

 

tak teraz wygląda kod i jest trochę lepiej - przeciwnicy uciekają tak jak chciałem, wciąż jednak przy specyficznych sytuacjach - gdy przeciwnik idzie obok przeszkody, gra się zawiesza.

w ciągu tej ucieczki wartość mp_potential_path (zmienna wartosc) wynosi 1 i pozostaje taka także w momencie zawieszenia się.

 

@EDIT:

no tamten kod poprzedni nie rysował patha

[lenin]

aktualizuj sobie co jakiś czas w stepie mp_potential_path i startuj go od nowa. powinno pomóc jeśli problem jest w tym co myślę

[Wojzax]

Yyy, ale ja to mam w stepie, czyli tak jakby startuje się non stop.

 

@EDIT:

może nie powinno to być w stepie?

nawet próbowałem zrobić żeby po 50 stepach path się usuwał, ale dalej się zacina.

 

@EDIT2:

może zrobiłbym to używając grida? I tu pytanie: czy jak używa się mp_grid to przeciwnik będzie się poruszał tylko w 8 kierunków i zakręcał w taki "ząbkowany" sposób?

 

@EDIT3:

zrobiłem z gridem, teraz działa chociaż topornie chodzą. Ale kiedy przeciwnik dotyka czerwonego pola i wtedy każę mu szukać patha to też gra się zacina, meh.

[Ignatus]

Jak najskuteczniej sprawdzić co mi zamula grę?Coś mi obciąża pamięć i z czasem gra chodzi coraz wolniej.Mam przykładowo 100leveli.Od pierwszego lvl mam 60/60fps , koło 15 robi się 55 i tak stopniowo coraz mniej aż w okolicy 60 mam 40fps- myślałem że to wina coraz bardziej rozbudowanych leveli- ale przełączyłem z 60 levelu na 1 - i tak też nędzne 40fps.Mam sporo particles ale wszystkie systemy są niszczone konsekwentnie- poza tym ciągle te same texture page i brak DS

Jak przeprowadzić skuteczne śledztwo?

[lenin]

Uruchom debuggera i wybierz żeby wyświetliło Ci okno 'profiler'. tam znajdziesz wszystko co potrzeba

[Ignatus]

Tak robię od początku,nie wiem jednak na co mam zwrócić uwagę,niby nic się nie zmienia- a fps spadają.Jest jakaś funkcja która sprawdza czy jest jakikolwiek particle system uruchomiony?

[Uzjel]

Może to głupie pytanie, ale czy w każdym roomie room_speed masz ustawione na 60?

[Ignatus]

Mam obj_control który ustala room_speed=60 i jest on oczywiscie w kazdym roomie.Co istotne stopniowy spadek wydajności dotyczy tylko słabych urządzeń(bo cały czas mowa o androidzie)

[Uzjel]

Ile mniej - więcej jest instancji na najmniejszej i największej mapie?

[Ignatus]

Tak mniej więcej od 5 do 100

[Amaterasu]

Walnij w jakimś obiekcie draw_text(0,0,instance_count) w evencie Draw GUI. Pokaże ci, ile obiektów jest w tej chwili aktywnych w roomie.

Czy używasz tilesetów? Kiedyś gra mi spowalniała, gdy było dużo tilesetów (wystarczyło, że były we wcześniejszych roomach), ale to było jeszcze w GM 7.0

Rysowanie wielu rzeczy naraz, nawet jeżeli tylko w jednym obiekcie, również spowalnia grę.

[lenin]

[pytanie]

Czy dodanie dużych grafik do projektu wpływa jakoś na działanie gry ? Oczywiście pomijam dłuższe wczytywanie się gry i ładowania grafik na początku.

[Amaterasu]

O ile nie masz zamiaru wyświetlać tysiąca obrazków o rozmiarze 800x600 tysiąc razy na sekundę, nie będzie jakiegoś wielkiego problemu. Ja np. w każdym projekcie używam sporej ilości surface'ów różnych rozmiarów i nie doświadczam spowolnień (raczej przyspieszenia, bo nie potrzebuję rysować obiektów w każdej klatce od nowa).

[lenin]

a tilesy o rozmiarze 1500x1500 tworzące background w edytorze rooma ? Niestety nie mogę poskładać tego z pojedynczych elementów bo nie osiągnę takiego efektu jakiego oczekuję.

[Amaterasu]

ugh, 1500x1500...

probowałbym użyć draw_background_part jeżeli to możliwe, w jakiś sposób znajdować odpowiednie współrzędne backgrounda do rysowania

rysowanie ponad połowy backgrounda poza obszarem rysowania to spora strata czasu

 

tzn. jeżeli tilesy mają mniejsze rozmiary niż 1500x1500, to nie będzie specjalnego problemu

jeśli to one mają takie rozmiary, to ten background, który wczytujesz, musi być naprawdę spory, choć przy współczesnych parametrach, jakie mają karty graficzne, to nie ma obawy o brak miejsca na karcie graficznej

[lenin]

background mam podzielony wcześniej w programie graficznym na te części 1500x1500, ustawione jako tilesy i poukładane jak puzzle w room edytorze.

Ale jeśli room miałby mieć wielkość powiedzmy 30000x30000 lub więcej to już słabo pewnie będzie:/

[Amaterasu]

w życiu nie robiłem tego typu testów

GameMaker jest skrojony na miarę gier, których grafika składa się z małych obrazków (jest tak nawet napisane w manualu, razem z uwagą, żeby sprite'y były tak małe, jak tylko to możliwe). Jestem jednak przekonany, że o ile nie rysujesz jakiejś niesamowitej ilości dużych obrazków naraz, to spadek wydajności nie będzie na tyle widoczny, aby wymusić uproszczenie mechaniki gry, jeżeli o to ci chodzi. Sprawdź, ile fps-ów wyciągnie twoja gra z tymi tilesami i miej tę liczbę na uwadze przy wprowadzaniu nowych elementów gry.

[lenin]

Ostatnie pytanie

tak gdybam i gdybam. Jeśli wrzucę wszystko do surface i będę rysował tylko jego część widoczną na ekranie, to nie powinno mieć większego znaczenia jego wielkość i co zawiera? Tak na moją logike

[Amaterasu]

30000x30000 = 9*10^8

9*10^8*8 = 7,2*10^9 ~~ 7 GB

tyle zająłby surface 30000x30000 na karcie graficznej przy optymistycznym założeniu, że karta graficzna nie zamieniłaby wymiarów na 32768*32768

już lepszym pomysłem są tilesety

możesz też zrobić tak, że znając położenie poszczególnych tilesów w roomie (np. korzystając z ds_listów lub z ds_grida) i położenie viewu w roomie, rysujesz fragmenty poszczególnych backgroundów prosto na surface o wielkości okna, w ten sposób pozbędziesz się tilesów w roomie (co oczywiście utrudni projektowanie rooma i ułożenia backgroundów, do tego trzeba by zrobić własny edytor albo ustawiać wartości ręcznie) i zyskasz na wydajności, a do tego miałbyś kontrolę nad tym, jakie grafiki są obecnie załadowane w grze, bo jest możliwość dynamicznego tworzenia i usuwania backgroundów.

[lenin]

a myślałem, że rysowanie na surface nie zabiera pamięci, dopiero samo jego rysowanie już tak:/

Dobra zostawię narazie tilesy tak jak są. Jak będę zmieniał testowego rooma już na tego właściwego( większego) i zobaczę jakiś znaczący spadek wydajności to machnę własny edytor ( pomysł na niego już mam ale nie chciałbym siedzieć nad tym nie potrzebnie)

[lenin]

[mały doublepost]

znalazłem takie coś gmc.yoyogames

I tam gościu zrobił testy na dużych i małych tilesach i wychodzi na to, że jednak lepiej lecieć na większych

I have just conducted a small benchmark that draws many 16x16 tiles to fill the screen, and few 64x64 tiles. With small tiles 350fps, with large tiles 800fps. This is a 2048x2048 room, drawing views at 640x480. Conducting the same test with the viewport at 320x240 shows minimal difference in performance, with 700fps using large tiles and 320fps using small tiles.

 

From this I would conclude that yes, using larger tiles does reduce the drain on performance, however game maker does not seem to stop tiles from drawing outside the viewport.

 

I hope this helps :) (The test: http://prntscr.com/1qg7qx)

 

Chyba jednak zostanę przy większych tilesach i nie będę kombinował:)

[Ignatus]

Od wczoraj przechodzę z GM jakąś paranoję, mam nadzieje że to nie bug z którym nic się nie da zrobić.

 

Sprawa wygląda następująco.Mam plansze wyboru mapy w grze.Poszczególne ikonki z numerami map.Żeby wybrać mapę klikamy na nią- wtedy pojawia się w tym miejscu obiekt z efektem specjalnym (latające wokół ikonki koło)- kiedy ikona jest w ten sposób zaznaczona ponowne kliknięcie w tą oznacza wybór mapy i przejscie do danej mapy.Wszystko działa pięknie i tak jak sobie to zaplanowałem ALE pojawia się jakiś totalnie paranoiczny motyw- możliwe jest dowolne przejście podświetlenia (np.oznaczony mamy room1 i naciskamy na room2 i wtedy obiekt z efektem znika z 1 i pojawia się na 2)- tylko że z niewiadomym przyczyn nie mogłem przejść z 1 na 2 i z 3 na 4 (w drugą stronę bez problemu czyli np z 4 na 3)- i tylko w tych przypadkach tak się dzieje- pozostałe kilkadziesiąt map bez problemu.Podjąłem kilka prób rozwiązania problemu, przy czym nawet skopiowanie innego obiektu i tylko zmiana numeru obiektu danej mapy do której się odnosi nic nie dawało.W końcu rozwiązenie okazało się dziwaczne- zmiany nazwy map 2 i 4 pomogła.Wszystkie mapy są oznaczone "O_L_1" itd - wszystkie tak samo tylko z innym numerem , ale przy 2 i 4 robił się problem.Myślałem że wszystko jest dobrze-bo działało ok.Wyłączyłem GM uruchomiłem kilka godzin później ponownie i co się okazuje- znów ten sam błąd- ale na innych mapach - i tym razem zmiana nazwy nie pomaga.Nic nie zmieniałem a przestało działać........O co chodzi??

 

 

edit.jeszcze dodatkowo te obiekty które są "wadliwe" robią się niewidzialne jeżeli ich nie skasuje i nie umieszczę ponownie po każdej zmianie nazwy

Problem zawsze dotyczy przejściu do obiektu następnego w kolejności..

 

 

edit.rozwiazane- problem polegal na tym ze byl warunek okreslajacy ze obiekt "Select" musial byc na tej samej pozycji co obiekt "O_L_numer" i z nieznanych mi powodow nigdy nie zajmowal tej pozycji przy okreslonych numerach- nadal tego nie rozumiem ale po usunieciu "place_meeting" wszystko dziala jak powinno

[Wojzax]

Mam pytanie takie:

W mojej grze są solidy które dodaję do grida jako przeszkody. Dodaje je w stepie bohatera za pomocą:

GML

if(instance_exists(box1))then

{

mp_grid_add_instances(grid, box1, false);

}

Jest fajnie ale te solidy są ruchome.

Kiedy strzelam do pudełek to się przesuwają i psują się, a w pewnym momencie znikają.

Wraz z nimi przesuwa się ten czerwony obszar i nie mam pojęcia jak go usunąć kiedy już nie koliduje z boxem.

 

Myślę że coś powinienem zrobić z mp_grid_clear_cell, ale jak sprawdzać te kolizje? A może jakoś inaczej zapisać ten kod ze stepa?

Macie może pomysły?

[lenin]

najprościej (niekoniecznie najlepiej) przy niszczeniu skrzyni czyść wszystkie komórki i ponownie dodaj przeszkody

[Wojzax]

No przecież :o dzięki

[Wojzax]

OK, mam taki kod:

GML

if(item=1)then

{

draw_sprite_ext(hud_item1,-1,x,y,1,1,0,c_white,0.8)

}

 

mimo że item=1 dla tego obiektu, rysuje się zamiast sprite'a hud_item1 jakiś większy różowy półprzezroczysty kwadrat :(

czemu tak

 

@EDIT:

ok, ten różowy kwadrat to taki jeden inny sprite, ale ma zupełnie inną nazwę, wie ktoś dlaczego się rysuje akurat ten sprite, skoro nie jest związany nijak z rzeczonym obiektem?

[I am vader]

Nie jestem pewien czy użycie "-1" w argumencie klatki jest dozwolone.

Jeżeli ustawienie tego na 0 lub image_index (jakkolwiek Ci trzeba) nic nie daje, to upewnij sie ze faktycznie ta czesc kodu jest wykonywana, np. show_message lub show_debug_message

[Wojzax]

Zmiana na 0 nie naprawiła problemu.

ustanowiłem nową zmienną która zmienia się z 0 na 1 kiedy ta część kodu jest wykonywana.

W debuggerze jest napisane że zmieniła się ona na 1, więc teoretycznie kod się wykonał, ale wciąż rysuje nie ten sprite który powinien.

 

#EDIT:

Pomogła dopiero zmiana nazwy sprite'a z hud_item1 na hud_itemz

nie wiem jak ale gra łączyła nazwę hud_item1 z nazwą sprite'a enemy_safezone_s

 

:( nie mam pojęcia jak to się działo

 

#EDIT:

ok, znalazłem błąd, był prozaiczny - nazwałem tak samo obiekt w którym wykonywałem to i sprite'a. Pewnie wtedy gm wariuje.