Tweaki

[Fervi_]

Witam.

 

Nie wiem czy jest taki zbiór tweaków i przydatnych porad. Jak nie to ja zacznę :P

 

Gry na strony internetowe powinny być jak najlżejsze. Oczywiście z GMem nie da się XD, ale można odchudzić je troszkę.

W mojej grze jest kilkadziesiąt spriteów w dość wysokiej jakości. Może się je zmniejszy w GM (W Global Game Settings -> HTML5 -> Graphics -> Textures Page można ustawić maksymalny rozmiar spriteów), ale to inna kwestia

 

Używając programu optipng z parametrem -o9 (ogólnie program zaleca o7) można przerobić sprite'y po zHTML5owaniu na jeszcze lżejsze bez utraty jakości (w tym formacie są przechowywane nasze spirte'y). Oszczędności w moim wypadku wyniosły 2MB. Oczywiście gra dalej jest ciężka, ale 2MB też zmienia sporo.

 

Kompresja plików HTML5

Kompresja aplikacji binarnych (Linux)

Weryfikacja pliku po ściągnięciu w Midori

 

 

Fervi

[Threef]

Hmm... Zmienianie metody kompresji grafik PNG które masz w projekcie nie ma najmniejszej szansy pomóc zmniejszyć rozmiar plików. O tym raczej wiesz, ale wytłumaczę innym bo ty tego nie zrobiłeś.

 

Przy tworzeniu pliku wyjściowego gry GM:S tworzy w asset cache atlasy (texture pages). Silnik korzysta z atlasów w grze i to je trzeba by skompresować. Skompresowanie grafik przed tym jak GM:S umieści je na atlasie nie ma sensu, bo GM:S użyje potem innych argumentów dla kompresji. I nie pamiętam już ale jest to możliwe chyba tylko dla HTML5 bo po kompilacji dostajemy zip w którym assety są w środku.

 

Rozumiem że zależy ci na optymalizacji rozmiaru gry? Nie na wydajności?

Wśród innych pomysłów jest to że możesz dołożyć grafiki już po uruchomieniu gry poprzez sprite_add(). Ten jako argument pliku przyjmuje także URL. Dzięki temu możesz pobrać zasoby graficzne po tym jak już gra się odpali.

[Fervi_]

Hmm... Zmienianie metody kompresji grafik PNG które masz w projekcie nie ma najmniejszej szansy pomóc zmniejszyć rozmiar plików. O tym raczej wiesz, ale wytłumaczę innym bo ty tego nie zrobiłeś.

 

Przy tworzeniu pliku wyjściowego gry GM:S tworzy w asset cache atlasy (texture pages). Silnik korzysta z atlasów w grze i to je trzeba by skompresować. Skompresowanie grafik przed tym jak GM:S umieści je na atlasie nie ma sensu, bo GM:S użyje potem innych argumentów dla kompresji. I nie pamiętam już ale jest to możliwe chyba tylko dla HTML5 bo po kompilacji dostajemy zip w którym assety są w środku.

 

Rozumiem że zależy ci na optymalizacji rozmiaru gry? Nie na wydajności?

Wśród innych pomysłów jest to że możesz dołożyć grafiki już po uruchomieniu gry poprzez sprite_add(). Ten jako argument pliku przyjmuje także URL. Dzięki temu możesz pobrać zasoby graficzne po tym jak już gra się odpali.

 

Kompresujesz po tym, nie przed.

 

Game Maker (HTML5) tworzy z twoich grafik "wielkie palety" (2048x2048, czyli pewnie ten texture pages) w formacie png. Prawdopodobnie w kodzie Javascriptu jest zapisane skąd ma je brać (w sensie jak podzielić to z powrotem).

Ogólnie manipulujesz plikiem wyjściowym.

 

Wydaje mi się, że to może tylko przyspieszyć, bo:

- Pobierasz mniejsze pliki (oszczędność)

- Ładujesz mniejsze do pamięci (oszczędność pamięci)

- Procesor raczej jest na tyle szybki (może nawet procesor graficzny), że podzielenie tego nawet jak go spowalnia, to nie na tyle, by "odzyskać ten czas"

 

Fervi

[Ranmus]

Pamięci na tym nie oszczędzisz, bo grafika i tak zostanie zdekompresowana z jakiegokolwiek formatu do wersji "raw". Jedynym plusem jest oszczędność czasu podczas pliku.

[gnysek]

czy to PNG czy JPG, w ramie i tak będzie to BMP+alpha (4 bity na piksel).

[Fervi_]

Pamięci na tym nie oszczędzisz, bo grafika i tak zostanie zdekompresowana z jakiegokolwiek formatu do wersji "raw". Jedynym plusem jest oszczędność czasu podczas pliku.

 

Lekka Lipa, ale i tak taniej i szybciej jest wysłać zoptipngnizowane pliki, parę MB zawsze do przodu, klient oszczędza parę MB, serwer szybciej kończy sesję, bla bla ...

 

Więc można robić :P

 

Fervi

[Fervi_]

Część binarek można skompresować np. UPX. Nie działa to na Windowsie (te binarki są kompresowane wcześniej przez GM), więc nawet jak da się coś oszczędzić, to parę KB.

 

Linuksową binarkę można ładnie skroić - oczywiście zalecam tutaj przy wydawaniu końcowej wersji to robić niż przy testach wewnętrznych.

 

5,5M thehero

1,6M thehero-light

1,2M thehero-max

 

Oryginalnie - 5.5MB udało się w wersji "szybkiej" zmniejszyć do 1.6MB, a w wersji "wolnej" do 1.2MB. Oczywiście te "wersje" moje to po prostu system algorytmów, które są testowane.

 

Jeśli chcecie wersję "light" to

upx -9 <plik>

 

Jeśli wersję "max" to

upx --ultra-brute <plik>

 

Prawdopodobnie wersja dla gejów (Apl) też daje się kompresować.

 

Jak to działa? UPX ogarnia odpowiedni algorytm, scala go z małym programem i tworzy jeden plik. Jak odpalamy grę, to ten mały programik rozpakowuje całą zawartość (do pamięci) i odpala grę.

 

Fervi

[Fervi_]

Zwykle pobrany plik jest właściwy (prawidłowy), ale czy można w razie nieprawidłowości zmusić przeglądarkę do sprawdzenia czy plik jest zgodny z sumą kontrolną?

 

W zasadzie nie. Dlatego ten przepis jest mało popularny, ale warto zastosować dla świętego spokoju xd

 

Jedna przeglądarka na jakiej zadziałał to Midori xd Popularność bliska zeru

 

<link>#!sha1!<suma sha1>

 

Samo Midori daje taki link:

http://midori-browser.org/downloads/midori...95c9462d99e3035

 

Po pobraniu pliku następuje weryfikacja sumy kontrolnej. Jeśli się zgadza - jest ok, jeśli nie - program wyświetli trójkąt, który po naciśnięciu zgłasza uszkodzenie pliku.

Oczywiście - niszowa przeglądarka, mało kto z niej korzysta, więc nie ma sensu. Ale dla Was to strata z minuty czasu. Dla innych - nic nie znacząca funkcja

 

Fervi