🚀 go-pugleaf

> kolega moze z PG? ;))

Tak, a widać to ? :))))
Jestem absolwentem PG od 10 lat :D

> no i tu pojawia sie kwestia doswiadczenia, o ktorej wspomnial Lukasz...
> nie robisz tak jak napisales, tylko tworzysz jeden pusty MC, definiujesz
mu
> funkcje onEF, a w tej funkcji przechodzisz w petli po wszystkich MC, ktore
> maja sie zderzyc z jakims innym... takie rozwiazanie jest o wiele bardziej
> wydajne niz definiowanie kilkudziesieciu onEF... (aby sie o tym przekonac,
> mozesz zerknac na zadanie nr 000 na kursie flasha mx
> (www.flashroom.com/forum/)... tam Tencin dal bardzo ciekawe zadanie, ktore
> okazalo sie jednak zbyt trudne na poczatek dla kursantow ;))
>
> mozesz sprobowac je sobie napisac... zareczam, ze jezeli zrobisz je Twoja
> metoda, to zabijesz procesor (w kazdym razie moj Athalon 1,73GHz polegl
;))

No właśnie o tym mówię :) Dlatego mój post jest teraz na tej grupie...
A tak na marginesienie sądzę, aby Twoja metoda była mniej obciążająca procek
ponieważ i tak musisz co ramkę sprawdzać kolizje "każdy z każdym". Jeżeli
masz 10 obiektów to musisz dokonać 100 sprawdzeń.

> hmm... bardziej poprawna forma bylby jakis manadzer zarzadzajacy gra, w
> ktorej sterowalbys "przeplywem" informacji miedzy obiektami... w ten
sposob
> moglbys uniknac problemu o jakim wspomnialem wczesniej... to sprawdza sie
> rowniez w innych przypadkach...

Tak właśnie zrobiłem. Każdy obiekt generuje zdarzenia, które wędrują do
rodzica i w konsekwencji do centrali :) Gdy rodzic nie obsługuje zdarzenie
idzie wyżej. Itd.

> poza tym... to co napisal Lukasz konczy chyba temat ;) zeby pisac
poprawnie
> jakiekolwiek aplikacje we Flashu potrzeba sporego doswiadczenia, a to jak
> pewnie wiesz zdobywa sie... empirycznie ;) a nie z ksiazek czy usenetu ;)

Wiem. Jednakże teoria jest też bardzo ważna - jest to nawet klucz bez
którego zdobywanie doświadczenia zajmie Ci 10x tyle czasu. Chyba kupię jakąś
książkę o pisaniu gier...