Jakiś czas temu, na prośbę ludzi z Microsoftu, zabrałem się za pisanie artykułów. Miło mi poinformować, że udało się sfinalizować tworzenie części serii tekstów, które będą stanowić wprowadzenie, do tworzenia gier z wykorzystaniem Microsoft XNA.

Osobom, które są zainteresowane kolejnymi artykułami, nie mogę obiecać konkretnego terminu publikacji, ze względu na duży natłok obowiązków, jednak zachęcam do odwiedzania centrum i wspólnego budowania polskiej sceny XNA.

Obecnie dostępne artykuły:

1. Co to jest Microsoft XNA?
2. Przygotowanie środowiska pracy
3. Tworzenie projektu
4. Wstęp do grafiki 2d/3d

Spis całej zawartości, która jest zaplanowana, znajduje się tutaj.

Źrodło screena: link

Do dyspozycji programistów będą oddane następujące predefiniowane shadery:

• BasicEffect (stary, dobrze znany, oferujący podstawowe efekty)
• DualTextureEffect (jak sama nazwa wskazuje, mieszanie tekstur)
• AlphaTestEffect (billboarding)
• SkinnedEffect (animacje)
• EnviromentMapEffect (mapa środowiska na obiekcie, odbicia)

Custom Shadery nie będą dostępne, przy czym Microsoft nie wyklucza ich wprowadzenia w przyszłości.

Dostępne rozdzielczości dla gier:

• 480×800
• 360×600
• 240×400

Oczywiście zmniejszenie rozdzielczości pozwoli na tworzenie bardziej skomplikowanych scen przy lepszym framerate (wyświetlacz 30hz, więc nie ma sensu tworzyć gier, które mają ponad 30fps, chyba, że są wyjątkowo proste i osiągają taki lub wyższy wynik przy maksymalnej rozdzielczości).

Dla zainteresowanych, Microsoft udostępnił już dokumentacje i pierwszy prosty tutorial, aby ułatwić przygodę z tworzeniem aplikacji na tę platformę.

• MSDN
• Pierwsza gra na Windows Phone
• Wszystkie resource’y w jednym miejscu
• Screencasty z ostatnich sesji z konferencji MIX10 (b. polecam prezentacje, gdzie przedstawiono przykładowe działające aplikację – 3d rpg i przykłady wykorzystania shaderów)

Inni artykuły:

• Polygamia
• Screeny z 3d rpg

Zapowiada się bardzo ciekawie.

W trakcie kursu zaprezentowałem, jak stworzyć aplikację w XNA na przykładzie wymyślonej na potrzeby wykładów gry Chrupcio.

Lista wykładów obejmuje:

1. Wstęp do Microsoft XNA ( 7 minut 21 sekund )
2. Przygotowanie środowiska pracy ( 5 minut 41 sekund )
3. Tworzenie projektu ( 10 minut 20 sekund )
4. Rysowanie w przestrzeni ( 6 minut 13 sekund )
5. Generowanie terenu ( 41 minut 17 sekund )
6. Model z animacjami ( 22 minuty 16 sekund )
7. Sterowanie modelem i kamerą ( 24 minut 0 sekund )
8. Stworzenie komponentów dekoracji ( 14 minut 6 sekund )

Łączny czas trwania wykładów wyniósł: 130 minut i 17 sekund.

Zapraszam do zapoznania się z witryną (wymagana rejestracja i aktywacja konta przez administratora), oraz będę bardzo wdzięczny za wszelkie uwagi dotyczące systemu jak i tematyki / formy nauczania itp.

Internetowy System Edukacyjny XNA

Mam również prośbę do zainteresowanych tą formą nauki, o wypełnienie poniższej ankiety:

Z góry dziękuję!

Surface

Cieszy fakt, iż Microsoft wraz z wprowadzeniem kolejnych platform sprzętowych, planuje wprowadzić natywną obsługę XNA przez te urządzenia. Chodzi tutaj konkretnie, o już dostępny wąskiemu gronu odbiorców stół z technologią multi-touch Microsoft Surface. Obecnie Microsoft udostępnia już API pozwalające pisać aplikację na Surface, w tym z użyciem XNA, które można przetestować na swoim lokalnym sprzęcie. Użytkownik podobnie jak w przypadku tworzenia aplikacji na urządzenia mobilne, widzi emulowane urządzenie.
Przykład prostej aplikacji w XNA uruchomionej na Surface.

Project Natal

Kolejnym dużo bardziej interesującym urządzeniem, które dołączy do gamy urządzeń wspierających XNA, będzie Project Natal, w którym rolę kontrolera pełnić będzie człowiek. Dwie kamery, analizować będą nasz ruch i przekładać go będą na trójwymiarowy model, który będzie mógł wchodzić w interakcje z aplikacją. Można powiedzieć, że dzięki tego typu rozwiązaniom, interfejsy naturalne wejdą w nową erę – przynajmniej pod warunkiem, że coś z tego co obiecuje Microsoft na swoich filmach zostanie spełnione.

Dla osób, które nie wiedzą o co chodzi, polecam te trzy prezentacje:

Windows Phone

W ciągu ostatnich dni, głośno było również o systemie na telefony komórkowe, Windows Phone. Tutaj również otwiera się nowy rynek, ponieważ jak dotąd z małych urządzeń, wsparcie dla XNA posiadał jedynie Zune, który jak wiadomo nie posiada funkcji telefonu, stąd pewnie też i jego popularność nie była największa. Windows Phone, ma uzupełnić lukę na rynku mobilnych urządzeń, którą pozostawił Microsoft, nie dając możliwości programowania w XNA na Windows Mobile. Teraz ma pojawić się taka możliwość. Początkowo, będą to tylko aplikacje 2D, ale uważam, że kwestią czasu będą również i te 3D.

Windows 7 Sensors*

Osoby, które śledzą mojego blip’a, Twitter’a czy też Buzz’a, widzieli już pewnie ten film:

W którym przedstawiono nowe funkcjonalności, które pojawiły się w Windows7. W skrócie chodzi o to, że teraz system potrafi odczytywać stany dowolnych sensorów. Na powyższym filmiku, przedstawiono akcelerometr wykorzystany do sterowania samochodem w przykładzie edukacyjnym pobranym z oficjalnej strony XNA. Nie trudno sobie jednak wyobrazić np. wykorzystanie sensora do pomiaru tętna i dynamicznego dostosowywania poziomu trudności gry, lub intensywności akcji na ekranie, odwrotnie proporcjonalnie do szybkości bicia serca użytkownika. To jeden z przykładów, ale obecnie WinApi Windowsa, podobno, ma umożliwić na współpracę z dowolnymi sensorami zewnętrznymi.

Kolejny przykład: multi-touch na Windows 7:

Zatem początek 2010, zapowiada bardzo ciekawe nowości, które być może za kilka lat będą standardem, mimo, że teraz wydają się odległą przyszłością. Mam nadzieje, że tak się stanie, bo to również dla osób, które skupiają się wokół tych technologii, dobry znak, że warto inwestować w nie swój czas i wysiłek.

Jeżeli interesuje Was to co piszę, a piszę dla Was zbyt rzadko, zapraszam do śledzenia mnie na ww. serwisach mikroblogowych, gdzie znacznie częściej znaleźć można jakieś krótkie notki, szczególnie na tematy XNA’owe.

Na zdjęciu do wpisu widać kamerkę Project Natal (źródło).

* Wolę określenie sensor, zamiast „czujnik”

Koncepcję, która przyjąłem, jest sprawdzanie, czy vertex w konkretnym punkcie, a właściwie normal do niego przypisany, jest nachylony do płaszczyzny pod odpowiednim kątem, który dobrany został eksperymentalnie (określony jest przez współczynnik i zależy od wielkości wygenerowanych vertexów i skali terenu).

Kluczem do wyliczania stromości, jest metoda, która jest składową klasy terrain (w moim przypadku dziedziczy po DrawableGameComponent i posiada jako składową, klasę HeightMapInfo z ww. przykładu), która to z kolei w zależności od spełnienia warunku stromości wyliczonego w ww. sposób, zwraca bool.

Jej postać jest następująca:

public bool bluff(Vector3 position)
        {
            Vector3 normal;
            heightMapInfo.GetHeightAndNormal(position, out position.Y, out normal);
            Vector3 angle;
            Vector3 plane = new Vector3(1, 0, 1);
            normal.Normalize();
            Vector3.Cross(ref plane, ref normal, out angle);
            angle.Normalize();

            if (Math.Abs(angle.Y) < 0.45f)
                return true;
            else
                return false;
        }

Użycie:

// metoda update, reakcja na klawisz
if (terrain.heightMapInfo.IsOnHeightmap(newSpherePosition) && terrain.bluff(newSpherePosition))
{
      // zmień pozycje i wykonaj opcjonalnie jakieś akcje
}
else
{
      // nie zmieniaj pozycji
}

Innymi metodami, które można zastosować w tym przypadku to mapa kolizji (rejonów po których można się poruszać bądź też nie), czy też np. podpięcie systemu fizyki, który wykonał by "brudną robotę" za nas. Zaletą tego rozwiązania oprócz prostoty, jest jego automatyka - raz zaimplemetowany, działa zawsze. Jestem pewien, że można by jeszcze udoskonalić zaprezentowaną metodę, zatem zainteresowanych zachęcam do przedstawienia swoich metod rozwiązania tego problemu, w komentarzach.

Fotografia: [ Link ]

Could not load file or assembly…

Otóż jak się okazuję, XNA Framework jest 32 bitowy i stąd, na 64 bitowym systemie, może pojawić się błąd (jak w nagłówku powyżej), którego identyfikacja, na pierwszy rzut oka nie wydaje się być łatwa, w sytuacji gdy wszystko znajduje się na swoim miejscu, a ponadto referencje prawidłowo wskazują to miejsce. Cały problem rozbija się o tryb kompilacji naszego kodu.

Problem pojawia się tylko w 64 bitowych systemach, w przypadku wyboru opcji „Any Cpu” lub „x64″. Jak napisał Shawn Hargreaves, jedynym rozwiązaniem tego problemu jest kompilacja w trybie „x86″. Warto jednak zauważyć, że problem ten nie występuje w przypadku samego XNA, jeśli ustawimy „Any Cpu” w projekcie. Jednak jeśli w solucji posiadamy inne projekty, np. WindowsForms lub WPF i ręcznie dodaliśmy w nich referencję do XNA, wtedy już tak.

Jeżeli jesteście zainteresowani większymi szczegółami, dlatego tak się dzieje, zapraszam do tego wpisu.

Aby uprzedzić ewentualne pytania: zdjęcie do dzisiejszego wpisu pochodzi stąd (ten uśmiechnięty osobnik to nie ja).

W odpowiedzi, jeden z twórców XNA Shawn Hargreaves, polecił mi przeczytanie tego artykułu. W skrócie ujmując, są 2 możliwości rozwiązania tego problemu:

1. napisanie własnego Shadera nie mniej skomplikowanego, co ten w BasicEffectcie, który uwzględnia pobieranie koloru z vertexa (a nie tylko textury)
2. drugie rozwiązanie, które jest moim zdaniem zdecydowanie prostsze – oteksturowanie całego modelu, co w sumie w grach jest standardem, bo łatwo można uzyskać bardzo ciekawie wyglądający model + dodatkowo bump’em zwiększyć poziom szczegółowości modelu.

Wpis reprezentuje surfujący pies.

10. NFS

Na początek old schoolowy remake pierwszej części Need For Speed

9. HurricaneX2

Jedna z pierwszych większych produkcji. Tutaj przedstawiam trailer z drugiej części gry.

8. Masters of Belial

RPG w klimatach średniowiecznych. Tegoroczny uczestnik Dream Build Play.

7. Britonia RPG

RPG, którego ogromny świat z założenia będzie kulą. Warto nadmienić, że nad całością stoi tylko jedna osoba, co zważywszy na poziom prac i zerowe doświadczenie podczas rozpoczęcia projektu jest imponujące.

6. Crash Demo

Przykład symulacji zniszczeń modelu samochodu.

5. NightFall

RPG Hack&Slash.

4. Edytor Map

Edytor, który był projektem dyplomowym pewnego Szwajcara, wykonany jak twierdzi autor, zaledwie w 10 tygodni.

3. SunBurn Engine

Jeden z naprawdę wielu interesujących gotowych engine’nów, którego autorzy skupili się przede wszystkim na aspektach wizualnych oraz narzędziach do tworzenia gry.

2. Burning Angels

Jedna z najstarszych produkcji, mimo wszystko, bardzo przyzwoicie zrobiona „nawalanka”.

1. Dust: An Alysian Tail

Co tu dużo mówić. Panie i Panowie, zwycięzca tegorocznego Dream Build Play.

Oczywiście interesujących projektów jest znacznie więcej, po więcej odsyłam Was na YouTube. Możliwości są nieograniczone i nic nie stoi na przeszkodzie, aby napisać pełnowartościową grę w C# + XNA, chociaż sam Microsoft nie ukrywa, że głównym celem są gry Casual’owe na platformę Live Arcade.

Co ciekawe, niektórzy próbują portować Ogre3d na tę platformę, a inne silniki też pewnie są już oku programistów.

Co można osiągnąć?

Powołując się na filmy na stronie autorów, 2 przykłady:

…oraz przykład stworzony przez samych autorów JigLibX:

Więcej filmów na stronie projektu.

Utworzenie projektu

Pierwsze co należy zrobić, to pobrać z sekcji Download, najnowsze źródła JigLibX’a. Po rozpakowaniu ich, tworzymy nowy projekt (w moim przypadku projekt XNA 3.1), klikamy w Solution Explorerze na główny korzeń naszego projektu (Solution NazwaNaszegoProjektu) prawym przyciskiem myszy i wybieramy Add › Existing project,

Dodawanie istniejącego projektu do już istniejącego

następnie wybieramy z folderu gdzie rozpakowaliśmy wcześniej pobrany silnik fizyki: JigLibX › JigLibX.csproj.

Dodawanie istniejącego projektu do już istniejącego

Jeżeli wybraliśmy przy tworzeniu projektu, projekt w dla XNA w wersji 3.1, to należy teraz zrobić upgrade projektu JigLibX do wersji 3.1. Robimy to klikając prawym przyciskiem myszy, na korzeniu projektu JigLibX › Upgrade solution. Musimy to zrobić, aby później móc dodać w projekcie głównym referencje do projektu JigLibX’a. Inaczej nie będzie to możliwe, ponieważ obecnie jest on przeznaczony dla wersji 3.0. Zmiany w wersji 3.1 nie są na tyle duże jednak, aby w pełni poprawnie biblioteka ta działała pod tą wersją XNA.

Następnie, klikamy prawym przyciskiem myszy na korzeń naszego głównego projektu (w moim przypadku nazywa się on FizykaZJigLibX) › Add reference › Projects › JigLibX. W drzewie naszego projektu, w folderze references powinien pojawić się JigLibX. Od teraz mamy dostęp do tej przestrzeni nazw.

Dodanie systemu fizyki

Po pierwsze, konieczną rzeczą będzie dodanie odpowiednich przestrzeni nazw w pliku Game1.cs.

using JigLibX.Physics;
using JigLibX.Geometry;
using JigLibX.Collision;

Możemy zatem korzystać z klas napisanych przez twórców JigLibX’a. Na początek, w konstruktorze naszej klasy, stworzymy dwa obiekty.

public Game1()
{
graphics = new GraphicsDeviceManager(this);
Content.RootDirectory = "Content";

PhysicsSystem world = new PhysicsSystem();
world.CollisionSystem = new CollisionSystemSAP();
}

Obiekt world, będący instancją klasy PhysicSystem, zainicjuje wszystkie niezbędne zmienne i będzie niejako kontrolerem zdarzeń zachodzących wewnątrz naszej aplikacji. Zdarzeń związanych z fizyką. W kolejnej linii, do właściwości CollisionSystem, przypisujemy utworzony obiekt typu CollisionSystemSAP, który jest konieczny, aby wykrywać wszelkie kolizje. Klasa ta wykorzystuje algorytm „sweep and prune” do wykrywania kolizji, który w tym przykładzie, będzie wystarczający, jeśli jednak zaglądniemy do folderu, Collision w projekcie JigLibX, zobaczymy, że mamy możliwość skorzystać z innych gotowych klas, wykorzystujących inne algorytmy, np. bazujący na siatce (grid). Jeżeli pominięto by ten krok, nie moglibyśmy reagować na kolizje, a obiekty po prostu przechodziły by przez siebie, bez żadnej reakcji.

Należy zrobić jeszcze jedną rzecz, mianowicie, regularnie aktualizować nasz obiekt w którym przechowywana jest logika fizyki. Aby to zrobić, wystarczy w metodzie Update, dodać następujący kod:

float timeStep = (float)gameTime.ElapsedGameTime.Ticks / TimeSpan.TicksPerSecond;
PhysicsSystem.CurrentPhysicsSystem.Integrate(timeStep);

Ponieważ PhysicsSystem.CurrentPhysicsSystem jest składową statyczną, jest ona dostępna z każdego miejsca w naszym projekcie, co niewątpliwie zwiększa wygodę użytkowania tego rozwiązania.

Utworzenie klasy aktora

Klasa aktora, będzie tak naprawdę służyła do utworzenia obiektu, w którym ustawiane będą odpowiednie parametry określające obiekt w naszej aplikacji, a które to są niezbędne do wszelkich obliczeń przy kolizjach z otoczeniem.

Utwórzmy zatem klasę BoxActor.cs, klikając na korzeń naszego projektu › Add › Class..

Tworzenie klasy BoxActor.cs

Umieśćmy poniższy kod wewnątrz pliku BoxActor.cs:

using System;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using JigLibX.Math;
using JigLibX.Physics;
using JigLibX.Geometry;
using JigLibX.Collision;

namespace FizykaZJigLibX
{
    public class BoxActor : DrawableGameComponent
    {
        private Vector3 position;
        private Vector3 scale;

        private Body _body;
        public Body Body
        {
            get
            {
                return _body;
            }
        }

        private CollisionSkin _skin;
        public CollisionSkin Skin
        {
            get
            {
                return _skin;
            }
        }

        public BoxActor(Game game, Vector3 position, Vector3 scale) : base(game)
        {
            this.position = position;
            this.scale = scale;
        }
    }
}

Klasa BoxActor dziedziczy po klasie DrawableGameComponent, ponieważ aktor musi być rysowany na ekranie, abyśmy mogli zobaczyć co się dzieje. Pole position przechowuje informacje o centralnym punkcie wewnątrz box’a, natomiast scale – jego wymiary. Body należy rozumieć, jako zmienną która przechowuje informację o ruchu oraz obracaniu się naszego obiektu. Skin odpowiada za wykrywanie kolizji.

Utworzenie Body i CollisionSkin

Kolejnym krokiem będzie dodanie na końcu konstruktora klasy BoxActor, następującego kodu:

_body = new Body();
_skin = new CollisionSkin(_body);
_body.CollisionSkin = _skin;

Do zmiennej _body, przypiszemy instancję klasy Body, która będzie przechowywać podstawowe informację o stanie w jakim znajduje się obiekt. _skin będzie posiadał informację o „powłoce” naszego obiektu, która zostanie utworzona na bazie, wcześniej ustawionego _body. Na koniec, konieczne jest jeszcze ustawienie własności CollisionSkin dla _body.

Teraz, zdecydujemy jaki kształt, będzie posiadał nasz aktor. Od tego zależy jak będzie się zachowywał na scenie. Służą do tego klasy Primitives znajdujące się w JigLibX › Primitives.

W naszym przypadku, zależy nam, aby nasz obiekt zachowywał się jak skrzynia, zatem wykorzystamy do tego klasę Box, dodając poniższy kod, na końcu konstruktora klasy BoxActor.

Box box = new Box(Vector3.Zero, Matrix.Identity, scale);
_skin.AddPrimitive(box, new MaterialProperties(0.8f, 0.8f, 0.7f));

W powyższym kodzie, utworzyliśmy nowy obiekt klasy Box, którego parametry w konstruktorze oznaczają kolejno: Pozycję środka naszego Box’a, orientację Box’a (Macierz jednostkowa oznacza brak rotacji itp.), oraz skalę, która ustalona będzie przy konstruowaniu obiektu BoxActor.

Druga linia, dodaje powierzchnię kolizyjną do naszego obiektu, aby mógł reagować z innymi obiektami. Pierwszy parametr, to typ obiektu z jakim mamy do czynienia, drugi parametr określa zachowanie się materiału (tarcie oraz elastyczność).

Ustalanie masy obiektu

Aby ustalić masę obiektu, której w dodatku środek ciężkości, będzie się zmieniał w zależności od kierunku sił jakie będą na ów obiekt oddziaływać, autorzy JigLibX, stworzyli taką oto metodę, którą dodamy do klasy BoxActor.

private Vector3 SetMass(float mass)
{
    PrimitiveProperties primitiveProperties = new PrimitiveProperties(
        PrimitiveProperties.MassDistributionEnum.Solid,
        PrimitiveProperties.MassTypeEnum.Mass, mass);

    float junk;
    Vector3 com;
    Matrix it;
    Matrix itCoM;

    Skin.GetMassProperties(primitiveProperties, out junk, out com, out it, out itCoM);

    Body.BodyInertia = itCoM;
    Body.Mass = junk;

    return com;
}

Na końcu konstruktora, tej samej klasy, ustalimy masę w następujący sposób:

Vector3 com = SetMass(1.0f);

I to wszystko, jeżeli chodzi o przejmowanie się masą naszego obiektu . Oczywiście nic nie stoi na przeszkodzie, aby w trakcie działania aplikacji, dowolnie zmieniać masę obiektu.

Ustawianie Box’a w odpowiednim miejscu

W tym kroku, ustawimy nasz Box na pozycji, którą podawać będziemy w konstruktorze, w trakcie tworzenia naszego aktora. Jest to niezbędne, aby dopasować ciało naszego obiektu, jak i powierzchnię kolizyjną odpowiednio do samego obiektu, aby efekt był adekwatny i realistyczny.

Na końcu konstruktora BoxActor, dodajemy następujący kod:

_body.MoveTo(position, Matrix.Identity);
_skin.ApplyLocalTransform(new Transform(-com, Matrix.Identity));
_body.EnableBody();

Pierwsza linia przenosi „ciało” naszego aktora na określoną pozycję. Drugi parametr w metodzie MoveTo, oznacza orientację obiektu.

Druga linia, ustawia powierzchnię kolizyjną odpowiednio względem środka ciężkości naszego obiektu.

Ostatnia linia, włącza symulację dla _body i zarazem aktora. Ta linia jest niezbędna, ponieważ symulacja, jest standardowo wyłączona.

Tworzenie Świata.

Wszystkie ustawienia związane z framework’iem, zostały ustalone, zatem można przejść do tworzenia Świata. Na końcu konstruktora, w głównym pliku naszego projektu game1.cs, dodajmy następujący kod:

fallingBox = new BoxActor(this, new Vector3(5, 20, 5), new Vector3(2, 2, 2));
immovableBox = new BoxActor(this, new Vector3(0, -5, 0), new Vector3(10, 10, 10));
immovableBox.Body.Immovable = true;
Components.Add(fallingBox);
Components.Add(immovableBox);

Brakuje jeszcze składowych, które należy dodać nad wszystkimi metodami w klasie Game1:

BoxActor fallingBox;
BoxActor immovableBox;

Pierwsze dwie linie tworzą naszych aktorów. Parametry w konstruktorze, oznaczają kolejno: pierwszy – instancja klasy, w której utworzyliśmy aktora, w tym przypadku, klasa główna naszej aplikacji Game1, drugi – pozycja, trzeci parametr oznacza rozmiar elementu.

Trzecia linia oznacza, iż drugi obiekt będzie nieruchomy, a jak widać w parametrach przekazanych do konstruktora, będzie znacznie większy (5x), niż pierwszy obiekt.

Czwarta i piąta linia doda utworzone przez nas obiekty, do kolekcji komponentów, które automatycznie będą rysowane przez klasę Game, po której dziedziczy nasza aplikacja.

Rysowanie

Zajmiemy się teraz ostatnim etapem, czyli wyrzuceniem rezultatu na ekran, a właściwie ładnie to ujmując, narysowaniem naszej sceny. Najpierw jednak, musimy dodać model skrzynki, który wykorzystamy w naszym projekcie. Przykładowy model pochodzący z Innovative Games, można pobrać tutaj.

Po rozpakowaniu pliku i przekopiowaniu dwóch znajdujących się w nim plików (z modelem i teksturą), należy w Solution Explorerze, kliknąć prawym przyciskiem myszy na folder Content (w naszym projekcie) i wybrać Add › Existing item… oraz wybrać plik z modelem .fbx oraz powtórzyć krok, wybierając plik z teksturą.

Folder Content po dodaniu modelu i tekstury

Następnie w klasie BoxActor, utwórzmy nową metodę, która załaduje nasz model:

protected override void LoadContent()
{
    model = Game.Content.Load("boxModel");
}

oraz dodajmy nad wszystkimi metodami w tej klasie, deklarację zmiennej model:

private Model model;

Następnie dodajmy do tej samej klasy, następującą metodę:

private Matrix GetWorldMatrix()
{
    return
        Matrix.CreateScale(scale) *
        _skin.GetPrimitiveLocal(0).Transform.Orientation *
        _body.Orientation *
        Matrix.CreateTranslation(_body.Position);
}

Zwraca ona macierz Świata naszego obiektu, która otrzymujemy w wyniku przemnożenia kolejno macierzy: skali, powierzchni kolizyjnej, a tak naprawdę kąta w jakim się znajduje, „ciała” obiektu (również kąt), oraz pozycji „ciała” obiektu.

Potrzebne będą jeszcze macierze projekcji oraz widoku, które dodamy do klasy głównej aplikacji (w pliku game1.cs):

private Matrix _view;
public Matrix View
{
    get
    {
        return _view;
    }
}

private Matrix _projection;
public Matrix Projection
{
    get
    {
        return _projection;
    }
}

W konstruktorze klasy Game1, na końcu ustawmy macierz projekcji, dodając następującą linię:

_projection = Matrix.CreatePerspectiveFieldOfView(
    MathHelper.ToRadians(45.0f),
    (float)graphics.PreferredBackBufferWidth / (float)graphics.PreferredBackBufferHeight,
    0.1f,
    1000.0f
);

Nie będę opisywał parametrów macierzy projekcji, bo zakładam, że na tym etapie są one dość jasne, jednak jeśli nie, zapraszam do tego artykułu na msdn’ie.

Pozostało nam ustawić jeszcze macierz widoku, zrobimy to w metodzie Update, w pliku Game1.cs, dodając następującą linię kodu:

_view = Matrix.CreateLookAt(
    new Vector3(0, 10, 20),
    fallingBox.Body.Position,
    Vector3.Up
);

Linia ta spowoduje, że w centrum ekranu, znajdować się będzie nasz spadający obiekt. W trakcie spadania, zobaczymy jak, dojdzie do kolizji z obiektem, który został unieruchomiony.

Na koniec, pozostało nam jeszcze dodać metodę Draw dla BoxActor, która zostanie automatycznie wywołana dla tego obiektu przy rysowaniu.

public override void Draw(GameTime gameTime)
{
    BasicWorldGame game = (BasicWorldGame)Game;

    Matrix[] transforms = new Matrix[model.Bones.Count];
    model.CopyAbsoluteBoneTransformsTo(transforms);

    Matrix worldMatrix = GetWorldMatrix();

    foreach (ModelMesh mesh in model.Meshes)
    {
        foreach (BasicEffect effect in mesh.Effects)
        {
            effect.EnableDefaultLighting();
            effect.PreferPerPixelLighting = true;
            effect.World = transforms[mesh.ParentBone.Index] * worldMatrix;
            effect.View = game.View;
            effect.Projection = game.Projection;
        }
        mesh.Draw();
    }
}

Dzięki pierwszej lini, będziemy mieli dostęp do macierzy widoku i projekcji, tworząc referencję do obiektu głównego naszej aplikacji. Reszta kodu, jest typowa dla renderowania obiektów z użyciem klasy BasicEffect. Jedyną istotną rzeczą jest używanie jako macierzy Świata, macierzy którą obliczamy na bieżąco, a właściwie JigLibX oblicza za nas.

Artykuł bazuje na dokumentacji znalezionej tutaj, jednak wiele wskazuje na to, iż przytoczony tutaj tekst jest już nieaktualny, i napisana przeze mnie wersja powinna działać lepiej. Być może spowodowane to jest niepełną kompatybilnością z XNA 3.1, ale z tego co przyglądałem się metodom, jedna z nich, została ograniczona z 3 parametrów do dwóch. Wersja JigLibX 0.3.1 (stan na 11 Września 2009).

Gotowy projekt do pobrania (XNA 3.1) (2,1MB)

Skompilowane demo (XNA 3.1) (0,3MB)

jQuery

http://jqueryfordesigners.com/
Świetna strona dla programistów korzystających z jQuery.
http://net.tutsplus.com/tutorials/javascript-ajax/5-ways-to-make-ajax-calls-with-jquery/
Dobrze opisane zapytania Ajaxowe z wykorzystaniem jQuery.

XNA

http://pdnimporter.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=30541
Tekstury Paint.NET do XNA.
http://xnaviewer.codeplex.com/
Kontrolka, pozwalająca na korzystanie z dobrodziejstw XNA w aplikacjach typu WindowsForms. Nie trudno sobie wyobrazić zastosowanie np. przy tworzeniu map.

Inne

http://www.bugmenot.com
Dzięki tej stronie, nie trzeba się rejestrować na różne serwisy społecznościowe, itp., aby móc w pełni przeglądać zasoby tych serwisów.
http://gskinner.com/RegExr/
Świetne narzędzie ułatwiające pracę z mod_rewrite.
http://www.logoinstant.com/
Darmowe wzory logo.
http://code.msdn.microsoft.com/PowerCommands
Przydatny dodatek do Visual Studio (za Procent‘em).
http://blogs.msdn.com/danieb/archive/2009/08/26/pl-windows-7-search-connectors-czyli-integracja-wyszukiwania-z-systemem-operacyjnym.aspx
Opis jednej z nowych bardzo interesujących funkcjonalności w Windows 7.
Word viewer
Programik pozwala na przeglądanie dokumentów Worda, bez potrzeby posiadania pakietu Office.
http://www.hanselman.com/tools
Naprawdę ogromna lista różnego rodzaju narzędzi, które przydadzą się każdemu, podzielona według kategorii. Sam się zdziwiłem, jak wiele przydatnych aplikacji jeszcze nie znałem.

Polecam również galerię prac autora zdjęcia, które reprezentuje ten wpis.