Wypuszczona jakiś czas temu biblioteka as3crypto pozwala na szyfrowanie tekstu. Z wysyłaniem danych do php jest jednak parę problemów – funkcje w as3crypto przeważnie nie wyrzucają danych które mcrypt w php mógł dobrze odkodować.
Bardzo źle jednak nie jest… udało mi się skłonić do współpracy as3crypto i php ze sobą przy zastosowaniu standardów szyfrowania DES i Blowfish w trybie CBC:
Znalazłem jeszcze kodowanie AES i udostępnione do niego pliki(php, air i flex) na goole code.
Kolizje w grach to ważna sprawa. Często są to dość żrące CPU algorytmy i w co większych grach trzeba zastosować mechanizm ograniczenia ilości badany obiektów. Zanim zaczniemy jednak sortować czy grupować obiekty – trzeba się zastanowić czy warto…
Dla małej ilość elementów algorytm „brute force” jest bardzo efektywny. Nieskomplikowany, polegający na tym że bada się kolizje każdego z każdym.
for(i = 0; i < n; i++) {
a = obj[i]; for(j = i +1; j < n; j++) { b = obj[j];
checkCollision(a,b) } }
Problem jednak powstaje przy większej ilości obiektów dla których kolizje musimy sprawdzić. Ilość wywołań metody checkCollision() dla n liczby obiektów rośnie dość szybko O((n2-n)/2). Brute force zaczyna tak obciążać procesor że fps odczuwalnie spada. Trzeba poszukać rozwiązania… a tych wcale nie jest mało…
Spatial Hashing
Chyba najprostsza metoda grupowania obiektów. Na obszar gry „nakładamy” siatkę i zapamiętujemy referencję do obiektu w każdej komórce siatki nad którą obiekt się znajduje.
Jest trochę problemów z optymalnym dopasowaniem wielkości komórki, ale zysk i tak będzie spory. Badamy kolizje tylko tych obiektów które znajdują się w tych samych komórkach.
Test dla 500 obiektów i porównanie z algorytmem brute force:
The Flash plugin is required to view this object.
Dobra – źle nie jest… ale i tak nie czułem pełni satysfakcji po napisaniu… otóż Michaela Baczynski na potrzeby silnika motor2 napisał quadtree – też algorytm do grupowania obiektów. I cholera… jego jest szybszy… i to dużo.
Nie jestem tak dobry jak myślałem… Tylko że do zwykłych gier quadtree średnio się nadaje. Ma tą wadę iż dla obiektu będącego na środku i tak musimy zbadać kolizje z wszystkimi innymi obiektami – a gry robię tak że postać (dla której badam kolizje) przeważnie jest na środku. Czyli tak średnio…
No nić pozostaje mi tylko zoptymalizowanie silnika „spatial hashing”… bo przecież szybszy być musi…
Skorzystałem do budowy struktury danych udostępnione przez Michaela Baczynskiego. Zresztą test też jest jego pomysłu.