O czym tym razem będzie? Ano o kolejnych przemyśleniach dotyczących światów 2D. GIGANTYCZNYCH ŚWIATÓW 2D.Tak ogromnych jak tylko pamięć komputera pozwoli i wola chęci oprogramowania pojedynczego poziomu do takiej gry. Artykuł ma też i drugi ukryty cel: DELPHI TO POTĘGA. Jeśli ktoś mówi Ci że C lub CPP zasługuje na uwagę to ma rację, ale jak przy tym krytykuje inne języki to jego zdanie jest nie wiele warte. Każdy język pozwala bardzo dużo wycisnąć z kompa… w jednym robi się to łatwiej, w drugim trudniej. Zasady są te same, stąd też treści zawarte w tym cyklu na pewno będą przydatne dla każdego, kto chce napisać grę 2D.
Jako że pomysł jest dość cenny zastrzegam sobie prawa autorskie i bez zgody autora nie pozwalam zamieszczać artykułu na innych serwisach niż www.unit1.pl
Tu chcę podkreślić ze omawiany model będzie 3 warstwowy. Gdzie każda warstwa może być zbudowana z kafli 25×25 lub 2000×2000 sztuk a nawet więcej. Wymiary kafli od 32×32 pikseli do 256×256. Jak kto woli. Mój leciwy komp- Duron 800, 512 MB RAM-u radzi sobie z 3 warstwami 2500×2500 dla kafli 64×48 pikseli wyśmienicie, FPS ponad 120, czas budowy losowego świata około 10 sekund. Im większy wymiar kafla w pikselach tym FPS będzie lepszy, który i tak jest bardzo dobry bo od 100 FPS wzwyż.
Temat planuję omówić w 3 częściach
1. opis modelu pojedynczej kości (kafla) warstwy świata 2D
2. przykład giganta mapy świata prostokątnego
3. przykład giganta mapy świata izometrycznego
Może też być omówiony gigant modelu świat opisanego prze zemnie w „Górach i dolinach świata 2d”. Nie obiecuję bo coraz bardziej nie lubię komputerów, wolę łódki strugać
Czas zacząć…
MODEL POJEDYNCZEJ KOŚCI WARSTWY ŚWIATA 2D
Poniżej rysunek przedstawia dwie kości świata 2D. Pojedyncza kość ma wymiar 64 x 48 pikseli. Proszę zwrócić uwagę, że drewniana (ma to być kasztelania:) budowla jest większa niż wymiar kafla.
Strzałki z klawiatury umożliwiają ruch warstw
Jakie zdania są stawiane na kość takiego świata:
a) musi umieć się poruszać
b) musi istnieć możliwość przyjęcia obrazu większego niż przyjęty rozmiar kafla
c) nie może być rysowana gdy nie zawiera obrazu
d) musi reagować na zmianę kolorów i kanału przezroczystości (Alpha)
e) może być animowana
f) może istnieć test kolizji
g) … i różne inne pomysły
Spełnienie wszystkich zadań najłatwiej jest zrealizować tworząc klasę bazową pojedynczej kości warstwy. W kodzie programu jest ona zapisana w warstwa_cz1.pas
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
TKostkaMapy=class(TSimpleAnimSprite) fPokaz:boolean;//dodatkowa flaga rysowania - ukrywania dla edytora swiatow typ:TTypSwiata; indeks:integer; fSiatka:boolean;//falaga pokazywania suiatki x0,y0, //stale wspolrzedne zaczepienia kafla dX,dY:single;//wzgledne przesuniecie kafla left, top :integer;//wspolrzedne lewego rogu obrazu przekazanego do klatki RogX,RogY:integer;//wspolrzedne kolumny i wiersza gornego lewego rogu mapy idWskMApy :integer;//indeks wskaznika mapy private procedure RuchWLewo; procedure RuchWPrawo; procedure RuchWGore; procedure RuchWDol; procedure Draw;override; procedure Move(const MoveCount:single);override; end; |
Serce bohatera artykułu zostało podane. Teraz pokrótce omówię realizację zadań wymienionych w podpunktach a, b…
Ad a) musi umieć się poruszać
Proszę teraz odpalić program i wcisnąć klawisze strzałek. Zauważymy, ze warstwa wcale nie porusza się po całym ekranie ale jest uwięziona. Ruch kości jest ograniczony. Kość może przesunąć się w lewo, prawo o odcinek nie większy niż jej szerokość, a w górę lub w dół o odcinek nie większy niż jej wysokość. Po czym wraca na swoje miejsce. Konkretnie do zmiennych
|
1 |
x0,y0, //stale wspolrzedne zaczepienia kafla |
wartość przesuwu pamiętana jest w
|
1 |
dX,dY:single;//wzgledne przesuniecie kafla |
Procedury reagujące na ruch to:
|
1 2 3 4 5 6 7 |
procedure RuchWLewo; procedure RuchWPrawo; procedure RuchWGore; procedure RuchWDol; |
Wywołane w
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
procedure TKostkaMapy.Move(const MoveCount:single); begin inherited Move(MoveCount); dx:=dx+SkokX; dy:=dy+SkokY; RuchWLewo; RuchWPrawo; RuchWGore; RuchWDol; x:=x0+dx; y:=y0+dy; end; |
Nie opisuję tego bo to zbyt proste. Jedynie nadmienię, ze
|
1 2 3 |
SkokX SkokY |
To zmienne globalne decydujące o przesuwaniu świata zgodnie z życzeniem gracza
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
procedure TForm1.RuchWSwiecie; begin if oisLeft in OmegaInput1.Keyboard.States then begin SkokX:=OmegaTimer1.DeltaSecs*150;end; if oisRight in OmegaInput1.Keyboard.States then begin SkokX:=-OmegaTimer1.DeltaSecs*150;end; if oisDown in OmegaInput1.Keyboard.States then begin SkokY:=-OmegaTimer1.DeltaSecs*100;end; if oisUp in OmegaInput1.Keyboard.States then begin SkokY:=OmegaTimer1.DeltaSecs*100;end; end; |
Tu chce podkreślić znaczenie programowania obiektowego. NIE MA SENSU PRZEKAZYWANIA WARTOŚCI SkokX, SkokY do każdej kości z osobna w jakiś tam pętlach. Jest to ogromy błąd który spowalnia silnik gry. To załatwia główna metoda ojca (nie biologicznego) naszych kości
|
1 2 3 4 5 6 7 |
OmegaSprite1.Collision; OmegaSprite1.Dead; OmegaSprite1.Move(OmegaTimer1.DeltaSecs); OmegaSprite1.Draw; |
OmegaSprite1 jest ojcem dla TSimpleAnimSprite, czyli naszej kości
TKostkaMapy=class(TSimpleAnimSprite)
Ad b) musi istnieć możliwość przyjęcia obrazu większego niż przyjęty rozmiar kafla
Bardzo ważna cecha. Spełnienie tego warunku pozwala osadzać w świcie budynki w całości. Jedynie należy rozwiązać problem justowania takiego obrazu. Rozwiązanie jakie ja przyjąłem jest bardzo proste i idealnie pasuje do drzew. Dla kasztelani należało by je zmodyfikować- co nie jest trudne. Idee justowania przedstawia poniższy rysunek poglądowy
jak widać w kaflu 64×48 pikseli należy umieścić obraz o innym rozmiarze, tu 120×86 pikseli. Justowanie dotyczy warstw 1,2 i tak dalej. W kodzie programu zrobiłem to w momencie załadowania obrazka lub jego zmiany w kaflu warstwy pierwszej. Czyli wykonujemy to tymi liniami
|
1 2 3 |
Kosc1.Left:=(DaneMapy.W1Kosc -Kosc1.Image.TileWidth ) div 2;//ustaw w osi kafla Kosc1.Top :=(DaneMapy.H1Kosc -Kosc1.Image.TileHeight)-16;//uastaw 16 pikseli nagd dolna podstawa kafla |
Wyliczone wartości są przechowywane w zmiennych klasy kafla to jest w
Left
Top
A wykorzystuje się je w procedurze rysowania
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
procedure TKostkaMapy.Draw; var Rect:TRect; begin if fSiatka then begin Image.Renderer.OmegaScreen.DrawRectangle(Round(x+1),Round(y+1),Round(x+DAneMApy.W1Kosc-1),Round(y+DAneMApy.H1Kosc-1), false,1,125,125,125); exit; end; //nie rysuj jesli indeks wskazuje na -1 if (ImageIndex=-1)then exit; Image.Draw(Round(x+left),Round(y+top),0,0.5,0.5,1,1,Red,Green,Blue,Alpha,ImageIndex,0); end; |
Podejście bardzo proste.
Ad b) nie może być rysowana gdy nie zawiera obrazu
c) musi reagować na zmianę kolorów i kanału przezroczystości (Alpha)
To można omówić razem. Kość nie będzie rysowana gdy indeks obrazu wynosi –1 (minus jeden). Zmian kolorów Red, Green, Blue pozwoli nam uzyskać na przykład efekt nocy w poziomie gry. A wszystko to robimy tak
|
1 2 3 4 5 |
//nie rysuj jesli indeks wskazuje na -1 if (ImageIndex=-1)then exit; Image.Draw(Round(x+left),Round(y+top),0,0.5,0.5,1,1,Red,Green,Blue,Alpha,ImageIndex,0); |
Ad e) może być animowana
To zostawiam własnej inwencji twórczej. Należy przerobić odpowiednie przykłady dołączone do komponentu OMEGI. Można zastosować te rozwiązania bo nasza kość jest oparta na klasie TSimpleAnimSprite
TKostkaMapy=class(TSimpleAnimSprite)
Ad f) może istnieć test kolizji
Tu należy zadać sobie pytanie:
Czy warto wykrywać kolizję z drzewem lub budynkiem metodą testu pikseli?
Moim zdaniem nie. Metoda ta przy dużej ilości drzew da się nam we znaki. Spowolni grę. Dalej: poza niewidoczną części świata gry nie jest wykonywana. Jej użycie będzie bez sensu dla „automatów”. Jak ktoś czytał moje arty o „Wędrówkach w świecie 2D” to może pamięta, ze wprowadziłem tam tablicę siatki drogi. Test kolizji będzie tylko wykonywany przez obiekty ruchome i polega na sprawdzeniu : jest /brak. Stąd też kolizje należy wykonywać w klasach obiektów żywych. W warstwach nie…Ale to jest moje zdanie i nie każdy musi je podzielać.
Na tym kończę część pierwszą. Kiedy powstaną kolejne tego nie wiem. Co prawda odpowiednie przykłady programów dla modelu świata 2D prostokątnego i izometrycznego są gotowe. Brakuje tylko tekstu…
Pozdrawiam oksal
Zbylitowska Góra 3.01.2007
Autor: Oksal
