16.02.2013 13:28
[#1]
AMOS - pytanie do programistów
Czołem zapaleni programiści :)
Dziś pytanie do tych spod znaku AMOS-a.
Problem: Detekcja kolizji obiektu z elementami tła
Pomysł: Oprócz tła przygotowana maska w kolorze białym i zero.
Maskę wczytuję jako Sprite/Bob i dokonuję detekcji kolizji.
Wynik i problemy:
a) sprite/bob musi być widoczny zatem słabo to wygląda i mruga
b) mocno obciąża cały system i gra zwalnia niemiłosiernie...
a) i b) pewnie dlatego, że obiekt jest zdecydowanie za duży dla blittera :/ (320x256) - aż strach myśleć co byłoby w Hires...
Kto ma inny pomysł na detekcję kolizji? Raczej odpada tworzenie stref, ponieważ tło jest nierówne (vide Area51) i opisanie każdego korytarza strefami byłoby nieco męczące :)
Ktoś się mierzył z czymś takim?
Dziś pytanie do tych spod znaku AMOS-a.
Problem: Detekcja kolizji obiektu z elementami tła
Pomysł: Oprócz tła przygotowana maska w kolorze białym i zero.
Maskę wczytuję jako Sprite/Bob i dokonuję detekcji kolizji.
Wynik i problemy:
a) sprite/bob musi być widoczny zatem słabo to wygląda i mruga
b) mocno obciąża cały system i gra zwalnia niemiłosiernie...
a) i b) pewnie dlatego, że obiekt jest zdecydowanie za duży dla blittera :/ (320x256) - aż strach myśleć co byłoby w Hires...
Kto ma inny pomysł na detekcję kolizji? Raczej odpada tworzenie stref, ponieważ tło jest nierówne (vide Area51) i opisanie każdego korytarza strefami byłoby nieco męczące :)
Ktoś się mierzył z czymś takim?
16.02.2013 18:03
[#3]
Re: AMOS - pytanie do programistów
@WojT_GL, post #1
-> Problem: Detekcja kolizji obiektu z elementami tła
W AMOSie jest tylko:
- strefy
- obiekt-obiekt (blitter)
- hardware, ale tylko sprite'y
- inne programowe metody (multum możliwości)
-> Maskę wczytuję jako Sprite/Bob i dokonuję detekcji kolizji.
Bez sensu. Bob ma zawsze maskę tworzoną automatycznie, można też użyć Make Mask lub No Mask. W tym przypadku tło musiałoby być bobem, a maska będzie stworzona automatycznie. Bob będzie widoczny, bo tło musi zostać i tak odrysowane.
Pewnikiem i tak będziesz musiał stworzyć pomocniczy programik do tworzenia tablic kolizji w zależności od mapy poziomu.
W AMOSie jest tylko:
- strefy
- obiekt-obiekt (blitter)
- hardware, ale tylko sprite'y
- inne programowe metody (multum możliwości)
-> Maskę wczytuję jako Sprite/Bob i dokonuję detekcji kolizji.
Bez sensu. Bob ma zawsze maskę tworzoną automatycznie, można też użyć Make Mask lub No Mask. W tym przypadku tło musiałoby być bobem, a maska będzie stworzona automatycznie. Bob będzie widoczny, bo tło musi zostać i tak odrysowane.
Pewnikiem i tak będziesz musiał stworzyć pomocniczy programik do tworzenia tablic kolizji w zależności od mapy poziomu.
16.02.2013 19:09
[#4]
Re: AMOS - pytanie do programistów
@cholok, post #3
Jestem przeciwny wszelakim dodatkowym softom ;) wykombinuje zatem polaczenie pomyslu Benka i swojego. Czyli przygotowanie opisu obszaru do latania na podstawie maski wczytywane dynamicznie. I detekcja kolizji przy pomocy wlasnego algorytmu sprawdzajacego czy jestesmy w obszarze - tu bedzie lekki problem bo sam latajacy obiekt to bob ktory ma nieregularny ksztalt ;)
Inne zagadnienie - ktos uzywal get bob do zrobienia boba animowanego poprzez amaliwa funkcje anim? Obecnie wczytuje dynamicznie z pliku iff boby i animuje samemu podmieniajac boby ale czy nie da sie lepiej?
Moze lamerskie pytania, ale amos to nie c i nie java ;) calkiem inne podejscie i trzeba sie przestawic na ciut inne myslenie i rozwiazania ;)
Inne zagadnienie - ktos uzywal get bob do zrobienia boba animowanego poprzez amaliwa funkcje anim? Obecnie wczytuje dynamicznie z pliku iff boby i animuje samemu podmieniajac boby ale czy nie da sie lepiej?
Moze lamerskie pytania, ale amos to nie c i nie java ;) calkiem inne podejscie i trzeba sie przestawic na ciut inne myslenie i rozwiazania ;)
16.02.2013 19:33
[#5]
Re: AMOS - pytanie do programistów
@WojT_GL, post #4
Kombinujesz na około.
Zrób se tablice dwuwymiarową.
Podziel ja jakoś sensownie. Np komórka odpowiada jednemu, dwom czy dziesięciu pikselom.
Ustalasz, że 1 to sciany 0 to przestrzeń a 2 to samolocik.
if a(x,y)=1 then goto krash
gdzie a to aktualna pozycja samolocikuj a x,y to miejsce w tablicy.
Masz system kolizji oraz rozplanowanie planszy :)
Benedykt Dziubałtowski
Zrób se tablice dwuwymiarową.
Podziel ja jakoś sensownie. Np komórka odpowiada jednemu, dwom czy dziesięciu pikselom.
Ustalasz, że 1 to sciany 0 to przestrzeń a 2 to samolocik.
if a(x,y)=1 then goto krash
gdzie a to aktualna pozycja samolocikuj a x,y to miejsce w tablicy.
Masz system kolizji oraz rozplanowanie planszy :)
Benedykt Dziubałtowski
16.02.2013 20:09
[#7]
Re: AMOS - pytanie do programistów
@Benedykt Dziubałtowski, post #5
Benek po pierwsze goto to zuuuuuuo.
Po drugie samolocik to nie jeden piksel ;) na hotspot tez nie mozna reagowac. Samolot jest nieregularny dlatego tak fajne jest dobrodziejstwo bob col ;)
Kazda gra musi miec inbe algorytmy ;) w szalterze moglo byc prost bo sciany byly proste - tu sie tak nie da ;)
Po drugie samolocik to nie jeden piksel ;) na hotspot tez nie mozna reagowac. Samolot jest nieregularny dlatego tak fajne jest dobrodziejstwo bob col ;)
Kazda gra musi miec inbe algorytmy ;) w szalterze moglo byc prost bo sciany byly proste - tu sie tak nie da ;)
16.02.2013 20:55
[#9]
Re: AMOS - pytanie do programistów
@Benedykt Dziubałtowski, post #8
Rozumiem :)
Troche spedzilem czasu na programowaniu, algorytmice i tym podobnych i wiem czym jest wyznaczanie i opisywanie obszarow a takze sprawdzanie czy punkt znajduje sie w zadanym obszarze.
Ale:
1) samolot to nie punkt, tylko ksztalt, a zatem detekcja czy nadal miesci sie w dozwolonym obszarze nie moze sie odbywac na podstawie jednego piksela a calego obrysu samolotu - wiec do sprawdzenia jest mnostwo pikseli (bo moze sie zdarzyc tak, ze ktos wjedzie obrysem samolocika na obrys tla ale jeszcze nie bedziemy mieli spelnionego warunku dla punktu ktory chcesz sprawdzac (pozycja samolotu) - i wtedy gracz przezyje)
2) opisywanie scian przy pomocy 2wymiarowej tablicy to marnotrawstwo pamieci (proponujesz 0 jako brak sciany i 1 jako sciane) - zatem przy 320x256 mamy 80kB na same 0 i 1 (Amos nie ma malych typow) - opisywanie scian co 2 piksele - zmniejsza nam tablice do 20kB - to tez zdecydowanie za duzo jak na obrys :)
3) aby uniknac problemu 2 nalezaloby wykorzystac opis obszaru wspolrzednymi - tak jak opisywane sa obszary w plikach KML ktore wykorzystujemy na przyklad w mapach google do obrysowania obszaru - i to sie bardzo dobrze sprawdzi - wystarczy kilkadziesiat/kilkaset wspolrzednych i obszar jest dosc dokladnie opisany - a kilkaset bajtow a 20-80kB to roznica :)
4) do 3) mozna wykorzystac algorytm Shuterlanda (http://en.wikipedia.org/wiki/Point_in_polygon) ale to nadal jest dla punktu, zatem trzeba by go zmodyfikowac tak aby detekcja odbywala sie dla obszaru (nakreslonego przez ksztalt samolocika) - tak jak proponuja to tutaj (zmodyfikowanie sledzenie promieni) - http://gamedev.stackexchange.com/questions/7735/how-to-find-if-circle-and-concave-polygon-intersect. Przy czym tu jest prosciej bo jest okrag ;)
Oczywiscie mozna isc na uproszczenia, i przyjac ze ksztalt samolociku opisany jest prostokatem, owalem lub od biedy piecio/szesciokatem (aby jak najbardziej przyblizyc ksztalt docelowy) - ale kazde takie uproszczenie bedzie sie odbijac na grywalnosci - bo w jednym miejscu samolot rozbije sie przed sciana a w innym kilka pikseli pozniej.
Tak jak wspominalem - detekcja kolizji dla bobow/spriteow jest bardzo fajnie zrobiona w Amosie i az prosi sie ja wykorzystac - tylko ze wystepuja wspomniane problemy. (ostatecznie mozna pociac maske kolizyjna na mniejsze boby, zawierajace tylko krawedzie kolizji i poukladac je na sciezce, ale to zmniejsza ilosc dostepnych pozniej bobow dla samych elementow gry).
Ciagle wierze ze jest w Amoise/AMALu jakas funkcja ktora pozwala na detekcje kolizji z tlem :) W przeciwnym przypadku przyjdzie sie zmierzyc z ciekawym zagadnieniem (ciekawe jak amos sobie wydajnosciowo z tym poradzi).
Moze z innej beczki - ktos widzial napisana w Amosie gre, w ktorej wystepowalby samolot/obiekt latajacy w tunelu i reagujacy na zderzenia (np. cos w stylu R-Type, Scramble)? A moze tego sie po prostu nie da tak zrobic ? (raczej w to watpie :p)
Troche spedzilem czasu na programowaniu, algorytmice i tym podobnych i wiem czym jest wyznaczanie i opisywanie obszarow a takze sprawdzanie czy punkt znajduje sie w zadanym obszarze.
Ale:
1) samolot to nie punkt, tylko ksztalt, a zatem detekcja czy nadal miesci sie w dozwolonym obszarze nie moze sie odbywac na podstawie jednego piksela a calego obrysu samolotu - wiec do sprawdzenia jest mnostwo pikseli (bo moze sie zdarzyc tak, ze ktos wjedzie obrysem samolocika na obrys tla ale jeszcze nie bedziemy mieli spelnionego warunku dla punktu ktory chcesz sprawdzac (pozycja samolotu) - i wtedy gracz przezyje)
2) opisywanie scian przy pomocy 2wymiarowej tablicy to marnotrawstwo pamieci (proponujesz 0 jako brak sciany i 1 jako sciane) - zatem przy 320x256 mamy 80kB na same 0 i 1 (Amos nie ma malych typow) - opisywanie scian co 2 piksele - zmniejsza nam tablice do 20kB - to tez zdecydowanie za duzo jak na obrys :)
3) aby uniknac problemu 2 nalezaloby wykorzystac opis obszaru wspolrzednymi - tak jak opisywane sa obszary w plikach KML ktore wykorzystujemy na przyklad w mapach google do obrysowania obszaru - i to sie bardzo dobrze sprawdzi - wystarczy kilkadziesiat/kilkaset wspolrzednych i obszar jest dosc dokladnie opisany - a kilkaset bajtow a 20-80kB to roznica :)
4) do 3) mozna wykorzystac algorytm Shuterlanda (http://en.wikipedia.org/wiki/Point_in_polygon) ale to nadal jest dla punktu, zatem trzeba by go zmodyfikowac tak aby detekcja odbywala sie dla obszaru (nakreslonego przez ksztalt samolocika) - tak jak proponuja to tutaj (zmodyfikowanie sledzenie promieni) - http://gamedev.stackexchange.com/questions/7735/how-to-find-if-circle-and-concave-polygon-intersect. Przy czym tu jest prosciej bo jest okrag ;)
Oczywiscie mozna isc na uproszczenia, i przyjac ze ksztalt samolociku opisany jest prostokatem, owalem lub od biedy piecio/szesciokatem (aby jak najbardziej przyblizyc ksztalt docelowy) - ale kazde takie uproszczenie bedzie sie odbijac na grywalnosci - bo w jednym miejscu samolot rozbije sie przed sciana a w innym kilka pikseli pozniej.
Tak jak wspominalem - detekcja kolizji dla bobow/spriteow jest bardzo fajnie zrobiona w Amosie i az prosi sie ja wykorzystac - tylko ze wystepuja wspomniane problemy. (ostatecznie mozna pociac maske kolizyjna na mniejsze boby, zawierajace tylko krawedzie kolizji i poukladac je na sciezce, ale to zmniejsza ilosc dostepnych pozniej bobow dla samych elementow gry).
Ciagle wierze ze jest w Amoise/AMALu jakas funkcja ktora pozwala na detekcje kolizji z tlem :) W przeciwnym przypadku przyjdzie sie zmierzyc z ciekawym zagadnieniem (ciekawe jak amos sobie wydajnosciowo z tym poradzi).
Moze z innej beczki - ktos widzial napisana w Amosie gre, w ktorej wystepowalby samolot/obiekt latajacy w tunelu i reagujacy na zderzenia (np. cos w stylu R-Type, Scramble)? A moze tego sie po prostu nie da tak zrobic ? (raczej w to watpie :p)
16.02.2013 22:24
[wyróżniony]
[#15]
Re: AMOS - pytanie do programistów
@WojT_GL, post #9
A nie można użyć kilku punktów określających przybliżony kształt samolotu?
Da radę zrobić tak, aby maska była kreślona tylko w pobliżu samolotu, np maska podzielona na kilka mniejszych bobów i w zależności od współrzędnych samolotu, samolot zbliżający się do prawej krawędzi boba powodowałby, że pojawiałby się drugi bob po prawej stronie jako maska (w ten sposób można by ograniczyć ilość bobów do wyznaczania maski do 2) ?
Da radę zrobić tak, aby maska była kreślona tylko w pobliżu samolotu, np maska podzielona na kilka mniejszych bobów i w zależności od współrzędnych samolotu, samolot zbliżający się do prawej krawędzi boba powodowałby, że pojawiałby się drugi bob po prawej stronie jako maska (w ten sposób można by ograniczyć ilość bobów do wyznaczania maski do 2) ?
16.02.2013 23:56
[#16]
Re: AMOS - pytanie do programistów
@jokov, post #14
właśnie szukam :) i nie moge znalezc.
Wszystkie przyklady pokazuja kolizje bob/bob sprite/sprite bob/sprite.
Brak wlasnie takiego o jakim wspominam - przegladam tez tutaj: http://www.amigacoding.com/index.php/AMOS:CreatedWithAMOS ale bez screenow ciezko wyczaic czy gra ma taki tryb jak poszukiwany :)
Wszystkie przyklady pokazuja kolizje bob/bob sprite/sprite bob/sprite.
Brak wlasnie takiego o jakim wspominam - przegladam tez tutaj: http://www.amigacoding.com/index.php/AMOS:CreatedWithAMOS ale bez screenow ciezko wyczaic czy gra ma taki tryb jak poszukiwany :)
17.02.2013 00:00
[#17]
Re: AMOS - pytanie do programistów
@rafgc, post #15
Hmmm to bardzo dobry pomysł w sumie.
Łącząc to z moim pomysłem, aby określić ścieżkę kolizji przy pomocy współrzędnych i wycinać fragment maski do którego zbliża się pojazd a następnie zamieniać go w boba i sprawdzać kolizję powinno zadziałać....
...ale jak zwykle pojawia się nowy problem :)
Jak odczytać ze screena, obrazka kolor pixela :)
Pomysł - wczytanie obrazka (iff) do pamięci, przeskanowanie go pod względem kolorów i na granicy czarny/biały utworzenie ścieżki kolizji w tablicy (jako współrzędne).
Problem - brak funkcji pobierającej kolor pixela o podanych współrzędnych z bitmapy :)
Łącząc to z moim pomysłem, aby określić ścieżkę kolizji przy pomocy współrzędnych i wycinać fragment maski do którego zbliża się pojazd a następnie zamieniać go w boba i sprawdzać kolizję powinno zadziałać....
...ale jak zwykle pojawia się nowy problem :)
Jak odczytać ze screena, obrazka kolor pixela :)
Pomysł - wczytanie obrazka (iff) do pamięci, przeskanowanie go pod względem kolorów i na granicy czarny/biały utworzenie ścieżki kolizji w tablicy (jako współrzędne).
Problem - brak funkcji pobierającej kolor pixela o podanych współrzędnych z bitmapy :)
17.02.2013 00:12
[wyróżniony]
[#18]
Re: AMOS - pytanie do programistów
@WojT_GL, post #17
W amosie jest funkcja pobierająca kolor pixela - nie pamiętam jej nazwy ale istnienie jej jest pewne ;)
Generalnie otwierasz ekran ładujesz obrazek i robisz sobie tablicę ze ścieżką kolizji. Ekran zamykasz a tablica zostaje. Wyjściem jest też ustawienie bobów na ekranie i ewentualne ich przesuwanie i wtedy detekcja kolizji bob vs bob. Nie musisz mieć boba wielkości ekranu, ale kilka mniejszych. Pamietaj w Amosie do jednego kanału możesz przypisać kilka bobów.
Generalnie otwierasz ekran ładujesz obrazek i robisz sobie tablicę ze ścieżką kolizji. Ekran zamykasz a tablica zostaje. Wyjściem jest też ustawienie bobów na ekranie i ewentualne ich przesuwanie i wtedy detekcja kolizji bob vs bob. Nie musisz mieć boba wielkości ekranu, ale kilka mniejszych. Pamietaj w Amosie do jednego kanału możesz przypisać kilka bobów.
17.02.2013 11:37
[#22]
Re: AMOS - pytanie do programistów
@rafgc, post #15
Poprawka, ilość bobów do użycia w danym rozwiązaniu to 4, bo samolot mógłby przecież znajdować się w punkcie w którym łączą się 4 kształty. Myślę, że jeżeli można wycinać maskę z jakiegoś predefiniowanego obrazka, to można by użyć jednego boba, który byłby aktualizowany (przesuwane wycięcie maski) gdy pojazd zbliża się do krawędzi aktualnej maski (odczytanie pozycji samolotu, użycie go do wyznaczenia środka wycięcia nowej maski, aktualizacja - porównałbym tę metodę do światła latarki, które przesuwa się na środek obiektu, gdy ten zbliży się do krawędzi), pytanie brzmi czy taki algorytm nie będzie nic spowalniał?
Ostatnia aktualizacja: 17.02.2013 11:39:04 przez rafgc
Ostatnia aktualizacja: 17.02.2013 11:39:04 przez rafgc
09.03.2013 09:31
[#23]
Re: AMOS - pytanie do programistów
@rafgc, post #22
Witam, odblokowali mnie, wiec male info dla zainteresowanych tym jak rozwiazalem problem.
Zgodnie z informacjami uzyskanymi na roznych forach zagranicznych Amos nie ma mozliwosci detekcji kolizji z tlem - jest to mozliwe na poziomie sprzetowym, ale nie zaimplementowane w Amosie :)
Po kilku moich probach implementacji (wycielismy z tla kolor czarny i sprawdzalem czy caly czas poruszam sie po czarnym) dotarlem do zrodel gry Planet Zybex, gdzie jest rowniez wykonana podobna detekcja kolizji - podejrzalem tam i rozwiazanie przyszlo samo :)
Leon przygotowal mapy tla tak, aby zawieraly jeden kolor ktory uzywam do detekcji kolizji. Ten kolor nie jest wykorzystywany nigdzie indziej w zadnej grafice. Leon obrysowal tym kolorem jaskinie (nawet tego nie widac) a ja analizuje czy mam ten kolor w odpowiednim miejscu - jesli tak, to mamy zderzenie). Dziala swietnie...
Postepy nad tematem sa :)
Zgodnie z informacjami uzyskanymi na roznych forach zagranicznych Amos nie ma mozliwosci detekcji kolizji z tlem - jest to mozliwe na poziomie sprzetowym, ale nie zaimplementowane w Amosie :)
Po kilku moich probach implementacji (wycielismy z tla kolor czarny i sprawdzalem czy caly czas poruszam sie po czarnym) dotarlem do zrodel gry Planet Zybex, gdzie jest rowniez wykonana podobna detekcja kolizji - podejrzalem tam i rozwiazanie przyszlo samo :)
Leon przygotowal mapy tla tak, aby zawieraly jeden kolor ktory uzywam do detekcji kolizji. Ten kolor nie jest wykorzystywany nigdzie indziej w zadnej grafice. Leon obrysowal tym kolorem jaskinie (nawet tego nie widac) a ja analizuje czy mam ten kolor w odpowiednim miejscu - jesli tak, to mamy zderzenie). Dziala swietnie...
Postepy nad tematem sa :)
09.03.2013 17:28
[#25]
Re: AMOS - pytanie do programistów
@WojT_GL, post #23
Miło, że są jacyś fajni programiści AMOSowi na forum. Rozumiem, że używasz takiego "blue boxa", czyli unikalnego koloru. Fajnie, że rozwiązałeś problem. Sam sobie w końcu zainstalowałem AMOSa i jestem bardzo zadowolony, język legenda, nadal urzeka ładną szatą graficzną i prostotą użytkowania. Życzę powodzenia w dokończeniu swojego projektu 
