Jak obiecałem w poprzednim w poprzednim wpisie, przedstawię teraz ciut bardziej sensowne rozszerzenie, niż to, które pokazałem w pierwszym poście z tej serii. A będzie to bardzo prosty binding. Przy pisaniu tego rozszerzenia do silnika(które to jest dostępne na GitHubie) pokusiłem się o implementację podobną do tej z WPF. Co prawda nie używałem DependencyProperty, ale i tak stwierdzam, że jest to przerost formy nad treścią. Niemniej jestem z tego dumny
Czytaj dalej…

Dziś natknąłem się na coś, z czym nie potrafię sobie poradzić. W mojej implementacji bindingów pobieram obiekt źródłowy przez IXamlNameResolver(który to pokrótce opisałem w poprzedniej notce) – wszystko działa pięknie, dopóki nie zachcemy odwoływać się do obiektu-rodzica dodatkowo odwołując się do niego z innego miejsca. Ciężko to opisać słowami, kod najlepiej to zobrazuje:

<Element x:Name="el1" Value="{Binding Source=el2,Path=Value}" />
<Element x:Name="el2" Value="5">
  <SubElement Value="{Binding Source=el2,Path=Value}" />
</Element>

Gdy zakomentuje sobie pierwszy element(a co za tym idzie i wiązanie) wszystko działa jak należy. Jednak gdy on istnieje… zaczynają się dziać cuda Gdy parser XAML przechodzi w fazę reparsowania grafu rozwiązuje pierwszą zależność(ten zewnętrzny binding) i przy drugim… rzuca wyjątkiem KeyNotFoundException z jakże wiele mówiącym callstackiem:

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at MS.Internal.Xaml.Context.NameFixupGraph.<GetRemainingReparses>d__a.MoveNext()
at System.Xaml.XamlObjectWriter.CompleteNameReferences()
at System.Xaml.XamlObjectWriter.WriteEndObject()
at System.Xaml.XamlServices.Transform(XamlReader xamlReader, XamlWriter xamlWriter, Boolean close
Writer)

Przekonać się o tym można pobierając ten commit.

Próbowałem różnych kombinacji – przenosiłem element nad, pod, z boku, z lewej, z prawej, dodawałem inne – nic. A wystarczy zakomentować ten wewnętrzny element…

Zastanawiam się, czy nie trafiłem przypadkiem na jakiś bug w .NET Frameworku. Jest to sprzeczne z tym, co napisał Xion w jednej ze swoich notek, ale chwilowo nie widzę innego rozwiązania, tym bardziej, że występuje to tylko pod jednym, jedynym warunkiem. Dodatkowo „na nie” przemawia fakt, że w WPF coś takiego działa(z tym, że jest tam to inaczej rozwiązane). Może ktoś z Was się z czymś takim spotkał w swojej karierze, ewentualnie widzi błąd w moim kodzie?

Ostatnio pokazywałem, jak napisać proste rozszerzenie XAML – opisałem, jak stworzyć parametrowe i bezparametrowe rozszerzenie. Dziś skupię się na metodzie ProvideValue, a dokładniej na dostawcy usług, który przekazywany jest nam w parametrze. Czytaj dalej…

Ostatnio cały czas bawiłem się XAML-em, by w końcu doprowadzić system GUI to względnej używalności. Temat ten jest na osobną notkę, która możliwe, że pojawi się niedługo

XAML w standardzie jest już dość rozbudowany. Lecz gdyby to nam nie wystarczało(a czasami nie wystarcza), daje nam możliwość jeszcze większej rozbudowy. Wystarczy odziedziczyć z klasy MarkupExtension, by móc korzystać z własnych rozszerzeń(dostępnych za pomocą sekwencji ucieczki {}). Ale jak to się robi w praktyce?

W poprzednim odcinku skupiłem się raczej na grze(i jak ją można ulepszyć) niż na, jak tytuł wskazywał, serializacji. Tak szczerze powiedziawszy to o grze samej w sobie jest bardzo mało wpisów, więcej jest o tym, czego użyłem, początkach z bibliotekami czy bojami z silnikiem. Przyznam, że nie wiem, czym to jest do końca spowodowane, możliwe, że gra jest od strony technicznej mało ciekawa

Na początku miałem zamiar opisać wszystkie znane mi sposoby na to, lecz po przemyśleniach stwierdziłem, że jest to bez sensu. W Internecie jest już tyle tekstów na ten temat(np. MSDN), że nie ma potrzeby, bym powielał to, co już jest. Opiszę natomiast to, czego ja użyłem i dlaczego akurat tego. Czytaj dalej…

Ostatnie kilka dni przesiedziałem nad samą fizyką. Nie implementowałem jej(w sposób nie-testowy) w grze, gdyż najpierw musiałem poznać tą bibliotekę i opracować „jak to zrobić”. Całe szczęście Box2D jak i Farseer Physics używa się przyjemnie i nie miałem większych problemów z ogarnięciem ich.

Przy pierwszym starciu z silnikiem przejrzałem jego „Hello World”(albo raczej „Hello World” Box2D) i napisałem „coś na wzór”(czyt. przepisałem to jeszcze raz ) swojego – oczywiście wszystko w konsoli. Potem zabrałem się u przepisałem to, co napisałem wcześniej, pod mój „silnik”. Hurra! Działa. Co prawda były błędy, ale tylko w wyświetlaniu(nie wiedziałem do końca wtedy „jak to działa”, teraz już wiem ciut więcej). Niestety, był to błąd. Zacząłem implementować poruszanie się jednostek. I, ogólnie rzecz biorąc, nie działało to tak jak chciałem. Niby się wszystko ruszało, kolizje były, ale a to tu coś się przesmykało, to tu „skakało”(choć to „wyłączyłem”), to się ruszać nie chciało. Nie wiedziałem, o co chodzi. Czytaj dalej…

Silników fizycznych mamy całą masę: Box2D, Bullet, Havok, PhysX, Newton Game Dynamics. Część jest OpenSource, część darmowa tylko do zastosowań niekomercyjnych, niektóre tylko komercyjne. Część 2D, cześć 3D. Część stosunkowo mało rozbudowana(np. pierwsze dwa z mojej listy), część to ogromne biblioteki(te komercyjne). Niestety, większość nie posiada rozwijanych wrapperów lub portów dla .NET, które by nie wymagały XNA.

Przeszukując czeluści Internetu natrafiłem na kilka wartych uwagi projektów. Większość bazowała na już istniejących rozwiązaniach(głównie Box2D, ale znalazł się też porty Bullet), lecz również na XNA, co przekreślało ją w moich zastosowaniach(a nie mam ochoty portować biblioteki na nie-XNA). Oto ich lista:

• Box2D.XNA – próbowałem stworzyć jej port pod bibliotekę matematyczną OpenTK, lecz nie potrafiłem doprowadzić tego do prawidłowego działania(nie liczyło kolizji)
• BulletX – port Bullet pod XNA, nawet nie sprawdzałem

Na moje szczęście znalazło się też kilka, które nie wymagają XNA(lub mają porty i pod niego). A były to:

• Box2DX – na początku wydawała mi się najlepszym wyborem, lecz niestety używa niebezpiecznego kodu, co również ją skreśliło
• Farseer Physics – zbudowany na podstawie Box2D.XNA, lecz biblioteka sama w sobie nie wymaga XNA(!)
• Physics2D.Net – biblioteka ta nie bazuje na żadnej, jest napisana od podstaw w C#

Mam dylemat, co do wyboru pomiędzy Farseer Physics i Physics2D.Net. Ta pierwsza bazuje na sprawdzonym rozwiązaniu(może nie przeze mnie, ale jednak) i ma dość pokaźną dokumentacje(włączając w to oryginalną dokumentacje Box2D) w porównaniu do Physics2D. Nie skreślam tej drugiej, lecz po pobieżnym przejrzeniu kodu nie przypadła mi do gustu i zostaję przy Farseer Physics.

OpenGL daje nam do dyspozycji kilka sposobów na wyświetlenie wierzchołków. Można to zrobić używając glBegin..glEnd(zwące się z ang. immediate mode), list wyświetlania(ang. display list), Vertex Array Object i Vertex Buffer Object – to właśnie nim się zajmiemy. Dla dużej części programistów grafiki jego używanie jest wręcz oczywiste, lecz zaczynając programowanie grafiki(przynajmniej w OpenGL) to jest ono często pomijane(bądź jest przedstawiane dopiero później). Aktualnie, obok VAO, jest to zalecane rozwiązanie, gdyż od wersji 3.0 OpenGL immediate mode i display list(choć tego pewien nie jestem) są uznawane za przestarzałe, a w wersji 3.1 zostały usunięte. Czytaj dalej…

No dobra, nie pierwsze tylko trzecie w moim wypadku, ale poprzednie się nie liczą, bo skończyło się na utworzeniu najprostszego okna

Czym jest OpenTK? Jest to binding OpenGL, OpenAL i OpenCL pod .NET. Aktualnie jest w wersji 1.0 RC1 i obsługuję Otwarty GL w wersji 3.2, OpenAL
1.1 i OpenCL 1.0. Do tego posiada dość rozbudowaną bibliotekę matematyczną(która mam nadzieję wystarczy mi) obsługującą wektory, macierze, kwaterniony i struktury opisujące krzywe Béziera.

Posiada kilka klas-kontrolek, które ułatwiają integracje z już istniejącymi programami, np. GLControl dla Windows Forms, GLWidget dla GTK# i, podobno, kontrolkę dla WPF(lecz ja jej nie znalazłem).

Dla gier stworzona jest specjalna klasa GameWindow – całe okno jest przeznaczone tylko dla OpenGL, daje to nam najlepszą wydajność i usuwa zbędne rzeczy ze „zwykłych” form. To właśnie jej będę używał i to ją szerzej opiszę w dzisiejszym poście. Czytaj dalej…

Postanowiłem sobie odpocząć od „projektowania” silnika(jeśli można to nazwać projektowaniem… ) i napisać klasę, która będzie mi udostępniać podstawowe informacje o komputerze i systemie operacyjnym, np.:

• wersję SO
• wersję CLR
• nazwę procesora, jego taktowanie i liczbę rdzeni
• ilość zainstalowanej pamięci RAM
• model karty graficznej, jej pamięć i wersję sterowników

Gdy pisałem coś podobnego w C++ do pobrania informacji o procesorze używałem asemblera i instrukcji cpuid, tutaj „nie ma tak dobrze”. Do pobrania informacji o karcie graficznej używałem OpenGL i glGetString, lecz zdobywałem ich tyle co kot napłakał.

Po krótkim poszukiwaniu dowiedziałem się jak to pobrać – WMI(i System.Environment ). Czytaj dalej…