Artykuł: Systemy cząsteczkowe -- część 1We Wrocławskim Portalu Informatycznym (WPI) jakiś czas temu pojawił się artykuł mojego autorstwa: "Systemy cząsteczkowe -- część 1". Mam nadzieję, że się spodoba ;)
Przy okazji komunikat: komentowanie na stronie zostało tymczasowo wyłączone w związku z pojawiającym się spamem. Wróci zaraz po przeniesieniu strony na WordPress.
Continuous integrationJedną z rzeczy na które kładziony jest nacisk w zwinnych metodologiach (ang. agile) to ciągła integracja. Pod tą nazwą nie kryje się nic innego jak częste, automatyczne czynności dotyczące projektu, zwykle kompilacja i uruchamianie testów jednostkowych i/lub regresyjnych. Ma to na celu szybkie wykrywanie problemów i ich rozwiązywanie. Ponieważ problemy są wykrywane szybko, powinno dać się je dość łatwo wyeliminować. Dzięki temu w każdym momencie mamy dostęp do sprawnego builda.
Przykładowe zalety takiego podejścia:
Podczas każdego builda powstają pliki, które możemy chcieć zachować -- nazywane są artefaktami. Mogą to być logi, wyniki testów, pliki wykonywalne, informacje o użytych plikach itp. Pozwala to na jeszcze lepsze śledzenie zmian w projekcie i znajdowanie problemów.
Najważniejszą rzeczą w całej idei continuous integration jest automatyzacja. Możemy kupić potężny komputer za kilka tysięcy, który będzie to wszystko robił i można znacząco zmniejszyć obciążenie członków zespołu. To inwestycja, która na pewno zwróci się bardzo szybko.
Tyle w teorii -- a jak to wygląda w praktyce? Na licencji MIT dostępny jest Hudson. Jego konfiguracja jest bardzo prosta i współpracuje chyba z każdym popularnym systemem kontrolii wersji ;) Sam używam go na komputerze Mac Mini do kompilacji 3 projektów -- frameworka i aplikacji, które go używają. Jak wiadomo, aplikacje pod iPhoneOS można niestety kompilować tylko pod systemem Mac OS X. Dzięki takiemu rozwiązaniu w kilkadziesiąt sekund od aktualizacji repozytorium mam przygotowanego zipa ze skompilowaną aplikacją, którą mogę pobrać w każdym miejscu na świecie przez przeglądarkę i zainstalować przez iTunes pod Windows. Ma to ogromne znaczenie w zespołach, które mają dostęp tylko do jednego komputera Mac.
Generowanie sudokuNajwiększym (choć wcale nie tak dużym) wyzwaniem podczas robienia sudoku jest generowanie planszy. Musimy zadbać o to, żeby plansz było dużo, żeby były poprawne (i miały jedno, unikalne rozwiązanie) i żeby można było wybrać poziom trudności. Okazuje się, że rozwiązanie jest bardzo proste i powinno zadowolić każdego.
Jak więc wygląda to proste rozwiązanie? Weźmy dowolną planszę o odpowiednim poziomie trudności i przeróbmy ją tak, żeby wyglądała na unikalną. Gracze nie powinni zauważyć różnicy. Jeszcze tylko trochę terminologii -- grupami pionowymi (poziomymi) będę nazywał grupy trzech kolejnych kolumn (wierszy) na planszy. Mamy więc trzy grupy pionowe i trzy grupy poziome. Sposób w jaki należy przerabiać planszę:
Zatem planszę można przerobić na 609 499 054 080 sposobów. Sporo, prawda? Oczywiście nie wszystkie są unikalne (np. gdy plansza ma dwie puste kolumny), ale jest tego wystarczająco dużo. Łatwo zauważyć, że plansza będzie wciąż poprawna i poziom trudności zostanie zachowany. Teraz wystarczy dla każdego poziomu trudności przypożądkować kilka plansz 'startowych' i mamy kompletny system generowania sudoku. Pozostaje tylko jedno pytanie -- skąd wziąć plansze startowe i jak ocenić ich poziom trudności? W sieci można znaleźć różnego rodzaju strony, które rozwiązują sudoku, niektóre z nich podają też ocenę trudności. Pozwala to już na dość dobre zbudowanie bazy plansz 'startowych' i zapewnienie, że żadne z nich nie są izomorficzne ;)
Nie takie iPhone SDK straszne jak je malująWspomniałem ostatnio, że będę pisał więcej w związku z projektami nad którymi powoli pracuję. Na razie nie ma co pokazywać, więc postanowiłem napisać kilka słów o tym jak wygląda praca przy pisaniu czegoś na iPhone i ewentualnie dać jakieś drobne wskazówki.
To co może na samym początku przestraszyć to Objective-C. Na szczęście nie jest to problem, bo bardzo łatwo jest łączyć ten język z funkcjami pisanymi w C/C++. Przez to stanowi on tylko spoiwo między aplikacją (a przynajmniej w moim przypadku) a urządzeniem. W tej chwili większość kodu Objective-C w moim projekcie to szkielet aplikacji OpenGL ES dostarczany z xcode -- nie jest tego dużo i w żaden sposób nie przeszkadza w normalnej pracy. Jeżeli potrzebna jest jakaś funkcjonalność z systemu, w sieci można znaleźć gotowe kawałki kodu.
Do uruchomienia swojego kodu na iPhone przygotowywałem się już od jakiegoś czasu -- przeniosłem rendering z Direct3D do OpenGL ES 1.0 i zrobiłem spory refactoring. Gdy położyłem już swoje ręce na odpowiednim sprzęcie, uruchomienie na symulatorze zajęło jeden dzień. Po tym jak zapłaciłem za dostęp do programu developerskiego wystarczył jeden wieczór (spędzony na generowaniu certyfikatów), żeby uruchomić na sprzęcie. Spodziewałem się, że zajmie mi to więcej czasu, ale na szczęście poszło dość sprawnie -- w sumie nic dziwnego, bo na razie nie robiłem nic zaawansowanego.
Aktualnie projekt ściągnięty z repozytorium kompiluje się bez problemów pod xcode jak i w Visual Studio pod Windows. Zdecydowanie wolę pracę z tą drugą platformą i taka przenośność jest bardzo wygodna. Przydaje się implementacja OpenGL ES pod windows, żeby mieć pewność, że obejdzie się bez problemów.
Żeby nie było, że smęcę bez sensu i tylko korzystam z tego co znajdę gotowe w sieci, poniżej zamieszczam dwa kawałki kodu w dziwacznym języku, które mogą się komuś przydać. Nic odkrywczego, ale od czegoś trzeba zacząć ;)
// ukrycie górnej belki aplikacji, do użycia w widoku [[UIApplication sharedApplication] setStatusBarHidden:YES];
// pobranie nazwy katalogu, w którym znajdują się zasoby
const char* getResourcesPath()
{
NSString* path = [[NSBundle mainBundle] resourcePath];
return [path UTF8String];
}
Postanowienia noworoczneZ końcem każdego roku miałem postanowienie, że w kolejnym będzie lepiej. Jakoś nigdy nie miałem konkretnej listy celów, które chcę osiągnąć, więc ciężko oceniać czy rok był udany czy nie.
Żeby mieć się z czego za rok rozliczać, garść postanowień:
Nie jest tego za dużo, ale przynajmniej będzie można łatwo to zrealizować. Mam nadzieję, że taka deklaracja planów choć trochę mnie zmotywuje do ich realizacji ;)
Compo 3hW poprzedni weekend na warsztacie zostało zorganizowane trzygodzinne compo.
Jeszcze nigdy nie brałem udziału w tak krótkim pisaniu gry na czas, ale postanowiłem, że zobaczę co z tego wyjdzie. Ostatecznie zająłem 2 miejsce i jestem z tego zadowolony.
Gra (oczywiście niedokończona ;)), którą pisałem była klonem crimson landa i wypadła nienajgorzej. Całkiem ciekawe wydają mi się szczegóły techniczne, bo jadąc do domu na święta nie miałem dostępu do swojego kodu i pisałem kompletnie od zera:
Ciekawostką jest też to, że na procesorze C2D 1.8 GHz, użycie procesora według Menadżera zadań Windows nie przekracza 2%. Jak widać proste gry można spokojnie robić bez jakiejkowiek akceleracji ;)
Grę można zobaczyć tutaj.
Aktualizacja freedokuJest to pierwszy z wpisów o freedoku na moim blogu. Z czasem pojawi się tu ich więcej i choć głównie będą informować o aktualizacjach, pojawią się też takie, które będą opisywać rzeczy dziejące się pod maską.
Jeżeli ktoś znajdzie jakieś błędy, to proszę o napisanie w komentarzu lub na e-mail. Miłego grania.
Deferred shadingDeferred shading jest coraz popularniejszą techniką oświetlenia. Idea jest bardzo prosta i wydaje się łatwa w implementacji. Szukając informacji na jej temat zebrałem odnośniki do kilku artykułów i postanowiłem się nimi podzielić:
Jak widać jest tego sporo i możemy zobaczyć jak to robią inni zanim zabierzemy się do implementacji.
Casual Games HarmonyChariboeta-mmarshenNetrixRegeditSell More GamesTomasz DąbrowskiWojciech TomanWachuXion
revo 2005-2012, wszelkie prawa zastrzeżone, w użyciu trochę silk icons, a pod maską CodeIgniter (generation time: 0.0328s)
