przykladowy max uproszczony: plansza, potworki, fanty (interkacja z tlem lub skarby), bohater:
1. generowanie planszy (grafika i atrybuty) w buforze1, 2. kopiowanie bufora1 do bufora2 3. aktualizacja stanu potworkow 4. aktualizacja stanu bohatera 5. rysowanie bohatera w buforze2 6. rysowanie potworkow w buforze2 7. aktualizacja stanu fantow 8. rysowanie fantow w buforze2 9. aktualizacja planszy (grafika i atrybuty) w buforze1 10. kopiowanie bufora2 na ekran 11. goto 2
wyjasnienie atrybutow: kolizje z tlem oraz fantami odbywa sie na podstawie zapisow w pamieci atrybutow.
jakie sa Wasze algorytmy. jak sprawdzacie kolizje, jaka organizacja ekranu (znakowy/graficzny) itp. wady/zalety...
xxl podałeś uproszczony algorytm samej wizualizacji gry. Pytasz o konkretną realizację sprawdzania kolizji z tłem i potworkami na A8 czy ogólnie o algorytm platformera, który na maluchu działałby sensownie? ---- ---- - - P.S. warunkowe 9.goto 1 : wprowadzi możliwość modyfikacji realitme planszy :) (otwarcie/zamknięcie obszaru, zapadnięcie obszaru itd).
1. Czyszczenie ekran1 2. Przesunięcie planszy zależnie od stanu joysticka (zmiana aktualnej pozycji) 3. Rysowanie planszy na ekran1 4. Aktualizacja stanu obiektów + kolizje + rysowanie wszystkiego co jest obecnie widoczne na ekran1 5. przełączenie obrazu na ekran1 6. Czyszczenie ekran2 7. Przesunięcie planszy zależnie od stanu joysticka (zmiana aktualnej pozycji) 8. Rysowanie planszy na ekran2 9. Aktualizacja stanu obiektów + kolizje + rysowanie wszystkiego co jest obecnie widoczne na ekran2 10. przełączenie obrazu na ekran2 11. goto 1
Kolizje to coś takiego: for i=5 to 0 for ii=3 to 0 if (abs(i[x]-ii[x])<= ZAKRESX) && (abs(i[y]-ii[y])<=ZAKRESY) then ...
gdzie "i" to np. indeks przeciwników a "ii' to indeks strzałów
xxl robisz sobie mapę poziomu w tablicy dwuwymiarowej, gdzie np 0 to powietrze, 1 ziemia/murek, 2 drzwi. Sprawdzasz na ktorym kwadracie jest postać i ktory kierunek jest przyciśnięty. Sprawdzasz odpowiednią kolizję, w sensie np jeśli w prawo to sprawdzasz czy nie ma ściany/ziemi z prawej. Czyli sprawdzasz, czy pod daną x,y nie istnieje przeszkoda uniemożliwiająca ruch. Grawitacja (bo przecież można spaść) - gdzie podczas lotu sprawdzasz x,y pod graczem.
To tak baaardzo ogólnie i z grubsza i w ogóle, na sieci jest trochę stuffu zwanego "platform game engine", dla Ciebie nie powinno to być nic trudnego zaimplementować i każdy post podobny mojemu to jest marnowanie miejsca i czasu Twojego na czytanie ;)
A co do implementacji w A8 asm nie wypowiadam się, bo się nie znam kompletnie.
W Ryśku - jak wiesz - mam detekcję kolizji opartą na wykrywaniu części wspólnej pomiędzy prostokątami otaczającymi obiekty. Nie ma potrzeby realizowania tego dokładniej. Zabiło by to wydajność, gdyby chcieć to zrobić "pixel-perfect".
Detekcja kolizji z tłem (murki, platformy) jest w niektórych przypadkach upierdliwa. Gdy prędkość spadania/skoku przekracza wysokość platformy (8 pikseli) w celu wykrycia kolizji należałoby dokonać testu przecięcia dwóch linii. Przy założeniu, że prędkość nie będzie większa niż 8, można to uprościć. Możemy mieć jednoczesny ruch w poziomie i pionie...
Organizacja ekranu - poprzeplatane wiersze 2 zestawów znaków na zmianę. Liniowy bufor obrazu. Kody znaków nieuszeregowane liniowo w buforze, a umieszczone na podstawie definicji z mapy.
Procedura skoku/spadania dała mi w kość swego czasu. Ponieważ animacja skoku posiada opóźnienie i przyspieszenie zaczynają się pojawiać wartości niebędące popularnymi krotnościami :) I teraz mamy test na walnięcie głową w sufit(przy wznoszeniu) a potem, przy opadaniu test noga-gleba. To dwie procedury do jednego skoku, wywoływane w zależności od stanu (czy postać się wznosi, czy też opada). Wiele razy postać utknęła mi głową w suficie albo kolanami w platformie. No więc tutaj zacząłem skrupulatnie badać przed kolejną wizualizacją pozycji gdzie współrzędne wypadną. Jeśli wypadały w suficie/w glebie zaokrąglałem do najbliższej wartości która dawała bezpieczną pozycję. A potem wizualizacja. Możliwe, że da się to zrobić prościej a ja zagmatwałem. Niemniej było to skutecznie i podczas działania postać podczas skoku waliła głową w sufit (limit górny) i nie leciała dalej, a podczas opadania zawsze stawała na glebie tak jak trzeba (limit dolny). Oczywiście można zmieniać wektor ruchu podczas skoku i opadania, co generuje kolejne "nietypowe" wartości x,y z którymi trzeba sobie poradzić.
@TheFender; @Konop: mam podobne zdanie co do pamieci atrybutow - dobry pomysl, ma swoje ograniczenia ale tez ma tyle zalet ze jest po prostu nieodzowny. kolizje z tlem i fantami najszybciej realizowac taka metoda, to sa najczesciej nieruchome obiekty, grafika nie musi wypelniac calej "powierzchni" jaka zajmuje atrybut.
@shanti77: kolizje na wspolrzednych. indeksy tez powinny moim zdaniem miec zakresy - przyklad: w tablicy pociskow masz zapisan pociski przeciwnikow i swoje - czy pociski przeciwnikow powinny wywolywac kolizje z innymi przeciwnikami a pociski twoje z bohaterem? - ogolnie taka metode zaobserwowalem chociazby w asteroids - jest szybka. obraz dwu buforowy to jest genialne (bardzo szybkie) przy pewnych zalozeniach - ograniczeniam jest np. obraz gry nie mozna dowolnie mapowac na ekran... ale ogolnie swietny pomysl - na razie nie aktualizuje bo musze sprawdzic :D
jeszcze nie teraz. nie przetestowane kolizje no i dwubuforowanie a to moze sporo zmienic... to trwa ale na pewno ten watek bedzie mial ciag dalszy. chce zaprojektowac "szablon" na ktorym moznaby w miare szybko pisac gierki :)
- pamiec atrybutow jest zupelnie niezalezna od grafiki, tak, ze jeden kafelek moze miec zupelnie rozne atrybuty w zaleznosi od kontekstu. - 256 kafelkow rozmiaru 8x8 - kolizje na atrybutach uzaleznione od klatki animacji (o wiele dokladniejsze - zdawac by sie moglo, do 2pikseli) - brakuje tu jeszcze wieluuu elementow, ale beda demonstrowane przetestowane i prawidlowo dzialajace.
Pomyśl o drugiej warstwie tileset'ów, z makroblokami MxN (np. 2x2, 4x4) nad zestawem 8x8/4x8. Taki sposób kodowania znacznie oszczędza pamięć na definicję mapy. W Rick'u dzięki takiemu zabiegowi oszczędzamy 50% pamięci przy makroblokach 4x4.
:)media markt nie dla...;) albo uderz w stół . za "moich czasów" mało by się znalazło atarowców, którzy by wzięli cię jakimś cudem za kodera.Więc wyluzuj :) napisz coś konkretnego i nie sraj żarem...przepraszam za wyrażenie..nie słowa a czyny a najlepiej jakies XeX'y albo AtR'y ..XXl jest koderem i to dobrym ,niestety nie chce demka zrobić, trudno :)Atari Blast rulez!!
wow! xxl dałeś czadu :) No i to jakże piękne założenie "przeszedłem mario w lewo" róls.
To, że xxl jest dobrym koderem wszyscy wiemy nie od dzisiaj. Fajnie, że się wziął za konkretną i dosyć ambitną rzecz. A robienie demek zostawmy całej reszcie ;) --------- ------ ---- --- - - Efekt, kiedy giniesz jest bezcenny :D Na game over będzie noga z fusitu?
@Konop: w tym momencie skarby sa oddzielna wartstwa tilesow (no ale tez rozmiar 8x8) zastanawiam sie nad wprowadzeniem warstwy tilesow z najwyzszym priorytetem - moglyby zaslaniac np. bohatera - oczywiscie wastwa z interakcja - na filmiku tego nie ma do skarbu typu "klucz" moznaby podpiac program modyfikujacy wastwe tilesow oraz atrybutow - to by bylo ciekawe.
@XXL, bardzo to zgrabne, jako fan runnerów kibicuję całym sercem. Ale mnie też ciekawi czemu w lewo? :) Wiesz, fakt że 99% gier jednokierunkowych ma zwrot akcji w prawo to nie przypadek tylko efekt naszej psychiki i cywilizacji. Podobno większość ludzi intuicyjnie wiąże upływ czasu, a więc i postęp akcji z takim kierunkiem. Dla runnerów to ma szczególne znaczenie. Czyli jeśli nie ma to jakiegoś sensownego zakotwiczenia w fabule, to ryzykujesz, że gracze będą czuli niepokój czy mieli podświadome poczucie, że "coś tu nie gra". Innymi słowy: ryzykujesz, że gra dostanie niższe noty niż dostałaby taka sama gra, ale ze zwrotem w prawo. Dlatego jestem ciekaw skąd taki zabieg?
jesli ruch w prawo wiekszosc ludzi wiaze z uplywem czasu to ruch w lewo beda wiazac z powrot do czasow dziecinstwa a wiec gra bedzie wywolywac nostalgie.
a jesli chodzi o niepokoj... to gracz go odczuje na bardzo krotko, juz po kilku sekundach bedzie to zupelnie inne odczucie - nie bez powodu masz do dyspozycji 1 milion zyc.
ad a) gdzie pole gry jest większe o 1 kafelek. ad b) wykresy w szkole podstawowej są rysowane w prawo nawet domyślnie rzędne i odcięte rysuje się jako osie dodatnie w cywilizacjach europejskich pisze się z lewej do prawej prawe oko uważa się za dominujące (błąd) i nawet przy celowaniu celuje się prawym okiem menu start jest po lewej i wszystko co się dzieje na pulpicie dzieje się na prawo od niego po angielsku right znaczy właściwie po polsku prawy znaczy nieskazitelnie dobry prawo i sprawiedliwość
@xxl - faktycznie nie wyraziłem się zbyt precyzyjnie, się tam na technikaliach nie znam, ale chodzi o taki scroll jak Mario idzie w prawo tylko że w lewo ;)
@nosty - najwyraźniej xxl celuje w rynki dalekowschodnie - tam np. czytanie od prawej do lewej jest normalne ;)
Kilka pytań: - czy jest to na znakach ze zmianą fontów, czy to czysty tryb graficzny? - jako wygląda możliwość przeniesienia na inną rozdzielczość (kolorową)? - ile to by mogło obsłużyć ruchomych obiektów? Mam na myśli potworki + pociski? - jak wygląda kwestia kolizji? Czy można mieć na nią wpływ? Standardowo zmniejsza się rozmiar kolizji z przeszkadzajkami a zwiększa z dobrymi przedmiotami jak na przykład monety. - czy engine może wspierać scroll / plansze większe niż 1 ekran?
1. w tym momencie tryb graficzny co pozwala zrobic pixel mono 1x2, kolor 2x1 itd. nie ma zadnego probblemu zeby w buforze funkcjonowal tryb graficzny kopiowany na fonty i tak wyswietlane. co wiecej, nasz bufor moze byc szerokosci 32 bajty a ekran 40. ja wybralem technike obrazu dwubuforowego dlatego zdecydowalem sie na tryb graficzny.
2. zaden problem - zmiana trybu antica
3. to "zalezy" ;-) od wielkosci ekranu, jaka metode umieszczania spritow - eor, z maska and/ora, kasowania spritow (niektorzy zachowuja tlo sprita i pozniej go przywracaja a niektorzy kopiuja caly bufor z obrazem tla na ktory nakladaja obiekty). obecnie 5-16x16 i 8-8x8 ale to bylo przy kopiownaiu buforow, przy obrazie dwubuforowym nie wiem, ale musialem robic synchronizacje z VBI bo zdazalo sie ze wyswietlany bufor byl zamazwany (czyli silnik dziala szybciej niz 1xramke). wedlug mnie akceptowana szybkosc to 2 ramki.
4. tak. kolizje z fantami realizowane sa na atrybutach i faktycznie sa malo rygorystyczne :-) to samo zrobilem z kolizjami tla - kolizje analizowalem na podstawie JSW - na szczescie napisalem inne gdzie brana jest pod uwage rowniez faza ruchu. proponuje porownac to co jest w JSW a tu. kolizje z potworkami na wspolrzednych lub pixel perfect (kopiujesz potworka i jak cos przykrywa to kolizja) - ograniczenie takie ze musisz miec typy potworkow ktore sa rysowane na odpowiednim tle ;-) dlatego wole wspolrzedne.
5. tu mam zagwozdke. wczesniej juz pisalem - jaki scroll? mozna miec scroll w okienku (niektore gry na zx spectrum tak maja) albo caly obraz z wycieta kolumna po prawej i lewej (soft scroll) albo sprzetowy z ekranem wiekszym o 1 kafelek lub cala mapa w pamieci. mam co prawda juz dwie wersje scrolla HV - z kafelkiem 8x8 oraz 16x16 jednak nie testowane :/ moze wcale nie dziala :D
Ja bym proponował skorzystać, z triku który eliminuje potrzebę wykorzystywania podwójnego buforowania (opisał to kiedyś w swoim artykule Fox w jednym z pierwszych numerów Atarynki):
Wyeliminowanie podwójnego buforowania oszczędza pamięć oraz bardzo przyspiesza bo np. kopiowanie bufora itp. jest bardzo czasochłonne (coś wiedzą o tym Commodore'owcy ;)
Czyli z tego:
xxl:
1. generowanie planszy (grafika i atrybuty) w buforze1, 2. kopiowanie bufora1 do bufora2 3. aktualizacja stanu potworkow 4. aktualizacja stanu bohatera 5. rysowanie bohatera w buforze2 6. rysowanie potworkow w buforze2 7. aktualizacja stanu fantow 8. rysowanie fantow w buforze2 9. aktualizacja planszy (grafika i atrybuty) w buforze1 10. kopiowanie bufora2 na ekran 11. goto 2
...usuwamy niepotrzebne punkty i mamy:
1. generowanie planszy (grafika i atrybuty) w buforze1, 2. aktualizacja stanu potworkow 3. aktualizacja stanu bohatera 4. aktualizacja stanu fantow 5. goto 2
W Twoim przykładzie gry na YT trik ten wyjątkowo fajnie i łatwo można zastosować, bo np. Fox w żadnym demie (czy grze) nie miał tak dużej swobody jak Ty w tej grze.
Zyski są proste: - uproszczenie całego algorytmu - przyspieszenie przez wyeliminowanie np. odrysowywania obiektów na obu buforach (bo mogą pozostać śmieci) - przyspieszenie poprzez wyeliminowanie kopiowania buforów , co jest tak bardzo czasochłonne jak duży jest bufor (najczęściej na cały ekran!) (czyli zmora Commodore'a :P) - oszczędność pamięci - co jest szczególnie cenne na 8-bit
Ja ten trik wykorzystuję we wszystkich grach (również tych, które napisałem w latach 80. np. w Matematyce (Mirage), Moontek, Bomb Jack itp.). Ostatnio zacząłem wykorzystywać podwójne buforowanie w moich strzelankach (ale to z innej przyczyny; wzrost wydajności osiągam w inny sposób) np. w At Arion Line II (jeszcze nie ukończona gra, ale można ją zobaczyć na wykładzie p.t Nowe tryby graficzne Atari na YT).
jesli odnosisz sie do pierwszego posta to dobrze myslisz. pierwszy post nie zostal zaktualizowany o realizacje obrazu dwubuforowego - rowniez filmik to wersja silnika bez obrazu dwubuforowego. przy kolejnym filmiku obejmujacy wszystkie opisywane zmiany zaktualizuje pierwszy post.
@maly_swd, kopiowanie jest potrzebne w podwójnym buforowaniu o ile wymaga to dana gra. Rozwiązania: Przykładowo wszystkie potrzebne zmiany można robić wraz z odrysowaniem wszystkich postaci/obiektów w grze tzn. mogą oni rysować więcej niż same postacie. Co prawda samo w sobie jest to już optymalizacją wyświetlania/animowania, jednak wymaga odrysowywania wszystkich postaci na każdy bufor. Innym przypadkiem jest gdy trzeba odrysować całość lub sporą część tła, np. podczas scrollingu, czyli przepisujemy całość wraz z przesunięciem (tak jak w scrollu na C=).
U XXLa nie ma scorlla, więc tu można jedynie narysować całość podczas wejścia do danej lokalizacji. Sprawę psują poruszające się postacie, które muszą odrysować to co zasłaniały, jednak nie jest to tak kłopotliwe w tym przypadku (na razie) bo tu nie ma postaci które by się poruszały z prędkością kilku znaków. Poruszanie z prędkością kilku znaków powodowałoby potrzebę odrysowania tła za postacią w adekwatnej wielkości i to na wszystkich buforach.
