podzielenie gry oraz... przyszłość game makera

[krzemo]

Witajcie! Dawno mnie tu nie było :)

 

Tworzę już od pewnego czasu pokaźniejszą (relatywnie do tego co tworzyłem wcześniej xd) gierę i chciałbym podzielić ją na części, żeby wszystkie pliki nie ładowały się od razu tylko w momencie zaistnienia takiej potrzeby. Najlepiej jakby potrzebne pliki ładowały się co poziom (planuję ich 15).

 

ładowanie wszystkiego na początku nie będzie raczej trwać zbyt długo, bowiem już teraz mam 5 poziomów i jakoś specjalnie długo loading nie trwa, jednakże chciałem zrobić poważniejszy remont gry, tzn przenieść ją ze świata 1024*768 na 1920*1080 i w związku z tym powiększyć wszystkie grafiki...

 

..i cóż... em... jak podzielić te pliki?

 

a teraz druga sprawa która pośrednio łączy się z pierwszą: rozważałem kupno game maker pro ale wchodze na stronę yoyogames a tam w sklepie jest już tylko game maker studio... czy mam się przesiąść na niego? Czy game maker 8.1 stał się abandonware?

[Threef]

Rozwiązanie drugiego bardzo Cię ucieszy:

1. Ściągnij GameMaker:Studio
2. Odpal i zaktualizuj
3. Wpisz email w okienku powitalnym
4. Sprawdź email
5. ???
6. Profit! Ciesz się aktywną wersją standard GM:S która za darmo ma wszystko co GM8.1 Pro + sporo nowych rzeczy jak to co przyda się w rozwiązaniu pierwszego problemu.

 

Więc z grafikami jest fajna sprawa w GM:S. Jest coś takiego jak texture pages. Są to spakowane razem grafiki. W wersji GM:S Pro możesz samemu kontrolować co na jakim texture page ma być, ale nawet jak nie masz do tego dostępu to wciąż zainteresuje Cię funkcja draw_texture_flush();. Ona najnormalniej wywala z pamięci wszystkie grafiki, a te które gra teraz używa są od nowa wczytywane.

Używa się tego na początku room (jako loading?) i dzięki temu jeżeli jakaś grafika nie pojawia się na tym room to nie zajmuje ona już RAM. Tylko niech nie przyjdzie Ci do głowy wyżywanie tego w Step! Wtedy osiągniesz odwrotny efekt bo grafiki będą musiały co step się od nowa wczytywać!

[krzemo]

Ciesz się aktywną wersją standard GM:S która za darmo ma wszystko co GM8.1 Pro + sporo nowych rzeczy jak to co przyda się w rozwiązaniu pierwszego problemu.

 

 

:OOOO nieźle... NATYCHMIAST POBIERAM

 

czy są jakieś haczyki? Np znak wodny w darmowej wersji?

 

inna sprawa: funkcja flush brzmi bardzo interesująco, jednakże jedno mnie zastanawia: skoro na początku gra i tak ładuje na ram wszystkie grafiki to jest jakikolwiek sens je potem flushować?

 

...a da się flushować obiekty? Ja tworzę coś na kształt FPSów - tylko w 2D, także każdy poziom zawiera ogrom obiektów.... chociaż wielkiego bólu i tak nie ma, mam te swoje 5 poziomów i tragedii nie ma podczas ładowania...

 

sporo się zmieniło w świecie GM...

 

Dzięki za odpowiedź :)

[Threef]

Ach jest haczyk, zapomniałem. Jest logo GM przy włączaniu gry chyba. Ale w porównaniu do tego co było w GM8.1 gdzie był znak wodny i ograniczone funkcje to jest nie do przebicia. Żebyś nie pytał to (prawie) wszystkie funkcje są odblokowane, a nie będą Ci oczywiście działać te od reklam albo analityki.

 

GM:S nie wczytuje wszystkiego na początku. Wczytuje tylko to co potrzebuje, ale właśnie nie usuwa tego co już nie potrzebne. Dlatego trzeba robić flush.

 

O ilość obiektów się nie martw, najgorzej jest z rysowaniem sprite. Jeżeli robić instance_deactivate() to nie powinieneś mieć problemów.

[krzemo]

Jest logo GM przy włączaniu gry chyba. Ale w porównaniu do tego co było w GM8.1 gdzie był znak wodny i ograniczone funkcje to jest nie do przebicia.

 

;p no dokładnie. Jeżeli cała gra jest "twoja" i tylko jakieś logo pojawia się na początku to to nie problem...

 

najgorzej jest z rysowaniem sprite. Jeżeli robić instance_deactivate() to nie powinieneś mieć problemów.

 

hmm nie używałem tego... zacznę..

 

dobra, dzięki za info. Jestem pozytywnie zaskoczony :o

 

..słuchaj, to teraz mam pytanie "konsumenckie": czy zagrałbyś w grę w której kontrolowana przez ciebie postać strzela tylko przed siebie?

Taką grę robię z kilku powodów: 1) w GM dla noobów niedostępna była dla mnie funkcja obracania spritem więc odpadał system nadawania kierunku lotu pocisku myszą 2) kiedy ręce są tylko na klawiaturze, można lepiej skupić się na dynamice gry - tzn strafeach przed pociskami i strzelaniu we wroga (i naturalnie, skoro możesz strzelać tylko w przód to wrogowie też byli tylko przed tobą) 3) takich gier gdzie celujesz myszą chyba jest sporo a tak to moja by się wyróżniała ;0

[MaxGaming]

zainteresuje Cię funkcja draw_texture_flush();. Ona najnormalniej wywala z pamięci wszystkie grafiki, a te które gra teraz używa są od nowa wczytywane.

Używa się tego na początku room (jako loading?) i dzięki temu jeżeli jakaś grafika nie pojawia się na tym room to nie zajmuje ona już RAM. Tylko niech nie przyjdzie Ci do głowy wyżywanie tego w Step! Wtedy osiągniesz odwrotny efekt bo grafiki będą musiały co step się od nowa wczytywać!

Zaciekawiłeś mnie tym, bo nawet nie wiedziałem o takiej funkcji(ja wciąż działam głównie na patentach z 8.1 mimo, że używam od dłuższego czasu już GMS :P). W każdym razie, skoro grafiki są zapisywane jako całe texture pages to wczytuje z nich do ramu poszczególne, potrzebne fragmenty(pojedyńcze sprite'y) czy po prosu potrzebne texture page'e, w których jakieś potrzebne grafiki się znajdują? I drugie pytanie to jak ta funkcja czyszcząca ram działa z grafikami czytanymi z dysku. Rozumiem, że po tej funkcji trzeba samodzielnie wczytywać od nowa z dysku wszystkie grafiki, bo te też się usuwają? I nie pomoże ona w żaden sposób przy grafikach wczytywanych z dysku(z dysku mam namyśli z jakiegoś dołączonego pliku, a nie z biniarki)?

[Threef]

Każda grafika wczytana z dysku to nowy texture page. Więc wczytując samemu grafiki z dysku robi się dużą głupotę.

Nie wiem tylko jakiego rozmiaru są one. Boję się że te texture pages są standardowej wielkości. Więc jak mamy w projekcie ustawione 2048x2048 to wczytując grafikę która ma 32x32 reszta jest pusta ale wciąż zajęta.

 

Ciekawi mnie teraz co by było gdyby wczytywać grafiki, zapisywać je na surface (czyli w pamięci graficznej) i rysować surface zamiast tego.

 

Może ktoś chciałby porobić testy wydajnościowe?

[MaxGaming]

Każda grafika wczytana z dysku to nowy texture page. Więc wczytując samemu grafiki z dysku robi się dużą głupotę.

Nie wiem tylko jakiego rozmiaru są one. Boję się że te texture pages są standardowej wielkości. Więc jak mamy w projekcie ustawione 2048x2048 to wczytując grafikę która ma 32x32 reszta jest pusta ale wciąż zajęta.

 

Ciekawi mnie teraz co by było gdyby wczytywać grafiki, zapisywać je na surface (czyli w pamięci graficznej) i rysować surface zamiast tego.

 

Może ktoś chciałby porobić testy wydajnościowe?

No dobrze, ale jeżeli chce, żeby grafiki mogły być zamieniane bez rekompilacji biniarki, a co ważniejsze bez posiadania w ogóle projektu to wczytywanie z dysku niektórych grafik jest mi niezbędne. Co do rozmiaru texture page'y to nie sądzę by była narzuca ona co do grafik z dysku, bo byłoby to okropne rozwiązanie. Oczywiście postaram się zrobić jaknajwięcej grafik w jednym pliku dla pewności, ale nie sądzę.

[gnysek]

Ciekawi mnie teraz co by było gdyby wczytywać grafiki, zapisywać je na surface (czyli w pamięci graficznej) i rysować surface zamiast tego.

 

Surface jest kasowany przez kartę graficzną gdy potrzebuje pamięci, więc za godzinę, minutę a może nawet sekundę możesz go nie mieć. Na pewno wygaszacz ekranu, przelogowanie, blokada telefonu go skasują, ale czasem dzieje się to randomowo. Przed uzywaniem surface_set_target ZAWSZE powinno się robić if !surface_exists(){<create_surface>}

[Threef]

Surface jest kasowany przez kartę graficzną gdy potrzebuje pamięci, więc za godzinę, minutę a może nawet sekundę możesz go nie mieć. Na pewno wygaszacz ekranu, przelogowanie, blokada telefonu go skasują, ale czasem dzieje się to randomowo. Przed uzywaniem surface_set_target ZAWSZE powinno się robić if !surface_exists(){<create_surface>}

 

Tak, dobrze wiemy o tym. Ale ciekawe jakie efekty miałoby właśnie pobieranie grafik z dysku i trzymanie ich tylko w surface.

[I am Lord]

Czy ten flush czyści także sprity stworzone podczas działania gry? Wygenerowane sprity? Jak tak to słabo, można ustalić jakieś wyjątki?

[Threef]

On wywala je z RAM. Te które są utworzone jako zasoby wciąż zostają gdzie były.

[I am Lord]

No i dlatego wygenerowanych nijak już przywrócisz gdy nagle flush je wyczyści bo żaden obiekt go nie używał. Chyba że przed flushem je zapiszesz na dysk.

[MaxGaming]

No i dlatego wygenerowanych nijak już przywrócisz gdy nagle flush je wyczyści bo żaden obiekt go nie używał. Chyba że przed flushem je zapiszesz na dysk.

No właśnie zależy jak rozumiemy dodać do zasobów. Jeżeli tak, że dodanie sprite funkcją w czasie gry to dodanie do zasobów to ok, gorzej jeżeli tak jak Lord piszę już nie przywrócimy. Swoją drogą, gdy dodajemy sprite funkcją w czasie gry, to on jest jakoś dorysowywany do texture page, czy jak to wygląda?

[I am Lord]

Jest umieszczany nieoptymalnie na osobnej texture page.

[MaxGaming]

Jest umieszczany nieoptymalnie na osobnej texture page.

Ale to pewniak? W takim razie jeżeli stworzę sprite i podmienie go w czasie gry na taki z dysku, ale sprite już istniał to co wtedy?

[Threef]

Też będzie na osobnym. Szansa na to że YYG zrobiło coś takiego że nowa grafika będzie wskakiwała w miejsce starej na texture page, jest nijaka. Poza tym niektóre atlasy (tak to się nazywa btw!) mogą mieć dorysowane do sprite trochę kolorków na krawędziach.

 

Ogółem skoro już jesteśmy przy takich technicznych sprawach. Na tech blogu YYG jest opisane żeby nie skalować view. Zamiast tego skalować application_surface. To bardzo dobry tip. ;)