Autor Wątek: Poziom w grze typu scrolling shooter np.River Ride  (Przeczytany 2379 razy)

Offline beermaster

  • Użytkownik

# Styczeń 03, 2013, 18:28:42
Witam. W jaki sposób przechowywać dane poziomu takie jak np w grze River Raid. Samolot leci wewnątrz kanionu , kolizja ze ścianą. Jak najszybciej sprawdzać kolizje i przechowywać dane poziomu żeby zajmował jak najmniej pamięci bez użycia jakiś specjalnych bibliotek itp.
Czy może być poziom zapamietany w postaci bitmapy dwukolorowej czy w jakiś inny lepszy sposób ?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline maro

  • Użytkownik

# Styczeń 03, 2013, 18:56:27
Podejrzewam, że w czasach riverraida nie trzymało się takich rzeczy w bitmapach - ta gra wgrywała się niecałe 3 minuty na atari. :) Obstawiam, że brzeg był wyznaczony przez współrzędne prostych, i na tej podstawie sprawdzane były kolizje.

Offline Kos

  • Użytkownik
    • kos.gd

# Styczeń 03, 2013, 19:13:10
Kafelkiii

Offline kubx

  • Użytkownik
    • Kanał YT

# Styczeń 03, 2013, 19:30:11
Oto jak była tworzona mapa w River Raid na Atari 2600
Cytuj
The river is divided into sections which are generated by random. The random
number generator can generate 57337 different sections. Each section is
divided into 16 blocks. The last block is the bridge. For each other block a
random Id is generated, which defines the shape of the river. The river is
randomly generated with or without islands.
Each block is 32 lines high and is divided into two parts. Those parts are
neccessary for the bridge only, because it is smaller than a whole block.

All objects are also randomly generated. There is one object in each block.
First the game randomly selects if a fuel tank, an enemy object (ship, plane
or helicopter) or a house should be generated. Then a starting x-position is
defined and finally the direction (left/right) of the object is set.
The ships and helicopters start patroling also randomly.

Obraz na Atari2600 jest generowany linia po linii , gdzie rejestry są kontrolowane bezpośrednio przez procesor (mamy 76 cykli procesora, aby narysować linię).
Kolizje sprawdzane są automatycznie - pomiędzy graczem (Player1 i Player2), a mapą (Playfield), pociskami (Bullet1, Bullet2) oraz kulą (Ball, konsola była projektowana z myślą o tworzeniu popularnych wtedy gier jak Pong). Wystarczy odczytać odpowiedni rejestr.
« Ostatnia zmiana: Styczeń 03, 2013, 19:31:42 wysłana przez kubx »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 03, 2013, 19:38:32
[Disclaimer: Post powyżej mnie wyprzedził, ale i tak wysyłam bo nie do końca się pokrywają]


Cytuj
Podejrzewam, że w czasach riverraida nie trzymało się takich rzeczy w bitmapach - ta gra wgrywała się niecałe 3 minuty na atari. :)
Zależy o jakim Atari mówisz. :) W oryginalnej wersji ta gra mieściła się w 4k ROM w kartridżu i nie musiała się wgrywać.

Cytuj
Czy może być poziom zapamietany w postaci bitmapy dwukolorowej czy w jakiś inny lepszy sposób ?
Jeżeli interesuje Cię jak to było zrobione oryginalnie na Atari 2600, to polecam poczytać okomentowane źródła tutaj: http://www.qotile.net/minidig/ :)

Generalnie rzeka składała się z fragmentów, które były generowane losowo podczas rysowania, bo sprzęt miał 128 bajtów RAM (a do tego nie miał bufora ramki - rzeczy trzeba było rysować na bieżąco z ruchem promienia). Grafika samych fragmentów była zapisana gotowa w ROM.

Co do kolizji, to niestety nie będziesz zadowolony - wówczas były sprzętowe bo tak było prosto i dość tanio. :)

Cytuj
Obstawiam, że brzeg był wyznaczony przez współrzędne prostych, i na tej podstawie sprawdzane były kolizje.
Nie na A2600 na pewno, a na XL/XE też nie sądzę. Procesory 65xx nie miały dzielenia ani mnożenia. Co do kolizji: patrz wyżej (dotyczy to też XL/XE oraz C64). :)


EDIT: kubx: piszesz coś na A2600? :)

Offline kubx

  • Użytkownik
    • Kanał YT

# Styczeń 03, 2013, 19:45:31
EDIT: kubx: piszesz coś na A2600? :)

Ostatnio pochłonął mnie temat starych konsol. Mam już na koncie emulator 6502, który następnie wykorzystałem do stworzenia emulatora NESa (działa znośnie, ale nie mam czasu implementować całego sprzętu) i ostatnio właśnie Atari 2600. Chciałem stworzyć emulator i przeportować go na ARMa (konkretnie STM32, pewien konkurs), jednak trzeba emulować konsolę co do cyklu, bo tak wtedy tworzono gry, a ja nie byłem w stanie napisać odpowiednio wydajnego kodu (na PC 3.0GHz program uzywał 100% cpu nie osiągając pełnej prędkości emulacji). Można odpalić kilka gier, ale większość ficzerów jest niezaimplementowana (np. właśnie kolizje).

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 03, 2013, 20:26:47
Cytuj
Chciałem stworzyć emulator i przeportować go na ARMa (konkretnie STM32, pewien konkurs)
A liczyłeś w ogóle na czym stoisz? :) Przy 48MHz ARMie, masz niecałe 12 cykli na color clock - no way man. :)

Znacznie lepszym rozwiązaniem było by FPGA. :)

Offline kubx

  • Użytkownik
    • Kanał YT

# Styczeń 03, 2013, 20:33:47
A liczyłeś w ogóle na czym stoisz? :) Przy 48MHz ARMie, masz niecałe 12 cykli na color clock - no way man. :)

Znacznie lepszym rozwiązaniem było by FPGA. :)
Celem było stworzenie emulatora, aby pokazać, że się da. Pomijając co drugą klatkę i taktując procesor 100MHz myślę, że projekt by działał (może nawet być te kilka fps). Skończyło się na tym, że napisałem emulator Chip-8 dzień przed deadline :)

FPGA - chętnie, niestety obecnie brak pieniędzy na takie zabawki, a symulacja logiki mnie nie rajcuje.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 03, 2013, 21:03:57
Cytuj
Celem było stworzenie emulatora, aby pokazać, że się da. Pomijając co drugą klatkę i taktując procesor 100MHz myślę, że projekt by działał (może nawet być te kilka fps). Skończyło się na tym, że napisałem emulator Chip-8 dzień przed deadline :)
Bez kolizji to może i tak - przecież nie pominiesz klatki ot tak sobie, bo aplikacja i tak ją przeliczy.

Offline beermaster

  • Użytkownik

# Styczeń 03, 2013, 21:29:34
Hmmm  , grając kiedyś na C64 w River Raid wydawało mi się że gra wygląda zawsze tak samo, nie przypuszczałem że plansza jest generowana losowo .... chociaż tyle czasu już minęło ,hmmmm

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 03, 2013, 21:37:53
Hmmm  , grając kiedyś na C64 w River Raid wydawało mi się że gra wygląda zawsze tak samo, nie przypuszczałem że plansza jest generowana losowo .... chociaż tyle czasu już minęło ,hmmmm
OK, źle to ująłem - plansza jest generowana z użyciem generatora liczb losowych, ale inicjalizowanego zawsze tym samym seedem.

Offline beermaster

  • Użytkownik

# Styczeń 03, 2013, 21:47:27
Czyli to można by napisać to tak aby generował się poziom "na bieżąco" według określonych parametrów , plansza sie przesuwa , generuje się nowa "linia" , ostatnia jest kasowana. W parametrach określałoby sie np. max szerokości kanionu , częstotliwosc występowania wysp itp.

Offline Dab

  • Redaktor
    • blog

# Styczeń 03, 2013, 22:03:53
W grach gdzie jest stała kamera i ruch w jednym kierunku najlepiej sprawdzi się właśnie coś w rodzaju cyklicznego bufora - generujesz na bieżąco nowe otoczenie/wrogów/przedmioty/whatever, a kiedy znikają za ekranem to je usuwasz/nadpisujesz nowymi.

Offline Vipa

  • Redaktor

# Styczeń 07, 2013, 12:29:13
W grach gdzie jest stała kamera i ruch w jednym kierunku najlepiej sprawdzi się właśnie coś w rodzaju cyklicznego bufora - generujesz na bieżąco nowe otoczenie/wrogów/przedmioty/whatever, a kiedy znikają za ekranem to je usuwasz/nadpisujesz nowymi.
Technicznie tak, ale gracze zjedzą cię na dzień dobry. Przerabiałem już ten temat i z doświadczenia: albo gra jest powolna i wymaga myślenia - planowania co wyklucza generację losową, albo bardzo szybka i gracze uczą się jej na pamięć co także wyklucza losowość. Chyba, że mówimy o doczycie, kopiowaniu danych z poprzednio wygenerowanej tablicy i wstawianiu jako początkowy element.

Jako, że temat dotyczy shooterów (lubi), to kasacja wrogów gdy znikną z ekranu też nie jest najlepszym pomysłem. Albo mamy coś sporego i powolnego, którego ograniczyć ekranem gry się nie da bo możliwość jego poruszania będzie żadna, albo stada szybkich jednostek, których ruch jest z góry zaplanowany (polega na zapamiętanych wcześniej stanach sin/cos/atan) co także wyklucza ich kasację. Oczywiście wszystko zależy od tego czy mamy scroll w dwóch wymiarach. W przypadku jednego wymiaru sprawa jest oczywista, ale gra wtedy nie trzyma nowoczesnych standardów, a shootery, nawet 2D, baardzo mocno wyewoluowały ;).
Wyjątek to popcorn, a więc grupa jednostek lecąca w stałym kierunku, np. przelatujemy przez pas asteroidów. Wtedy kasacja za obszarem ekranu jest jak najbardziej wskazana.

Tutaj w sumie nie ma co kombinować. Nawet jeżeli mamy 200 jednostek na ekranie to posortowanie tablicy trwa tyle co nic. Robiłem testy z tysiącami gdy robiłem Seditio, nigdy nie było z tym problemu.


Co do samego terenu i kolizji, to wszystko zależy od tego z czym mamy do czynienia. Jeżeli teren to skomplikowana mieszanina różnych płaszczyzn z maskami itd. do tego wrogowie o skomplikowanych kształtach to tak, tu można się pokusić o odczyt koloru maski. Choć rozumiem, że chodzi o kolizję punktu, bo perfekcyjna kolizja każdego pixela statku gracza z każdym pixelem jakiegoś obszaru maski będzie najpewniej dość powolna.

Jeżeli to tylko kolizja ze ścianą kanionu, to nie ma sensu kombinować i śmiało można zaprząc do działania trygonometrię.