Oczywiście nie znaczy to, że rzucę SC2 w kąt po rozegraniu trzech misji ;P O nie, nie ma mowy. Już teraz mogę bowiem stwierdzić, że mimo podążania za kilkoma nieco denerwującymi trendami w obecnym przemyśle gier (czyli wszechobecnymi achievementami, koniecznością rejestracji online i całymi tymi niby-facebookowymi bajerami), Starcaft 2: Wings of Liberty jest bardzo udaną kontynuacją jedynki.

Tak więc narodowy sport Korei Południowej doczekał się sequela, natomiast blog przynajmniej w tym miesiącu nowej notki na pewno się nie doczeka ;P

Są jednak biblioteki, które "twierdzą", że taka konwencja jest niedobra i proponują inne. Pół biedy, gdy chodzi tu o coś w rodzaju typu HRESULT, do którego w pakiecie dostarczane są makra SUCCEEDED i FAILED. Zupełnie nie rozumiem jednak, co jest pociągającego w pisaniu np.:

Usprawiedliwiać się mogę jednak tym, że... no cóż, to przecież Linux ;-) Ale kiedy dostaję do ręki porządną bibliotekę z klasami, wsparciem dla STL-a i CamelCase w nazwach funkcji, to przecież mogę się spodziewać czegoś rozsądniejszego, prawda? Skąd może mi przyjść do głowy, że rezultat zero ma oznaczać powodzenie wykonania funkcji?!

Najwyraźniej jednak powinienem taką możliwość dopuszczać. Okazuje się bowiem, że nawet dobrze zaprojektowane, estetyczne API może mieć takie kwiatki. Przekonałem się o tym, próbując pobrać wartość atrybutu elementu XML, używając biblioteki TinyXML i jej metody o nazwie QueryStringAttribute. W przypadku powodzenia zwraca ona stałą TIXML_SUCCESS; szkoda tylko, że jej wartością jest... zero ;P
Więc zaprawdę powiadam wam: nie ufajcie żadnej funkcji, której typem zwracanym nie jest bool!

Moje trwające już kilka miesięcy zainteresowanie lojbanem pewnie nie przetrwałoby tak długo, gdyby był on czymś w typie esperanto - a tym, jak wiemy, na pewno nie jest. Przeglądanie jego "formalnej definicji" (czyli The Lojban Reference Grammar) sprawia raczej wrażenie czytania dokumentacji języka programowania, biblioteki lub innego API. Jest to więc całkiem przyjemna lektura :)
Nie zapominajmy jednak, że lojban jest mimo wszystko pomyślany jako język (również) dla ludzi, i to także do - szok! horror! - mówienia. Posiada więc również określone reguły wymowy wyrazów. Są one zresztą określone bardzo dobrze, gdyż niewielki poziom ich skomplikowania nijak ma się do złożonych i nie zawsze jasnych niuansów wymowy języków naturalnych. Można to łatwo zauważyć, kiedy przyjrzymy się im z bliska.

Zacząć wypada od powtórzenia tego, co kiedyś napisałem w pierwszej notce nt. lojbanu. Chodzi o fakt, że w języku tym obowiązuje reguła tak zwanego audio-wizualnego izomorfizmu, co jest uczoną nazwą dla jednoznacznej odpowiedniości między wypowiadanymi głoskami i ich reprezentacją w postaci liter. W lojbanie obowiązuje ona zawsze, co ma niewątpliwe zalety. Konsekwencją jest chociażby brak słów o takiej samej wymowie, lecz innej pisowni, czyli tzw. homonimów (przykłady: bóg/Bug/buk w języku polskim albo np. ware/wear/where w angielskim). Nie występuje też sytuacja odwrotna, czyli różna wymowa przy tej samej pisowni, czego przykładem są pary typu lead ('przewodzić' lub 'ołów'), present ('prezent' lub 'pokazywać'), record ('nagranie' lub 'nagrywać') albo wind ('wiatr' lub 'nakręcać') w języku angielskim.
Krótko mówiąc, w lojbanie nie trzeba uczyć się wymowy poszczególnych słów - wystarczy jedynie znać sposób wypowiadania głosek; słowa są po prostu ich złożeniem. Żeby więc poprawnie mówić w tym języku, trzeba sobie jedynie przyswoić jego alfabet. Oto on:

Zawiera on 26 znaków, ale nie wszystkie są literami w typowym nas sensie (dlatego używa wobec nic raczej lojbańsiego terminu lerfu). Niemniej większość jest, a dodatkowo ich podobieństwo do polskich odpowiedników jest całkiem spore. Reguły wymowy lojbanu przedstawiają się bowiem następująco:

• Samogłoskami są a, e, i, o, u. Można wymawiać je dokładnie tak samo jak w języku polskim.
• y tylko z grubsza można odnieść do polskiego <y> - to bynajmniej nie jest to samo. y to tak zwana szwa - głoska, którą często nieświadomie artykułujemy, gdy chwilowo "brakuje nam słów" (co się czasem zapisuje jako "eee...."). W angielskim jej przykładem jest chociażby samogłoska między 't' i 'l' w nazwie zespołu The Beatles. W języku polskim szwa jako taka nie występuje, ale jej wymowa nie powinna stanowić żadnego problemu.
• Spółgłoski b, d, f, g, k, l, m, n, p, r, s, t, z są wymawiane tak samo, jak po polsku. r może być dowolnie "twarde".
• Co do pozostałych spółgłosek, rzecz ma się nieco inaczej:
  • przede wszystkim, ' (apostrof) nie jest znakiem interpunkcyjnym. Jest on jak najbardziej wymawiany (!) - tak jak polskie <h>. Występuje on tylko między samogłoskami.
  • c wymawiamy jak polskie <sz>
  • j to <ż>, trochę tak jak w języku francuskim (bonjour)
  • v, jak można się domyślić, to <w> (które jest różne od <b>)
  • x to prawdopodobnie najgorsza bestia. Jego polskim odpowiednikiem jest <ch>, ale niestety obecnie różnica między wymową <ch> a <h> jest u większości Polaków właściwie żadna. Stąd najlepiej określić ją jako "twardsze", bardziej "charczące" <h>. Najczęściej podawanym przykładem tej głoski jest 'ch' w szkockim wyrazie loch, oznaczającym jezioro.... Oto przykład dźwiękowy: [x] - życzę połamania gardła ;)
• Samogłoski mogą występować w parach, które wymawia się tak, jakbyśmy się spodziewali w języku polskim. Przykłady: io jako <jo>, oi jako <oj>, au jako <ał>, ii jako <ji>, itp. Wyjątkiem jest ou - ta para w lojbanie nie występuje.
• . (kropka) nie jest znakiem przestankowym, lecz pauzą. Oznaczą krótką przerwę między wypowiadanymi głoskami. Stosuje się ją zawsze, gdy słowo zaczyna się od samogłoski.
• , (przecinek) może rozdzielać wyrazy w obcych nazwach. Nie pełni on funkcji znaku interpunkcyjnego i zasadniczo jest rzadko spotykany.
• Akcent pada zawsze na przedostatnią sylabę, przy czym ewentualne y się tu nie liczy. Mówimy więc np. vacysai ('kolacja'), a nie vacysai.

Proste, prawda? ;-) Żarty żartami, ale niech ktoś spróbuje w podobnie kompaktowej formie streścić zasady wymowy (i pisowni!) języka polskiego... Mam wrażenie, że by się to nie udało :)

Po dawce wiedzy teoretycznej możemy posłuchać próbek dźwiękowych mówionego lojbanu. Na oficjalnej stronie możemy znaleźć ich całkiem sporo. Co nieco można znaleźć też na Youtube, aczkolwiek nie wszystkie mają znaczącą wartość poznawczą :)
Jest tam jednak przynajmniej jeden świetny przykład: la fanza najnimre, czyli The Annoying Orange (Wkurzająca Pomarańcza) z lojbańską ścieżką dźwiękową:

Powszechniejsze wydaje mi się prostsze podejście, w którym assembly dostarcza się w postaci skompilowanej. Zazwyczaj jest to biblioteka .NET-owych, zapisana jako plik .dll, niemający przy tym zbyt wiele wspólnego z natywnymi czy COM-owymi DLL-ami. Wczytanie go jest bardzo proste, gdy wykorzystujemy do tego klasę System.Reflection.Assembly:

Wskazana jest tutaj ostrożność np. w postaci zapewnienia, że każde assembly ładujemy tylko raz. Najlepiej jest wyznaczyć osobny podkatalog na wtyczki do naszego programu i ładować je jednokrotnie, zapewne podczas uruchamiania samej aplikacji.

Gdy mamy już gotowy obiekt klasy Assembly (niezależnie od tego, czy skompilowaliśmy go sami czy wczytaliśmy go z gotowej binarki tak, jak powyżej), chcielibyśmy pewnie jakoś wykorzystać zawarty w nim kod. Są nim oczywiście jakieś klasy, które możemy pobrać metodą GetExportedTypes. Zwróci nam ona metody tablicę obiektów Type, czyli znanej zapewne metaklasy należącej do .NET-owego systemu refleksji. Z nimi zaś zrobić możemy... no, prawie wszystko :) Do interesujących w kontekście pluginów czynności należy przede wszystkim sprawdzenie, czy dana klasa implementuje jakiś ustalony przez nas interfejs "wtyczkowy", a następnie utworzenie jej obiektu:

Takie beztroskie, dynamiczne tworzenie obiektów z binarnego kodu wczytanego już w trakcie działania programu jest jak najbardziej możliwe i, jak widać wyżej, całkiem proste - stosujemy do tego metodę CreateInstance klasy o wdzięcznej nazwie Activator. Wymogiem jest obecność w klasie wtyczki odpowiedniego konstruktora. W powyższym kodzie zakładamy na przykład najprostszy przypadek, iż dostępna jest jego wersja bezparametrowa.

To w sumie wszystko, jeśli chodzi o wczytywanie. To, w jaki sposób plugin może rozszerzać możliwości naszej aplikacji, zależy głównie od zawartości interfejsu, który nazwałem tutaj umownie IPlugin. Projektując go, powinno się zadbać o jego elastyczność i prostotę, a także wziąć pod uwagę chociażby kwestie bezpieczeństwa.

Przy jego pomocy pobranie aktualnej temperatury procesora nie jest trudne. Posługujemy się do tego WMI - Windows Management Instrumentation - które to jest rozszerzeniem modelu sterowników systemu Windows, pozwalającym m.in. na monitorowanie różnego rodzaju informacji diagnostycznych. PowerShell zawiera wbudowane komendy, pozwalające na tworzenie obiektów WMI - wśród nich również takich, które udostępniają informacje na temat temperatury procesora:

Z bliżej nieokreślonych powodów wartość temperatury podawana jest w dziesiątych częściach kelwinów, więc konieczne jest ich przeliczenie na stopnie Celsjusza. Ponadto istnieje też prawdopodobieństwo, że używana tutaj klasa WMI o nazwie MSAcpi_ThermalZoneTemperature nie jest dostępna na naszym komputerze - zależy to prawdopodobnie od modelu jego płyty głównej. W moim przypadku powyższy kod działał bez problemu na komputerze stacjonarnym, lecz nie na laptopie. Może to i dobrze... Mam bowiem uzasadnione przeczucie, że temperatura tamtejszego procesora wcale by mi się nie spodobała ;)

Chcąc "wodne" pole tekstowe umieścić na swojej stronie, możemy skorzystać z jednego z gotowych rozwiązań. Wiele z nich używa jQuery - darmowej biblioteki ułatwiającej pisanie w JS. Jeśli jednak nie korzystamy z niej w innych miejscach strony, to wymaganie jej obecności nie musi się nam podobać. A ponieważ watermark textbox jest efektem łatwym do zakodowania, spokojnie możemy napisać go własnoręcznie. Prześledźmy zatem, jak da się to zrobić.

Definiujemy najpierw styl naszego pola tekstowego, określający jego wygląd podczas wyświetlania wskazówki-znaku wodnego:

Szary kolor jest oczywiście tylko propozycją. Potrzebujemy w każdym razie osobnej klasy CSS, by oznaczać nią te textboksy, które mają wyświetlać znak wodny. Jako wskazówkę będziemy pokazywali początkową wartość pola tekstowego, czyli to co zostało fabrycznie przypisane atrybutowi value elementu input:

To właściwie tyle, jeśli chodzi o statyczny HTML; resztę musimy załatwić JavaScriptem. Interesują nas dwa zdarzenia: zyskania oraz utraty fokusu przez kontrolkę. Są to odpowiednio: onfocus i onblur. (Właśnie za takie nieintuicyjne nazwy "kochamy" JavaScript ;P). W reakcji na pierwsze z nich powinniśmy ukryć nasz szary tekst i pozwolić użytkownikowi na wpisanie nowego. Jeśli jednak tego nie zrobi, to w drugim zdarzeniu wykrywamy, że textbox jest wciąż pusty i ponawiamy wyświetlanie znaku wodnego. Oto procedury zdarzeniowe, które wykonują te czynności:

Jak można zauważyć, rzecz polega na dodaniu lub usunięciu nazwy uprzednio zdefiniowanej klasy CSS z listy klas pola tekstowego. Zakładamy tutaj, że atrybut watermark zawiera jego etykietę, czyli znak wodny. Żeby jednak tak było, musimy go ustawić, przy okazji podpinając (fuj, nie lubię tego słowa) przypisując powyższe funkcje do zdarzeń kontrolki. Czynimy to podczas wczytywania strony:

Przechodzimy po prostu po wszystkich tagach input, szukając zwykłych pól tekstowych (type równe "text"), które mają przypisaną "wodną" klasę CSS. Ustawiamy im następnie m.in. watermark na ich aktualną zawartość.

I właściwie to już wszystko. Okazuje się więc, że czasami JavaScript nie jest taki straszny ;) A jeśli chodzi o działający przykład praktyczny, to można go oglądać gdzieś nieopodal w postaci długo oczekiwanego formularza wyszukiwarki :)

Disclaimer: rozwiązanie testowane na najnowszych wersjach dwóch najsensowniejszych przeglądarek, czyli FF3.6 i IE8. Za Opery, Safari i inne chromy nie ręczę ;P

W bardziej rozsądnych przypadkach da się uniknąć pętli nieskończonych, nawet jeśli od razu nie widać, jak można by to zrobić. I tak odkryłem na przykład, jak można to ładnie zrobić w sytuacji podobnej do poniższej:

Nazywam to pętlą z wyróżnionym startem, bo typowa jej postać, która nie zawiera (pozornie) nieskończonego kręcenia się w kółko, wygląda tak:

Cała zabawa polega na tym, że pierwsze wywołanie SomeFunction może dać niepoprawną wartość w foo. (Może to być jakieś wyszukiwanie w pojemniku i element odpowiadający kluczowy sth nie został w ogóle znaleziony). Sama treść pętli nie może być wtedy wykonana, bo zdarzy się zapewne jakieś nieszczęście. Dlatego trzeba wyodrębnić to pierwsze wywołanie, i oczywiście zadbać także o kolejne. A to daje, jak widać, dublowanie kodu. Chciałoby się to zrobić lepiej.

I można, na szczęście. Możemy za to podziękować feature'owi C++, który często bywa krytykowany jako ułatwiający popełnianie błędów. Bowiem to dzięki temu, że instrukcja przypisania zwraca wartość przypisywaną, możemy to wszystko zapisać tak:

Zdaję sobie sprawę, że dla wielu fakt ten jest równie oczywisty jak pisanie return a == b; zamiast:

ale dla niektórych taka postać pętli for może być zupełnie zaskakująca. Pamiętajmy, że kiedyś (prawie) każdy pisał też i takie ify jak powyżej ;-)

Postulat zastąpienia liczby - chyba najbardziej znanej stałej, występującej w matematyce, fizyce, grafice komputerowej i generalnie każdej dziedzinie wiedzy, mającej cokolwiek wspólnego z liczeniem czegokolwiek - wygląda zrazu na zupełnie szalony. Tym niemniej Manifest Tau zawiera naprawdę sporo argumentów przemawiających za tezą, że jednak jest bardziej użyteczną liczbą i lepiej spełnia funkcję "stałej okręgu" niż jej połówka, czyli . Ich podsumowanie wygląda mniej więcej tak:

1. Definicja jest nienaturalna, bo wykorzystuje pojęcie średnicy okręgu zamiast jego promienia. Promień jest tu lepszy w tym sensie, że okrąg można zdefiniować jako zbiór punktów w równej odległości od swojego środka - odległości równej właśnie promieniowi.
2. we wzorach matematycznych występuje często z czynnikiem 2 - na tyle często, że można stwierdzić, iż właśnie jest ważniejszą wartością niż samo .
3. Standardowa miara kątów płaskich w radianach przypisuje kątowi pełnemu, czyli kątowi jednego obrotu po okręgu. Przy użyciu kąt ten wyraża się jako , co wydaje się znacznie bardziej intuicyjne. Łatwiej jest też podobno wytłumaczyć, że np. ćwiartka okręgu to , a nie .
4. Słynna tożsamość Eulera (  ), łącząca pięć ważnych stałych matematycznych, ma też swój odpowiednik w postaci wykorzystującej : .
5. Wzór na pole koła (  ), w którym występuje z czynnikiem 1, po przepisaniu na staje się podobny do niektórych wzorów fizycznych (zwanych tutaj formami kwadratowymi), jak np. czy .

W oryginalnym artykule argumenty te przedstawione są rzecz jasna w sposób znacznie bardziej pomysłowy, elokwentny i trącący przekazywaniem "oczywistej oczywistości", że się tak kolokwialnie wyrażę :) Trąci też jednak nadmiernym zamiłowaniem do numerologii i przywiązywaniem wagi to takich rzeczy jak czynnik przy jakiejś stałej w tym czy innym wzorze. Lecz nawet jeśli przyjmiemy tę konwencję, to znalezienie przekonujących kontrargumentów wcale nie jest trudne.

Rzekoma nienaturalność definicji wynika głównie z tego, że z niewiadomych przyczyn przyczepiliśmy się do pojęcia okręgu, ignorując istnienie innej figury geometrycznej: koła, czyli okręgu wraz z jego wnętrzem. Koło zaś możemy łatwo zdefiniować jako zbiór punktów odległych co najwyżej o jakieś d, gdzie to d to właśnie średnica. Jeśli jednak bardziej odpowiada nam promień, to też nie ma problemu. Oto ; iloraz pola koła i kwadratu jego promienia to właśnie .
Wszechobecność z czynnikiem 2 w wielu wzorach też jest raczej pozorna, bo zależy głównie od tego, na które wzory akurat patrzymy :) Istnieje bowiem całe mnóstwo przykładów - zarówno matematycznych, jak i fizycznych - na występowanie z innymi czynnikami. Są to chociażby pole powierzchni (  ) i objętość (  ) kuli, prawo Coulomba (  ), stała kosmologiczna (  ) czy też zasada nieoznaczności (  w wersji dla pozycji i pędu). Nie ma więc specjalnych powodów by twierdzić, że użycie w znaczący sposób uprościłoby te formuły.

Ponadto spora liczba wystąpień związana jest z tym, że taka jest właśnie miara kąta pełnego - co jest zresztą kolejnym argumentem przeciwko poczciwej ludolfinie. Pomijając fakt użycia specyficznych dla języka angielskiego sztuczek słownych (przypisanie wyrazowi turn, czyli obrót), wprowadzenie w zastępstwie sprawiłoby przecież, że nagle suma miar kątów w trójkącie i każdym innym nieparzysto-n-kącie stanie się "brzydka", bo równa . Podobny argument o okresie funkcji sinus i cosinus (oba równe ) da się zripostować analogicznym stwierdzeniem dla tangensa i cotagensa, dla których wynosi on okrągłe .
O tożsamości Eulera w postaci trudno natomiast powiedzieć cokolwiek innego niż 'naciągana' - zwłaszcza, że jej odpowiednik z należy do niezwykle powszechnych w matematyce równań o zerowej prawej stronie. Jednak to nic w porównaniu z rzekomym uzasadnieniem, dlaczego jest lepsze od jako wzór na powierzchnię koła. Porównanie do formuł fizycznych w rodzaju wzoru na energię kinetyczną (  ) wydaje się z miejsca przekonujące, o ile tylko zapomnimy o pewnym istotnym szczególe. Otóż wielkości fizyczne mają jednostki (tutaj: kilogramy, metry i sekundy) i to od definicji tych jednostek zależy między innymi to, jakie współczynniki wystąpią w formułach takich, jak powyższa. Wystarczyłoby zamienić odważnik w Sevres na dwukrotnie cięższy (zmieniając definicję kilograma), by nasz wzór na energię kinetyczną stracił czynnik . Podobnej "wady" nie ma oczywiście ani , ani żaden inny wzór geometryczny, bo nie występują w nich działania na wielkościach różnych wymiarów, więc są one niezależne od używanych jednostek.

Wniosek końcowy jest więc taki, że pogłoski o rychłej śmierci są zdecydowanie przesadzone :) Manifest Tau może więc stanowić co najwyżej przykład "kreatywnej matematyki" - analogicznej do sławetnej 'kreatywnej księgowości' - oraz dość osobliwego sposobu postrzegania elegancji w matematycznych formułach. Tym niemniej samego nie powinno się od razu spisywać na straty, bo w przynajmniej jednej dziedzinie stała ta może być faktycznie lepsza od liczby .
Gdzie? Ano spieszę z odpowiedzią, że w... grafice komputerowej, a dokładniej w tych miejscach, gdzie dokonujemy przekształceń obiektów za pomocą obrotów. Trudno zaprzeczyć temu, że wyrażanie kątów za pomocą jest w tej sytuacji o wiele wygodniejsze niż przy pomocy . Trudniej też o pomyłkę w pisaniu:

zamiast:

gdy naszą intencją był półobrót wokół osi X. Definiując więc sobie taką oto stałą:

możemy z tej matematycznej zabawy wynieść wymierną, koderską korzyść :)

Zwłaszcza ostatni pokazuje, że split jest rzeczywiście użyteczną funkcją, mogącą ułatwiać parsowanie formatów tekstowych (zwłaszcza, jeśli daje się ją zastosować wielokrotnie). Warto więc mieć takową w swoim języku/bibliotece. Jak więc przedstawia się jej dostępność na różnych platformach?

Tradycyjnie w .NET i Javie jest dobrze, a nawet lepiej. W obu przypadkach funkcja (a właściwie metoda) Split/split klasy String dodaje nawet trochę więcej możliwości niż to opisałem wyżej. I tak w .NET można podać więcej niż jeden oddzielacz, natomiast w Javie domyślnie może być nim również wyrażenie regularne.
Niektóre języki skryptowe i skryptopodobne też mają się w tym względnie całkiem dobrze. W Pythonie jest metoda split w klasie napisu, natomiast PHP ma funkcję explode, która mimo innej nazwy działa bardzo podobnie.

Ale nie wszędzie funkcja typu split jest od razu dostępna; niekiedy trzeba ją sobie samemu napisać. Przykładem języka, gdzie może być to koniecznie, jest Lua oraz - jakżeby inaczej - C++ :) Ze względu na użyteczność splita często znajdowałem się w sytuacji, gdzie konieczne/wygodne było jego napisanie. Po kilku(nastu?) takich przypadkach doszedłem wreszcie do czegoś podobnego do poniższego kodu:

Na koniec zwrócę jeszcze uwagę na to, że czasami trzeba ostrożnie postępować z rezultatem splitu. Zdecydowana większość wersji tej operacji dopuszcza, by w wynikowej tablicy występowały puste ciągi. Odpowiadają one kilku kolejnym wystąpieniom separatora lub jego obecnością na początku bądź końcu ciągu. Jeśli nie są one nam potrzebne (a rzadko są), to należy je zignorować lub usunąć.

Pod tą nazwą kryję się obiekt, którego zadaniem jest - jak nazwa zresztą wskazuje - zarządzanie różnego rodzaju zasobami gry, gdzie pod pojęciem 'zasobu' kryje się zwykle jakiś element jej contentu: model, tekstura, próbka dźwiękowa, czcionka, shader... Menedżer ma za zadanie udostępniać odwołania do tych zasobów elementom silnika/gry, które ich potrzebują. To jest jego główny, nadrzędny cel.
Tu jednak dochodzimy do małego paradoksu. Jeśli bowiem jest to jedyne przeznaczenie modułu od zarządzania zasobami, to tak naprawdę mogłoby go w ogóle nie być!... W praktyce jego istnienie usprawiedliwia przynajmniej jeden z poniższych powodów:

• jednoczesne załadowanie wszystkich zasobów gry czy nawet pojedynczego etapu/krainy/lokacji/itp. nie jest możliwe z uwagi na ograniczony rozmiar pamięci
• ładowanie zasobów trwa na tyle długo, że rozsądne jest wydzielenie tego procesu do osobnego wątku
• kompatybilność z DirectX w wersjach poniżej 9Ex wymaga obsługi zjawiska utraty urządzenia, a więc ponownego wczytania zasobów umieszczonych w pamięci karty graficznej
• między poszczególnymi zasobami występują zależności, które nie pozwalają na łatwe określenie prawidłowej kolejności ich zwalniania

Tego rodzaju wymagania rzeczywiście można rozsądnie zrealizować dopiero wówczas, gdy w logiczny sposób wydzielimy z kodu część, która za kontrolę zasobów będzie odpowiadać. Jeśli jednak żadna z powyższych sytuacji nie aplikuje się do nas, nie ma żadnego powodu, by zabierać się za tworzenie modułu zarządzania zasobami tylko dlatego, że "przecież zasoby gdzieś muszą być". Coś takiego jak 'prosty menedżer zasobów' to oksymoron: jeśli faktycznie może być prosty, to najpewniej znaczy, iż jest zbędny. No, chyba że pod tym pojęciem rozumiemy też coś, co w praktyce da się zredukować do:

W takim przypadku powinniśmy zadbać przede wszystkich o to, by nasz Menedżer Zasobów (caps intended) dobrze współpracował z Modułem Wyświetlania Życia Gracza, że o Silniku Od Pauzy^TM nie wspomnę ;P