🚀 go-pugleaf

> > proste prawda? :)
>
> He, he - wcale nie :) Tu zaczyna się dopiero mój problem. Nie wiem bowiem
> jak najwygodniej jest sterować dużą ilością obiektów na scenie. Np. pauza:
> proste a za razem trudne wyzwanie. Przypuszczam, że musiałbym założyć
jakiś
> obiekt, w którym każdy graficzny obiekt mógłby zapamiętać swój stan. Do
tego
> musiałbym stworzyć jakiś model zdarzeń i np. puścić broadcasta "wszystko
> stop". Ja to potrafię zrobić lecz potem może sie okazać, ża AS jest tak
> wolny, że musiałbym używać nowego komputera  TASKu, żeby zagrać w Tetrisa.

kolega moze z PG? ;))

> > a jak projektowac???? to temat rzeka ;) na kursie flash mx 2004 na
> > flashroom.com staramy sie pokazac jak projektowac "male" fragmenty
> > programow, czyli klasy... zajrzyj tam i sprobuj sie przylaczyc, ale
> > ostrzegam, to co bylo omawiane na kursie flasha mx musisz miec w malym
> > paluszku ;)
>
> Zerknę sobie na to z pewnością. Nie wiem czemu temat jest "rzeką" bo
wydaje
> mi się, że jeśli zdecydujemy się na jakiś model to potem możemy stosować
go
> w każdym typie gry. Czyż nie jest tak ? Problem w tym, że taki model
> narzucony jest funkcjonalnością języka. Np. aby wykonać hitTest() danego
> obiektu to muszę co klatkę w pętli sprawdzać czy nie koliduje on z innymi
i
> robić to dla każdego z nich (!!!)

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 ;))

> zamiast zlecić to "enginowi". Mając to na
> uwadze boję się, że zginę tak postępując. Niemniej jednak to narzuca mi
> model aplikacji propagujący zdarzenia "w górę". Czyli MC przesyła
zdarzenie
> "zderzyłem się" do nadrzędnego MC itd. Taka struktura programu jest
właśnie
> przykładową odpowiedzią na moje pytanie.

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...

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 ;)

--
pozdr.
Paweł Piotrzkowski