Wspomniane rozwiązanie nazywa się disper i jego strona domowa znajduje się tutaj: http://willem.engen.nl/projects/disper/. Aktualnie najnowsza wersja opatrzona jest numerem 0.3.0, ale działa już bardzo poprawnie. Cały projekt napisany jest w pythonie więc nie ma problemów z kompilacją i miliardem zależności do rozwiązania. Cała instalacja składa się z upewnienia się, że mamy Pythona i narzędzie make. Możemy to zrobić na przykład tak:

$ sudo apt-get install build-essential python2.7

Następnie ściągamy, makeujemy i instalujemy najnowszą wersję dispera (w moim przypadku 0.3.0):

$ wget http://ppa.launchpad.net/disper-dev/ppa/ubuntu/pool/main/d/disper/disper_0.3.0.tar.gz
$ make
$ sudo make install

To tyle jeśli chodzi o instalację. Teraz jak tego używać? Zacznijmy może od wyświetlenia pomocy programu, która już sama mówi wszystko co trzeba wiedzieć:

$ disper -h

Jeśli bardziej lubisz czytać strony man lub info to też są dostępne.

Poniżej przedstawię podstawowe komendy dispera wraz z krótkim opisem:

• disper -l  - powoduje wyświetlenie wszystkich dostępnych monitorów oraz ich rozdzielczości
• disper -s - wykorzystywany jest jedynie pierwszy monitor
• disper -S - wykorzystywany jest jedynie drugi monitor
• disper -e - wykorzystane oba monitory, jeden z nich jest rozszerzeniem ekranu (xinerama)
• disper -c - klonowanie obrazu – na obu monitorach jest to samo
• disper -C - przełącza cyklicznie pomiędzy powyższymi trybami (coś jak Fn+Fx w laptopach [x to liczba od 1 do 12 ] )

Dodatkowo możemy też wyeksportować nasze ustawienia do pliku:

$ disper -p > ekran.conf

Lub zaimportować te ustawienia:

$ cat ekran.conf | disper -e

Jedną poważną zaletą używania dispera jest to, że zmieniamy tryby graficzne i nie musimy restartować serwera Xów. To znaczy po prostu tyle, że uruchomione programy nie zostają ubite w tym procesie i po zmianie ekranu możemy po prostu pracować dalej.

Mam nadzieję, że ten wpis pomoże ludziom trafiającym tu codziennie z problemami dotyczącymi obsługi dwóch monitorów. Oczywiście disper będzie działał w dowolnym innym Linuxie. Wystarczy mieć pythona oraz make’a, a to jest wszędzie.

Z tym postem muszę stwierdzić z zadowoleniem (ale też z lekkim smutkiem), że czasy kiedy siedziało się tygodniami przed Linuxem, żeby coś w nim uruchomić powoli się kończą. Powoli

PS. Jeśli kogoś interesuje dlaczego „z lekkim smutkiem” to spieszę z odpowiedzią. Otóż może i siedzenie i grzebanie było czasami nużące i frustrujące, ale ostateczny sukces dawał ogromny zastrzyk samozadowolenia

Na początek pomyślałem sobie, by napisać plugin do programu Totem. Jest to Linuksowy program do odtwarzania filmów i utworów. Kiedy rozpocząłem swoje poszukiwania odpowiednich tutoriali w tym temacie okazało się, jest z tym raczej krucho. Bardzo słaba dokumentacja i wsparcie od kogokolwiek skłoniła mnie jednak do poszukania czegoś innego.

Jak zwykle w takich sytuacjach pierwsze kroki kieruję w stronę Pythona. Po prostu wiem, że on potrafi zazwyczaj wszystko co potrzeba. W związku z tym, że jakiś czas temu uczyłem się PyQt4 pomyślałem, że może i to przyjdzie mi z pomocą.

Oczywiście nie zawiodłem się Okazało się bowiem, że Qt ma przepiękne wsparcie dla odtwarzania audio/video poprzez Phonon. Po kilku minutach przypatrywania się genialnej dokumentacji Qt (ma świetne przykłady) napisałem kilka linijek w interaktywnej konsoli Pythona i moim oczom ukazało się okienko z odtwarzaniem filmu! Linijki te wyglądały tak:

>>> import sys
>>> from PyQt4.QtGui import QApplication
>>> from PyQt4.phonon import Phonon
>>> app = QApplication(sys.argv)
>>> player = Phonon.VideoPlayer(Phonon.VideoCategory)
>>> source = Phonon.MediaSource(„/sciezka/do/pliku”)
>>> player.setVisible(True)
>>> player.play(source)

W ten sposób na ekranie pojawiło się proste okienko z odtwarzaniem filmu. Przy pomocy tego narzędzia można napisać prosty program, który uruchomiony z linii poleceń rozpocznie odtwarzanie filmu:

import sys
from PyQt4.QtGui import QApplication
from PyQt4.phonon import Phonon

if __name__ == '__main__':    
    app = QApplication(sys.argv)
    app.setApplicationName("Simple Video Player")
    player = Phonon.VideoPlayer(Phonon.VideoCategory)
    
    source = Phonon.MediaSource(sys.argv[1])
    player.play(source)
    player.setVisible(True)
    
    app.exec_()

W taki sposób możemy stworzyć prosty odtwarzacz. To jednak nie wszystko! W pakiecie dostajemy zupełnie za darmo odtwarzanie strumieni sieciowych. Jeśli do MediaSource podamy URL to player po prostu rozpocznie strumieniowanie i odtwarzanie filmu czy pliku dźwiękowego. Oczywiście podając URL statycznego pliku graficznego również ujrzymy go na ekranie. Problem pojawia się jedynie z przezroczystością w plikach PNG, ale do moich zastosowań zupełnie wystarczy mi to co działa dobrze.

Coraz bardziej się przekonuję o tym, że Python+Qt4 to duet nie do zastąpienia. Wszystko o czym pomyślę można osiągnąć pisząc w zasadzie bardzo niewiele linijek i na dodatek wszystko da się uruchomić na różnych systemach operacyjnych. Pięknie!

Wszystko dlatego, że specjalnie nie miałem o czym pisać ponieważ zajmowałem się głównie rzeczami uczelnianymi, a kto chce słuchać o podstawach sieci neuronowych albo javowych technologiach?

W międzyczasie przypatrywałem się grze Minecraft. Mimo tego, że na pierwszy rzut oka wygląda okropnie (w sumie to na każdy następny rzut oka wygląda równie słabo), a gra nie ma za specjalnie celu wielu ludzi nie może zrozumieć dlaczego, w ogóle taka gra istnieje i ma się dobrze… Początkowo też nie byłem przekonany ale po jakimś czasie okazało się, że gra jest niezwykle grywalna! Niemały wpływ na taki stan rzeczy ma fakt, że świat zbudowany z klocków można całkowicie przemodelować przy użyciu kilofa, łopaty i siekiery (które trzeba najpierw sobie zrobić).

Tak czy inaczej nie chciałem zachwalać Minecrafta bo czy ktoś go lubi czy nie to już kwestia indywidualna. Postanowiłem stworzyć coś podobnego do Minecrafta tylko idącego w nieco innym kierunku bardziej skupiając się na drugiej części nazwy – craftingu. Oczywiście zanim będzie można zabrać się w ogóle za tworzenie czegokolwiek potrzebujemy głównie świata, w którym będziemy pracować Bez tego ciężko pozyskać surowce.

W czasie świąt udało mi się zmusić silnik jMonkey Engine 3 do wyświetlania świata złożonego z bloczków. Efekt można podziwiać na poniższym screenie:

W chwili obecnej możliwe jest niszczenie i dostawianie bloków różnych typów. Dodatkowo ostatnim osiągnięciem jest oświetlenie per-blokowe

Oświetlenie zrealizowane jest przy pomocy kolorów wierzchołków, które są mieszane z teksturą przy pomocy prostego pixel shadera. Brakuje tutaj porządnego algorytmu do zaciemniania miejsc zakrytych przed źródłem światła innymi blokami.

Ostatnimi dwiema rzeczami, które potrzebuję do osiągnięcia pełni szczęścia w tej chwili jest utworzenie generatora terenu, który potrafiłby „dogenerować” kawałki terenu jeśli byłby potrzebny oraz zaimplementowanie jakiejś prostej fizyki by móc się poruszać po świecie.

Do tej pory do fizyki używałem zintegrowanego z jME3 silnika fizyki jBullet, ale wydaje się to być trochę wyciąganiem armaty na muchę…. Pomijam już fakt, że przy zmienianiu geometrii świata trzeba też było generować na nowo CollisionShape dla danego kawałka terenu, a to zabiera kilka cennych kwantów czasu co jest niedopuszczalne!

Tak więc… nie leniłem się ostatnio choć może tak to wyglądało kiedy nic nie pisałem :p Jeśli macie jakiś pomysł jak stworzyć generator terenu, który można tu wykorzystać to jestem otwarty na propozycje

Przypuszczam, że w przyszłości pojawi się jeszcze jakiś wpis na temat tworzonego przeze mnie… czegoś

Okazało się to nieco bardziej kombinatorskie ale w końcu się udało Poniżej daję skrypt który pokazuje listę utworków i po wyborze jakiegoś zaczyna go odtwarzać:

#!/bin/bash

if [ -z `pgrep mpd` ]
then
 echo "MPD nie jest uruchomione!"
 exit 1
fi

UTWORY=$(mpc playlist | sed 's/\(.*\)/"\1"/' | awk '{print NR,$0}' )

CMD="zenity --title='Wybór utworu' --width=600 --height=600
 --list --column '#' --column 'Utwór' $UTWORY"
NUM=$(eval $CMD)

if [ -z $NUM ]
then
 exit 0
fi

mpc play $NUM

Tak czy inaczej pomyślałem sobie, że fajnie byłoby móc szybko wybrać sobie szybko playlistę utworów i zacząć ją odtwarzać najszybciej jak się da. Kto lubi czekać aż włączy się program do odtwarzania muzyki? Jasną jest sprawą, że prędkość zależy od programu W tej sprawie Music Player Daemon [MPD] jest nie do pobicia. Głównie dlatego, że jest to jedynie serwer dźwięku bez żadnego graficznego zatem nie ładuje żadnych zbędnych bibliotek. Prawdę mówiąc to działa dokładnie jako serwer i jedyna możliwość jego obsługi to podłączenie się do niego poprzez program klienta. Klientów jest bardzo wiele. W większości są to programy używające jakiegoś ładnego GUI co sprawia, że są wygodne i działają w sumie podobnie do zwykłych programów do odtwarzania audio jak Windows Media Player, Amarok czy Rhythmbox [oraz wiele innych ].

Najbardziej interesujące jest jednak narzędzie konsolowe do obsługi tegoż serwera. Działa natychmiastowo zatem włączenie serwera i rozpoczęcie odtwarzania muzyki to kwestia kilku poleceń. Ale co szybszego jest w odpalaniu konsoli i wklepywaniu poleceń? NIC! Dlatego trzeba to trochę zautomatyzować by było lepiej i wygodniej. Prowadzi do tego bardzo długa droga składająca się z dwóch kroków:

1. Utworzenie pliku uruchamiającego demona mpd (jeśli jeszcze nie działa) oraz wyświetlającego wszystkie nasze playlisty.
2. Dodanie globalnego (dla systemu) skrótu klawiszowego do uruchomienia tego skryptu.

Najpierw należy utworzyć skrypt gdzieś na domyślnej ścieżce wyszukiwania systemu. Ja dodałem do zmiennej PATH katalog ~/.bin dzięki czemu wystarczyło utworzyć plik:

touch ~/.bin/mpdplaylist
chmod +x ~/.bin/mpdplaylist

Do pliku wpiszmy kilka poleceń:

#!/bin/bash

MPDPID=`pgrep mpd`
if [ ! -z $MPDPID ]
then
 echo Uruchamiam mpd...
 mpd
fi

LISTY=`mpc lsplaylists`
LISTA=`zenity --list --text "Proszę wybrać listę:" --column "Listy" $LISTY`

if [ -z $LISTA ]
then
 exit
fi

mpc clear
mpc load $LISTA

mpc shuffle
mpc play

W powyższym skrypcie najpierw sprawdzamy czy jest uruchomiony MPD. Jeśli nie to go uruchamiamy. Jeśli tak to pobieramy wszystkie playlisty oraz wyświetlamy okienko, w którym będziemy mogli wybrać tę do odtwarzania. Jeżeli lista nie zostanie wybrana to nic nie zmieniamy i kończymy skrypt.

Później czyścimy aktualną listę odtwarzania i ładujemy wybraną. Na koniec mieszamy utwory (aby nie słuchać ich zawsze w tej samej kolejności) i uruchamiamy odtwarzanie.

Ostatnim krokiem do szczęścia jest ustawienie globalnego skrótu klawiszowego. W KDE4 należy uruchomić Ustawienia Systemowe > Skróty i gesty >Własne skróty i tam dodać odpowiedni skrót uruchamiający nasz skrypt.

W efekcie otrzymujemy okienko:

WAŻNE: do działania skrypt potrzebuje programu zenity!

Takie rozwiązanie sprawy pozwala niemalże natychmiast rozpocząć odtwarzanie ulubionych utworów. W razie gdybyśmy chcieli posłuchać innej playlisty wystarczy znów wcisnąć skrót i wybrać ją z proponowanych.

Można by jeszcze utworzyć podobny skrypt tylko do wyświetlania wszystkich utworów na danej playliście żeby skoczyć do odtwarzania go. Wówczas dałoby się powiedzieć, że sam system działa jak odtwarzacz multimediów… Zwłaszcza jeśli połączy się go z przełącznikiem utworów na pasku zadań 

Tak czy inaczej samo wykonanie skryptu to jeszcze nie wszystko. Gdybyśmy chcieli mieć w grze wiele różnych obiektów wykonujących kilka zadań w zależności od potrzeb to musielibyśmy dla każdej funkcji pisać osobny plik skryptu. Ani to wygodne, ani eleganckie dlatego też warto było poświęcić wczoraj kilka chwil na zastanowienie się w jaki sposób wywoływać po nazwie funkcje JS z kodu Javy.

Aby to osiągnąć najpierw trzeba załadować skompilowany skrypt tak jak w ostatnim poście.

URL[] urls;
urls = new URL[] { new File('/home/morti/NetBeansProjects/RhinoJS/scripts').toURI().toURL() };
URLClassLoader loader = new URLClassLoader(urls);
Class cl = Class.forName('Base', true, loader);

Script scr = (Script) cl.newInstance();

Następnie należy utworzyć/pobrać kontekst wykonywania oraz przestrzeń:

Context cx = Context.enter();
Scriptable scope = cx.initStandardObjects();

Na stronie o silniku RhinoJS nie rozwodzili się przesadnie nad tym czym jest kontekst ale dość jasno zaznaczyli, że ma on występować jeden na wątek. Na szczęście funkcja enter() załatwia wszystko za nas. Jeżeli w tym wątku nie ma jeszcze kontekstu to zostanie utworzony a jeśli jest to zostanie pobrany i zwiększony jego licznik referencji. Skoro jest licznik referencji to pewnie trzeba też jakoś informować o oddaniu obiektu no i rzeczywiście: mamy metodę Context.exit().

A do czego te przestrzenie? No cóż. Służą one głównie do przechowywania środowiska wykonywania skryptu (np. zdefiniowanych zmiennych oraz ich wartości). Możemy mieć takich przestrzeni ile dusza zapragnie no i dobrze Cała sztuczka polega na tym, że dla każdego obiektu w grze będziemy mieli jedną przestrzeń, która będzie przechowywała stan zmiennych oraz treści funkcji. Za chwilę postaram się wytłumaczyć dlaczego tyle tych scopów będziemy potrzebować. Najpierw jednak dam następny fragmencik kodu:

scr.exec(cx, scope);

Być może dla niektórych jest już jasne dlaczego potrzebujemy wiele przestrzeni. Napiszę jednak, aby wszyscy mogli wyciągnąć z tego tekstu wartościowe informacje Jak widzimy powyżej należy wykonać załadowany skrypt. Trzeba wykonać ten krok aby zdefiniować w przestrzeni funkcje. Jeśli będziemy mieli wiele obiektów używających skryptów tej samej postaci (z tymi samymi nazwami funkcji) to gdybyśmy zdefinoiwali je wszystkie w jednej przestrzeni to tylko funkcje ostatniego skryptu byłyby wykonywane dla wzsystkich gdyż nadpisałyby one definicje poprzednich skryptów. Dlatego każdy obiekt w grze powinien mieć włąsną przestrzeń wykonywania skryptu.

Jak dotąd w sumie zrobiliśmy to samo co w ostatnim poście z tą różnicą, że dziś na tym nie skończymy No i oczywiście opisałem nieco znaczenie kilku wymaganych linijek. W całym kodzie trzeba oczywiście jeszcze umieścić odpowiednie bloki try{..} catch(…) ale nie używam tego tutaj ponieważ utrudniłoby to tylko czytanie przykładów.

Ostatnią rzeczą, którą trzeba wykonać jest pobranie obiektu funkcji z przestrzeni oraz wywołanie jej z podaniem parametrów:

Object fObj = scope.get('NazwaFunkcji', scope);
if(fObj instanceof Function) {
	Function f = (Function)fObj;

	result = f.call(cx, scope, scope, new Object[] {'Argument1', new Integer(44), arg3});
	System.out.println('Result: ' + result);
}

Powstaje naturalne pytanie dlaczego podajemy aż 2 razy scope skoro na zdrowy rozum możnaby go nie podawać wcale! Pobraliśmy przecież obiekt z tej przestrzeni więc o co tu chodzi. No cóż. chcąc być do końca szczerym to powiem, że nie zagłębiałem się w te przestrzenie tak mocno aby potrafić udzielić zadowalającej odpowiedzi. Mogę jedynie wkleić opis z dokumentacji:

java.lang.Object call(Context cx,
                      Scriptable scope,
                      Scriptable thisObj,
                      java.lang.Object[] args)

    Call the function. Note that the array of arguments is not
    guaranteed to have length greater than 0.

    Specified by:
        call in interface Callable

    Parameters:
        cx - the current Context for this thread
        scope - the scope to execute the function relative to.
                This is set to the value returned by getParentScope()
                except when the function is called from a closure.
        thisObj - the JavaScript this object
        args - the array of arguments
    Returns:
        the result of the call

Być może komuś pryda się opisany tutaj sposób na wywołanie funkcji ze skompilowanych skryptów JavaScript. Może ktoś wie coś więcej i potrafi dodać coś do tematu? Ja z pewnością skorzystam z umiesczenia tutaj tego przykładu bo nie będę musiał go szukać w kodzie

Na początku było tak, że za każdym razem przy uruchamianiu aplikacji kompilowałem skrypty. Myślałem wówczas, że tworzenie interpretera i kombinowanie da się później wyeliminować kompilując skrypty do plików *.class. Tak się niestety nie stało.

Ostatnio usiłując poprawić czas uruchamiania aplikacji skompilowałem najpierw te kilka skryptów testowych do plików binarnych klas Javy i spróbowałem je załadować zupełnie pomijając tworzenie obiektu klasy PythonInterpreter. Życie nie okazało się jednak łaskawe i jak się okazało Jython utworzył mi klasę NazwaKlasy$py.class. Wszelkie próby załadowania tej klasy bez użycia Jythona skończły się niepowodzeniem… Sam Jython oczywiście potrafił bez problemów wczytać ten plik ale zajmowało to tyle samo czasu ile wcześniej (ok. 5 sekund), zatem startowanie aplikacji nie przyspieszyło.

Postanowiłem zatem poszukać pomocy gdzie indziej – zmienić język skryptowy. Po krótkim poszukiwaniu stwiedziłem, że chyba najbardziej trafnym językiem skryptowym dla Javy będzie.. JavaScript
Szybko zabrałem się za pisanie testowych skryptów i kodu uruchamiającego. Kiedy opanowałem samo wykonywanie, przyszedł czas na kompilację i ładowanie. Po kilkudziesięciu minutach z dokumentacją i przykładowymi kawałkami kodu udało mi się stworzyć program kompilujący plij *.js do pliku *.class. Okazało się to być znacznie prostrze niż przypuszczałem gdyż wystarczył taki fragmencik:

String script = readSource("scripts/base.js");
CompilerEnvirons env = new CompilerEnvirons();
ClassCompiler classCompiler = new ClassCompiler(env);
Object[] classes = classCompiler.compileToClassFiles(script, "scripts/base.js", 1, "Base");

I tyle! Funkcja readScript(..) wczytuje oczywiście z pliku kod skryptu. Wówczas tablica obiektów classes zawiera nazwy klas oraz skompilowane wersje binarne następujące kolejno po sobie. Wystarczy już tylko wpisać dane do odpowiednich plików *.class:

for(int i=0; i < classes.length; i+=2) {
 String name = (String)classes[i];
 byte[] bytes = (byte[])classes[i+1];

 File out = new File("scripts/" + name + ".class");
 FileOutputStream os = new FileOutputStream(out);
 os.write(bytes);
 os.close();
}

Wersja binarna może być już łatwo odczytana przez Javę:

URL[] urls = new URL[] { new File("/path/to/scripts").toURI().toURL() };
URLClassLoader loader = new URLClassLoader(urls);
Class cl = Class.forName("Base", true, loader);

Na koniec aby wykonac skrypt można utworzyć obiekt przy pomocy klasy oraz wywołać funkcję exec():

Script scr = (Script) cl.newInstance();
Context cx = Context.enter();
Scriptable scope = cx.initStandardObjects();
scr.exec(cx, scope);

Na zakończenie powiem tylko, że czasowo kompilacja kilku skryptów nie robi praktycznie żadnej różnicy w działaniu programu. Jest to zatem duży plus dla silnika JavaScriptu od Mozilli Warto również dodać, że nie traci się spejcalnie na funkcjonalności ponieważ z poziomu skryptów JS można również korzystać z klas Javy

Później napiszę jeszcze jak ze skryptu wywoływać konkretne funkcje, bo to w sumie nadaje się na osobny wpis

Powód nie-pisania ostatnio oraz tego, że piszę teraz jest w zasadzie ten sam – egzamin dyplomowy. Dziś miałem okazję przystąpić do ustnej wersji egzaminu licencjackiego z wynikiem całkiem zadowalającym – 4,5. Egzamin taki jest moim zdaniem strasznie dziwnym tworem ponieważ powodzenie i porażka zależą tylko i wyłącznie od naszego szczęścia w losowaniu pytań. U mnie nawet nie było losowanie. W zasadzie po wejściu do sali otrzymywało się kartkę z trzema pytaniami. Jakkolwiek dziwny i niesprawiedliwy system oceny wiedzy by nie był to na (nie)szczęście do gry wchodziła jeszcze średnia z całych studiów.

Ostatecznie nie taki diabeł straszny… Choć spędziłem ostatnie dwa tygodnie siedząc całe dnie i powtarzając 3 lata nauki. Na szczęście teraz mam już wreszcie zasłużone (mam nadzieję, że nikt nie ma innego zdania) wakacje A po wakacjach na studia drugiego stopnia i znów cyrk

Chciałbym wam obiecać, że będę pisał częściej ale nie jestem pewien czy nie byłoby to okrutne kłamstwo dlatego też nic nie napiszę Mam trochę rzeczy do nadrobienia przez ostatnią nieobecność w życiu publicznym i prywatnym na rzecz wzorów i definicji.

Uf.

Wiele prawdy jest we wspomnianym artykule, jednak wydaje mi się, że to czy ktoś da się złapać w pułapkę czy nie zależy jedynie od niego samego. Tarczą obronną powinna być skromność, chęć do dalszej nauki oraz doskonalenia technik. Z programowaniem jest jak z majsterkowaniem. Pierwsza rzecz to posiadanie narzędzi (technik), a druga to ich umiejętne wykorzystanie. Niestety umiejętność taką nabywa się z całymi tysiącami linii złego kodu

Jeszcze innym problemem jest rozumienie swojej pracy. Każdy człowiek, który ma do wykonania jakąkolwiek pracę, powinien zawsze pamiętać o tym co jest celem tej pracy. Inaczej możemy osiągnąć coś takiego:

Powszechne jest przekonanie o tym, że programista pisze kod. Nie jest to jednak prawda. Programista pisze program. Dla ludzi. Często nie związanych ani trochę z informatyką. Wydaje mi się, że często bywa tak, że koder poświęca więcej uwagi temu aby kod był piękny niż temu, żeby tworzone narzędzie było użyteczne. Oczywiście nie mówię, że jakikolwiek kod jest dobry Kod powinien być tak dobry jak się da. Problem w tym aby wybrać złoty środek. Taki złoty podział pomiędzy jakością kodu, a jakością programu, ponieważ nie zawsze idą one w parze

Wracając do wspomnianego na początku artykułu: nie mogę się jednoznacznie przyporządkować do żadnej z tych grup. Pewnie, że niektóre opisane tam rzeczy brzmią znajomo Mimo to problem autora leży w pewności siebie. Ja nigdy takiej pewności nie miałem i zawsze podchodziłem do swoich rozwiązań z pewną nieufnością sądząc, że da się to zrobić lepiej. Oczywiście zazwyczaj miałem rację Patrzę teraz na kod pisany zaledwie rok czy dwa lata temu i już widzę, że był słaby. Zapewne patrząc za rok na kod, który piszę teraz również zobaczę, że można było lepiej. No cóż… Taka już rola różnych doświadczeń

Idea jest dość prosta, a jej zastosowanie daje duże możliwości. Jeśli ktoś nie jest jeszcze zapoznany z entities to proponuję jak najprędzej przeczytać wspomniany artykuł pod adresem:

http://slick.cokeandcode.com/wiki/doku.php?id=entity_tutorial

Zastanawiam się tylko jak to jest możliwe, że zajmując się dość intensywnie (swego czasu) próbami napisania różnych gier i poszukiwaniu jak najlepszych sposobów na to, nigdy nie natrafiłem na żadne informacje dotyczące encji w grach. Może jest to coś o czym warto by wytworzyć artykuł na Warsztacie?