Slick

W jednym z poprzednich postów napisałem, że Slick udostępnia biblioteki natywne tylko dla Windowsa. Otóż dzisiaj przyjrzałem się temu dokładniej i okazało się, że po prostu Windowsowe nativy są w głównym katalogu natomiast pozostałe są popakowane w archiwa JAR i wrzucone do katalogu lib. Wcześniej ich po prostu nie zauważyłem.

W związku z poczynionym odkryciem uruchomiłem netbeansa na nowo zainstalowanym OpenSUSE i rozpocząłem poszukiwanie tutoriali w internecie. Tutaj niestety nie jest tak fajnie jak w GTGE. Dostępne są głównie przykładowe kody źródłowe. Udało mi się jednak znaleźć jeden tutorial ( http://thejavablog.wordpress.com/2008/06/08/using-slick-2d-to-write-a-game/ ), który pozwala załapać jak to mniejwięcej wygląda.

Prawdę mówiąc sam szkielet jest prawie taki sam jak to było w przypadku GTGE. Mamy metody init, update, render, których znaczenia i funkcji raczej nie trzeba tłumaczyć

Slick jest pierwszym silnikiem 2D w Javie, w którym odkryłem możliwość dowolnego obracania obrazków. Dodatkowo przeglądając API zauważyłem, że posiada różne algorytmy wyszukiwania trasy, silnik cząsteczkowy (wraz z edytorem) oraz wsparcie dla tile-map rysowanych w programie Tiled.

Myślę że spędzę na tym silniku kilka ładnych godzin ponieważ zamierzam wziąć udział w tegorocznym WSOC! To chyba będzie pierwsza praca na WSOC napisana w Javie

Dystrybucje

Korzystając z wolnego czasu postanowiłem sprawdzić jak radzą sobie najbardziej znane (przynajmniej moim zdaniem) dystrybucje Linuksa. Pamiętam swoje początki z tym systemem operacyjnym – wówczas byla to dystrybucja RedHat 9. Od tamtego czasu sporo się zmieniło…

Fedora

Na pierwszy ogień postanowiłem puścić Fedorę. Po zainstalowaniu ładnie wykryła sieci bezprzewodowe co zasługuje niewątpliwie na ogromny plus gdyż nawet Ubuntu miał z moją kartą sieciową problemy, które znikły dopiero w najnowszej dystrybucji. Na początek chciałem zainstalować Gnome-Do. Świetne narzędzie do wszystkiego dla użytkowników środowiska GNOME. Po zainstalowaniu okazało się, że nie ma tam żadnych wtyczek (w Ubuntu były zainstalowane z programem). Postanowiłem więc poszukać wtyczek które mnie interesowały. Kilka godzin i milion prób później wciąż nie miałem wtyczek… Porzuciłem więc ten pomysł i postanowiłem przyjrzeć się reszcie systemu.

Zauważyłem, że w Fedorze bardzo duży nacisk kładziony jest na bezpieczeństwo. To cud, że aby ruszyć myszą nie trzeba wpisywać hasła root’a… Co prawda jest to trochę uciążliwe, ale w końcu bezpieczeństwo jest bardzo ważne…

Była jednak pewna rzecz (oprócz irytującego braku wtyczek do gnome-do), która sprawiła, że postanowiłem więcej nie dotykać tego systemu – instalator programów/pakietów. Mimo iż pomysł z kolejkowym dostępem do blokady operacji “na”programach” przypadł mi do gustu to wyszukanie pakietu, który mnie interesował w repozytoriach graniczyło niemalże z cudem – nawet jeśli mniejwięcej znałem nazwę samego pakietu…

Fedora początkowo zrobiła na mnie niezłe wrażenie, ale o przyjazności użytkownikowi chyba jeszcze niewiele słyszała (chociaż z drugiej strony ma interfejs grafizcny ). Jednak po kilku ładnych godzinach klikania i sprawdzania i kombinowania stwierdziłem, że nie jest to system z którym chciałbym żyć na codzień… Postanowiłem spróbować czegoś innego…

OpenSUSE

Następny w kolejce był znany mi już od jakiegoś czasu OpenSUSE. Od naszego ostatniego spotkania poczynił niesamowite postępy. Zaskoczyło mnie trochę, że i on nie miał problemów z rozpoznaniem mojej karty sieciowej i wykryciem sieci bezprzewodowych. Kiwając z uznaniem głową postanowiłem zainstalować sobie na początek sterowniki do karty graficznej. Przyznam się, że trochę się przy tym namęczyłem, ale wszystko przez mój niedobry pośpiech i niechęć do czytania instrukcji Gdyby nie to prawdopodobnie nie sprawiłoby mi to kłopotu. Tak czy inaczej po godzince czy dwóch miałem już zainstalowane sterowniki NVidii do mojej karty i z zapałem ruszyłem psuć inne rzeczy.

Następną rzeczą jaką musiałem zrobić było włączenie odtwarzacza muzyki. Tutaj domyślnym okazał się być mój ulubiony Banshee (zatem plus dla susła ). Niestety okazało się, że nie chce mu się odtwarzać mp3. Okazało się, że brakowało mu codeców, które w Ubuntu są instalowane domyślnie. Nie było ich i pewnie nigdy nie będzie w domyślnej instalacji systemu ponieważ wówczas kolidowałoby to z częścią Open nazwy tegoż systemu Po zgooglowaniu problemu okazało się, że wystarczy ściągnąć i uruchomić jeden mały pliczek i reszta zrobi się za mnie. Tak się stało i po restarcie komputera mogłem się cieszyć moimi ulubionymi utworami wypełniającymi przestrzeń.

Tak świetnie przygotowany do dalszej pracy rozpiąłem guzik pod szyją w moim T-Shirt’cie bez guzików i ruszyłem instalować Netbeansa. Tutaj troszeczkę się rozczarowałem. Netbeans w repozytoriach był w wersji 5.0 (najnowsza to 6.5 czy nawet 6.7) , a po instalacji i uruchomieniu straszliwie wolno pracował. Pomyślałem wówczas: “Hmm… OpenJDK”. Ściągnąłem więc i zainstalowałem najnowsze JDK od SUNa. Następnie ściągnąłem najnowszego Netbeansa z internetu i (po uprzednim odinstalowania tego z repów) zainstalowałem go na dysku. Po uruchomieniu śmiga równie pięknie jak pod znanym i lubianym przez wszystkich systemem.

Dalszych testów już właściwie nie robiłem bo postanowiłem, popracować trochę z tym systemem i przyjrzeć mu się dokładniej. Jeśli zauważę jakieś ogromne niedogodności czy coś godnego uwagi to napiszę o tym na tym blogu.

Podsumowanie

W podsumowaniu chciałbym przyrównać te systemy do najbardziej mi obecnie znanego Ubuntu. Wspomniana na początku Fedora nie ma szans aby równać się z łatwością użytkowania potomka Debiana, ale za to jest mnie idiotoodporny, a co za tym idzie – bardziej konfigurowalny. Właściwie nei ma co tu porównywać gdyż Fedora nigdy nie mówiła, że ma zamiar być najbardziej popularną i łatwą w użyciu dystrybucją. Polecam ją ludziom, którzy nie boją się wyzwań (a uważają, że Gentoo to trochę za głęboka woda ).

Jeśli chodzi o OpenSUSE to w łatwości użytkowania również przegra z Ubuntu i nie poleciłbym go całkowicie początkującym. Jest jedna rzecz, która ogromnie przypadła mi tutaj do gustu. Ustawianie zmiennych systemowych. O ile korzystając z Ubuntu męczyłem się z ustawieniem jednej zmiennej przez kilka dni przeszukując fora, na których każdy miał 100 pomysłów i żaden tak do końca nie skutkował to tutaj wszedłem zagooglowałem o ustawianiu zmiennych systemowych i zaraz dowiedziałem się, że jeśli chodzi o jednego użytkownika to wystarczy ustawić .bashrc w jego katalogu domowym, a globalnie – dodać exportowanie zmiennych w pliku /etc/bash.bashrc.local . Tak to na prawdę takie proste

jMonkeyEngine

Aby dostawić wisienkę na torciku postanowiłem napisać jeszcze o jednym silniku. Ten już “niestety” nie jest tylko 2D. Mamy tutaj do czynienia z całkiem zaawansowanym – jako go reklamują – silnikiem 3D. Przyznam się, że stworzyłem tylko prostą aplikację która wyświetlała sferę i dwa prostopadłościany.

Popatrzyłem jednak troszkę na tutoriale, screeny i różne opisy – wynika z tego wszystkiego że jME jest całkiem ciekawą propozycją dla każdego kto chciałby napisać coś ciekawego dość łatwo i to tak, że uruchomi się to na wielu systemach

Na koniec rzucę linkiem do strony domowej projektu: http://jmonkeyengine.com/

Z niniejszym postem chciałbym ogłosić prawie zakończenie sesji letniej Prawie bo lubię panią prof. od Baz danych i spotkamy się jeszcze we wrześniu Ale teraz frei zeit ^^ Chcę z tego miejsca pozdrowić moją dziewczynę, rodziców, ewentualnie rodzeństwo, psa, panią Zosię ze sklepu warzywnego oraz wszystkich koderów i czytających tego posta. (tak, koderzy czytający tego posta są pozdrowieni dwa razy )

Na osobne podziękowania zasługują także wszyscy moi wykładowcy oraz ćwiczeniowcy, bez których nie cieszyłbym się tak z wakacji

Słowem – na prawdę – końcowym napiszę jeszcze dewizę jaka towarzyszyła mi podczas sesji:

Nie wierz w cuda – polegaj na nich!

Refleksje w Javie

Poszukując nowych i ciekawych zastosowań Javy trafiłem na wzmiankę o mechanizmie pozwalającym ładować biblioteki (klasy) dynamicznie w trakcie działania programu. Właściwie to należało się spodziewać, że będzie to możliwe… Tak czy inaczej mechanizm ten nazwano Refleksjami.

Poszukałem trochę na temat tych refleksji i trafiłem na tutorial jak ich używać: http://www.programowanieobiektowe.pl/java_obiekty_refleksyjne.php.

Niestety to co się dzieje na tamtej stronie – w celu wykorzystania jednego malego obiektu bije na głowę nawet ładowanie zewnętrznych bibliotek w C… Dzieje się tak dlatego, że zakładamy, że dana bibioteko-klasa nie będzie miała nic wspólnego z naszym projektem. Widać zatem, że można załadować w ten sposób każdą klasę. Tylko po co skoro można to zrobić dużo, dużo prościej i przyjemniej. Czyniąc sobie pewne założenia na temat ładowanej klasy możemy znacznie uprościć używanie tej klasy zewnętrznej.

Jeśli mamy zamiar stworzyć sobie możliwość dodawania pluginów do własnego programu to prawdopodobnie stworzymy sobie interfejs Plugin. I tak na prawdę to tyle całkowicie wystarczy aby uprościć sprawę. Pokażę to “w kodzie”:

Plik Plugin.java:

interface Plugin {
    public String sayHello();
}

Plik MyPlugin.java który będzie ładowany dynamicznie:

class MyPlugin implements Plugin {
    public String sayHello() {
        return "Hello World!";
    }
}

No i teraz jeśli chcemy wykorzystać nasz plugin to wystarczy gdzieś wcisnąć coś takiego:

try {
    Plugin plugin = (Plugin) Class.forName("MyPlugin").newInstance();
    System.out.println(plugin.sayHello());
} catch(Exception e) {
    e.printStackTrace();
}

Jest to znacznie prostsze niż sprawdzanie każdej metody i jej argumentów jednak ma ograniczenie w postaci przymusu implementacji przez ładowaną klasę odpowiedniego interfejsu. No ale nie jest to chyba przeszkoda nie do przejścia

Golden T Game Engine

Postanowiłem wczoraj przetestować jeszcze jeden nieźle zapowiadający się silnik: Golden T Game Engine. Właściwie był to jedyny, który znalazłem (oprócz JGame) oferujący możliwość używania OpenGL jako backendu do renderowania.

Początkowo tutorial dostępny na stronie GTGE był dla mnie “nieprzyjazny” ponieważ ja tylko chciałem zobaczyć trochę kodu i pokombinować. Później jednak zmusiłem się aby go przeczytać i muszę przyznać, że jest to najlepszy tutorial wprowadzający do używania biblioteki jaki w życiu widziałem. Przyczyną tego stanu rzeczy jest niewielka ilość kodu obudowana w dość obszerną dawkę wiedzy na temat wewnętrznego działania konkrentych części silnika. Dzięki temu po przeczytaniu tutoriala znacznie łatwiej połapać się w dokumentacji.

Sama dokumentacja również zawiera przykłady użycia różnych klas. Dzięki temu nie trzeba czytać więcej tutoriali. Na dowód tego napisałem dziś (po raz kolejny) swoją wersję ponga o wiele mówiącej nazwie Jong. Niektórzy z was na pewno znają już to “boisko” Wykorzystałem trochę starej grafiki, ale stworzyłem nowe paletki oraz piłkę.

Podczas pisania nauczyłem się wielu rzeczy o tym silniku i muszę przyznać, że jest to najlepsze z badanych przeze mnie ostatnio wyjść. Najciekawsze jest to, że do rysowania można używać klasy java.awt.Graphics2D! Było to dla mnie miłe zaskoczenie po tym co widziałem w JGame…

Dodatkowo w silniku dostępne są klasy do obsługi różnego rodzaju obiektów tła. Domyślnie mamy dostępne klasy jak ColorBackground, ImageBackground, a nawet takie jak TileBackground, IsometricBackground oraz ParallaxBackground! A jest to tylko część silnika. Na prawdę zachęcam do obejrzenia i przetestowania tej biblioteki gdyż tworzenie gier z jej pomocą to prawdziwa przyjemność

Mała uwaga: Aby używać OpenGL należy ściągnąć ze strony jeszcze GTGE Add Ons. Można je znaleźć na TEJ stronie razem z kilkoma innymi dodatkami takimi jak system GUI dla GTGE.

Na koniec dam wreszcie link do tego Jonga. Nie jest to produkcja na miarę Obliviona czy nawet Mario Bros…. Tak czy inaczej… chodziło bardziej o przetestowanie niż zrobienie czegoś wartościowego Grę można ściągnąć tu:

http://www.mediafire.com/?sharekey=cb92a7ab0b4a9246cb36451a58fbe7c44b232d45b6124d0e

U siebie sprawdziłem działanie na Ubuntu Linux 9.04 oraz Windows XP. Ta wersja jest “domyślną” i nie wykorzystuje OpenGL jednak radzi sobie świetnie w obu systemach.

JGame

Ostatni post napisałem na temat prób pracy z grafiką w czystej Javie bez dodatkowych bibliotek. Okazało się, że proste gry, w których grafiki zbyt wiele nie ma, dadzą się napisać nawet w taki sposób, jednak wszyscy wiemy, ze im szybciej tym lepiej. W poszukiwaniu prędkości rozpocząłem poszukiwania silników i frameworków do gier 2D w Javie. Natrafiłem na projekt SLICK, ale oblał egzamin zaraz po ściągnięciu na dysk – okazało się, że w paczce DLL-ki dla windowsa były, a SO dla Linuxa nie…  Zdegustowany ruszyłem w dalszą podróż…

Następna biblioteka na jaką trafiłem to JGame. Strona internetowa była dość mało zachęcająca, ale trzeba było dać jej chociaż szansę. Obejrzałem ubogą stronę z Tutorialami oraz aplety dla każdego z nich. Chwilę później zaczynałem już “testowanie”.

Już przy pierwszej “próbie” sił zostałem miło zaskoczony. Wrzuciłem na okienko 100 wykorzystywanych wcześniej obrazków PNG 40×40 z kanałem Alpha. FPS wyniósł 60. Nietrudno było się domyśleć, ze to wina v-sync, a nie prędkości. Postanowiłem więc zwiększyć nieco obciążenie dostawiając jeszcze jedno zero, czyli renderując 1000 tych obrazków. FPS wciąż był równy 60. Pomyślałem, że po dostawieniu jeszcze jednego zera efekt już powinien być widoczny. I był… Podczas renderowania 10 000 tych obrazków FPS spadł do ~10.

Kiedy już wiedziałem, ilu obrazków lepiej NIE rysować przyszedł czas aby znaleźć “optymalne” rozwiązanie… Okazało się, że przy 3000 obrazków prędkość umiejscowiła się około ~30 FPS, a to już wystarczy aby gra chodziła w miarę płynnie.

Dodam jeszcze, że wszystko sprawdzałem w rozdzielczości 640×480 oraz 800×600 i wyniki były niewiele gorsze w drugim przypadku.

Javę uruchamiam na moim laptopie z procesorem 2×1,8 GHz i kartą graficzną GeForce GO 7300 z użyciem systemu Ubuntu Linux 9.04. Jak widać da się osiągnąć całkiem zadowalające efekty na komputerach nie będących najnowszymi osiągnięciami techniki.

Pokombinuję jeszcze trochę z JGame bo ciekawie się zapowiada. Oprócz nienajgorszej wydajności oferuje jeszcze wiele “wspomagaczy” do tworzenia gier 2D. Polecam zapoznanie się z tym projektem.

Java 2D – Testy

Obiecałem, że przebadam trochę sprawę tworzenia gier w Javie. Jak dotąd udało mi się stworzyć okno wielkości 640×480 i powrzucać tam troszkę grafiki oglądając malejącą wartość licznika FPS.

Z tą grafiką nie jest wcale tak źle. W Linuksie (gdzie Java chodzi wolniej niż w Windowsie) przy samym czyszczeniu i ekranu FPS wahał się od 1500 do 2000. Wrzuciłem więc na ekran 1000 linii. Dla każdej linii kolor losowany był tuż przed narysowaniem. Dało to piękny efekt migoczących kresek na ekranie z prędkością około 400 FPS.

Następnym krokiem było usunięcie tęczowych linii i zastąpienie ich obrazkiem PNG wielkości 40×40 z kanałem Alpha. Tutaj wydajność już mnie tak nie zaskoczyła gdyż 100 takich obrazków spowodowało spadek wydajności do około 55 FPS.

Postanowiłem więc zmniejszyć nieco swoje oczekiwania i podmieniłem obrazek na JPG (wielkości tej samej i oczywiście bez Alpha ). Okazało się, że 100 takich grafik namalowało się powodując spadek jedynie do około 70 FPS.

Na koniec stworzyłem sobie grafikę 640×480 jako tło i wrzuciłem na okno. Wówczas średnia prędkość rysowania wyniosła około 230 FPS.

Z tego co zaobserwowałem wydajność Javy przy grafice 2D jest porównywalna z wydajnością SDLa, a skoro jest tak i ludzie programują gry z użyciem SDL to dlaczego nie można by programować gier w Javie?

Należy jednak zdać sobie sprawę, z faktu, że sama prędkość rysowania to jeszcze nie wszystko. Pozostaje kwestia samej mechaniki gry. Jeśli będzie ona przeprowadzać wiele obliczeń to ona może się okazać wąskim gardłem całego programu.

Wydaje mi się jednak, że do wielu gier taka wydajność w zupełności wystarczy, a jeśli nie to zawsze można popróbować różnych bibliotek co również zamierzam uczynić