IZOMETRIA W ŚWIECIE PROSTOKĄTNYM
…jak zwykłe będzie o OMEDZE i DELPHI
Temat artykułu jest kontynuacją cyklu moich artykułów dotyczących gigantycznych światów 2D. Chciałbym opisać sposób, a raczej przedstawić propozycję realizacji problemu rzutu izometrycznego w kaflach ułożonych w sposób typowy dla płaskiego świata mapy gry. Czyli coś takiego
Od razu zaznaczam grafika nie jest moja. Pobrałem ją z tego miejsca: zasoby grafiki 2D
UWAGA: uruchamiając przykład dołączony do artykułu proszę poczekać parę sekund. Plik danych jest dość duży, ponieważ przystosowałem go do trzech rodzajów map: prostokątnej, izometrycznej i góry-doliny (taki mój nowy format). Można go zmniejszyć o 40 %. Ale nie chcę nic zmieniać już w moim edytorze, który i tak nigdy nie zostanie ukończony….
1. Przygotowanie siatki świata
Model świata zapisany jest w mapie giganta 512×386 kafli, gdzie każdy ma wymiar 48×36. Można powiedzieć, że kafel ma nietypowy wymiar:) Otóż nie. Skrócenie jednego boku Stawarza wrażenie perspektywy- głębi (patrz cykl artykułów Wędrówki w świecie 2D ). a że akurat wybrałem 48×36 to tylko wynikało z pobranej grafiki. Tam autor rysunków rysował budynki lub postacie w stosunku 0,75 To znaczy 36/48= 0,75 Oznacza to, że mogę dobierać tak kafle, aby wysokość kafla miała 75% długości z podstawy. Wybrałem rozmiar 48×36 z kilku względów. Między innym z ograniczenia liczby wyświetlanych kafli we wszystkich warstwach oraz utworzenia, czegoś, co określam siatką drogi. Jest ona ukryta w danych warstwy 1. W sposób jawny w tym artykule jej nie wykorzystuję…i już jest temat na kolejny artykuł. Choć pisałem już o tym w Wędrówkach..
Wracając do sedna…osadzony budynek w płaskim świecie powinien wyglądać jak poniżej
a jak się pokaże siatkę drogi, to obraz będzie taki jak poniżej
Jednym z problemów izomerii jest stworzenie na płaszczyźnie głębi, z której wynika możliwość chowania się za budynkiem lub przeszkodą…, ale o tym już też pisałem Czerwone pola oznaczają barierę dla organizmów żywych lub pojazdów. Proszę zauważyć, że bitmapa zamku osadzona w całości ładnie wpasowała się w płaski świat prostokątnych kafli 2D. Reszta to już pisanie kodu. Mechanizm warstw opisałem w gigantach. Tak wiec pomijam to. Z jedną tylko różnicą. Warstwa gruntu, czyli zerowa jest nowego typu
2. Nowy model warstwy zerowej -grunt
Silnik (jeżeli mogę tak powiedzieć) Omegi to te poniższe linie kodu
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
OmegaScreen1.BeginRender; OmegaScreen1.ClearScreen(0,0,0,0); OmegaSprite1.Collision; OmegaSprite1.Dead; OmegaSprite1.Move(OmegaTimer1.DeltaSecs); OmegaSprite1.Draw; OmegaScreen1.EndRender; |
Najbardziej obciąża zegar gry OmegaSprite1.Collision oraz OmegaSprite1.Draw; no i oczywiście to, co sami spapramy. Ogólnie mówiąc wszystko szybko śmiga, gdy mało mamy obiektów typu TSprite. Należy dążyć aby warstwy możliwie mało zawierały TSprite, większą ilość takich obiektów należy zostawić dla postaci. Przypominam, że gadżety i inne obiekty nieruchome w moim rozwiązaniu przekazują swoje cechy kaflom warstw 1 lub 2. Oczywiście gdy są widoczne na ekranie, jeżeli są poza ekranem to cała mechanika zderzeń dzieje się w siatce danych. A że ja oparłem warstwy świata na tym obiekcie to znaczy pochodnej TSprite, więc do wcześniej opisanego rozwiązania (patrz arty: Giganty świata 2D) wprowadzam pewną modyfikację. Warstwa grunt nie musi być potomkiem tej klasy, nie musi pamiętać głębi- wystarczy ze będzie pierwsza narysowana (patrz procedura PokazGrunt(skokX,skokY)) Głębia będzie dla warstwy pierwszej i drugiej.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
OmegaScreen1.BeginRender; OmegaScreen1.ClearScreen(0,0,0,0); RuchWSwiecie(4{OmegaTimer1.DeltaSecs*300}); PokazGrunt(skokX,skokY); //dotyczy warstwy 1, 2 OmegaSprite1.Collision; OmegaSprite1.Dead; OmegaSprite1.Move(OmegaTimer1.DeltaSecs); OmegaSprite1.Draw; |
Warstwa gruntu nie musi wykrywać kolizji, a całą resztę musi umieć co warstwy 1 i 2. Zainteresowanych odsyłam do kodu. Nowy model warstwy gruntu to klasa TKostkaGruntuMapy. Posiada ona te same procedury i funkcje ruchu co pozostałe. Metodę rysowania płynnych przejść opisałem w artykule Płynne przejścia terenu .Przykład pracuje w trybie 1024×768 z włączoną synchronizacją. FPS w dobrej formie…Wszystko zostało już powiedziane.
UWAGA
Aby dołączony przykład działał poprawnie wymagane są te pliki
swiat_512x384.mue2D
teren_rosliny.oil
swiatynie.oil
zamki.oil
D3DX81AB.DLL
MPPSDK.DLL
Muszą być one zapisane w tym samym katalogu, co plik exe
Pozdrawiam
Adam Lasko (oksal) Zbylitowska Góra 18.10.2007
EDIT (20.10.2007):
Zmieniłem plik zapisu świata gry, tylko na wersję prostokątne, co dało zysk na zmniejszeniu wagi pliku danych (ponad 50%). Dodałem również „okno” czasu oczekiwania na załadowanie danych.
