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…

Już od dłuższego czasu przymierzałem się do poznania tej techniki tworzenia oprogramowania. Zawsze gdy tworzyłem oprogramowanie pisałem jakąś funkcjonalność i gdy uznałem, że to co napisałem działa przynajmniej w części tak jak powinno zabierałem się do testowania. I testowałem, testowałem, debugowałem, testowałem… Czasami na przetestowanie i poprawę, często głupich, błędów potrzeba było o wiele więcej czasu niż na „pierwszą implementację”(która zawsze wydaje się najtrudniejsza). Postanowiłem w końcu „coś z tym zrobić”. A nuż się uda i testowanie nie będzie takie męczące? Czytaj dalej…

Kilka dni temu zacząłem pisać swoją pierwszą, „dużą” wtyczkę do Foobara2000. Posiadam w domu słuchawki bezprzewodowe(Seenheiser RS130, polecam – świetny sprzęt) i czasami nie mam dostępu do klawiatury a chcę zobaczyć co leci(jeśli nie rozpoznałem) lub zmienić piosenkę. Gotowego nie znalazłem, więc postanowiłem napisać stosowne oprogramowanie. I tak oto powstała wtyczka foo_RemoteControl. Ma ona za zadanie udostępniać podstawowe(i nie tylko, ale trzeba je dopisać) funkcje do zarządzania odtwarzaczem poprzez TCP/IP. Jest już ona gotowa do użytku i raczej nie będzie dalej rozwijana(choć może się to zmienić, wystarczy, że ludzie wykażą zainteresowanie projektem i potrzebę nowej funkcjonalności), taka funkcjonalność mi wystarcza. Już niedługo pojawi się pierwszy „klient” dla tej wtyczki pod Androida.

Więcej informacji na stronie projektu.