Monthly archive for November, 2007

Wielokąty radarowe

2007-11-12 9:28

Dane liczbowe przedstawiać można na wiele sposobów. Najbardziej kompletnym jest zwykle tabelka, ale o wiele ładniejszą jest odpowiedni wykres. Czasem sztuką jest dobrać jego odpowiedni typ, gdyż rodzajów wykresów jest wbrew pozorom bardzo dużo. Jeżeli ktoś nie wierzy, niech sprawdzi w dowolnym arkuszu kalkulacyjnym :)

Radarowy wykres powierzchniowy w grze StepmaniaJednym z ciekawszych jest wykres radarowy. W nim ze środka wykresu na zewnątrz wypuszczone są osie (różna może być ich liczba), na których z kolei zaznaczone są wartości. W najprostszej wersji wygląda to jak pajęczyna z napaćkanymi punktami i w sumie nie jest specjalnie sugestywne.
Ciekawiej zaczyna się robić, jeżeli punkty na poszczególnych osiach połączymy ze sobą i zamalujemy wnętrze tak powstałego wielokąta. Jeżeli bowiem wartości na osiach przedstawiają pewne właściwości jednego obiektu lub zjawiska, to powstała figura niejako opisuje go w sposób całościowy. Weźmy na przykład taki wykres, w którym w subiektywny sposób ocenimy sobie różne charakterystyki jakiegoś hipotetycznego kawałka kodu źródłowego:

Radarowy wykres powierzchniowy cech kodu

Figura taka ma jeszcze jedną istotną cechę: powierzchnię. Na pierwszy rzut oka dość ciężko określić, w jaki sposób zależy od wartości na poszczególnych osiach. Czy na przykład gwałtowny wzrost jednej zmiennej przy identycznych wartościach pozostałych da ostatecznie większe pole wielokąta niż równomierny przyrost na wszystkich osiach?
Nie jest to oczywiste i dlatego wydaje się całkiem interesujące :) Naturalnie znając wszystkie wartości, rzeczone pole policzyć jest bardzo łatwo.

Dlaczego jednak wspominam o tym wszystkim? Otóż uważam, że gry w których przedstawia się graczowi bardzo dużo danych – a więc na przykład ekonomiczne, strategiczne czy RPG – są zwykle dość ubogie pod względem sposobów prezentacji tych danych. Prawie zawsze królują w nich nieśmiertelne tabelki i czasami tylko jakieś wykresy liniowe czy słupkowe.
A przecież można by nieco się wysilić i zafundować graczowi jakąś bardziej atrakcyjną formę. W końcu jeśli ktoś nie lubi odmóżdżających strzelanek to jeszcze nie znaczy, że uśmiecha mu się wpatrywanie się w rzędy numerków ;P

Tags: , ,
Author: Xion, posted under Games, Programming, Thoughts » 3 comments

ColorShop 2.2

2007-11-10 20:55

ColorShop 2.2Zgodnie z zapowiedzią, zamieszczam ukończoną kilka dni temu, nową wersję programu ColorShop. Nowości jest mnóstwo, cały program został oczywiście napisany od nowa (tym razem w C#) i naturalnie gorąco zachęcam do jego obejrzenia :) Powinien okazać się przydatny grafikom i webmasterom, ale także programistom grafiki.

File: ColorShop 2.2  ColorShop 2.2 (116.2 KiB, 3,267 downloads)

Tags:
Author: Xion, posted under Applications, Website » 14 comments

Bolączki C++ #6 – Obsługa zdarzeń

2007-11-09 23:46

Dzisiaj w programowaniu aplikacji obowiązują dwie proste i fundamentalne zasady. Po pierwsze, programujemy obiektowo i kod zamykamy w klasy z polami i metodami. Po drugie, tworzymy programy działające w środowisku graficznym, z okienkami, przyciskami, polami tekstowymi i innymi klasycznymi elementami interfejsu.
Jednak jeden plus dwa równa się kłopoty, przynajmniej w C++. Już raz narzekałem zresztą na to, że w tym języku obiektowość i GUI to nie jest najlepsze połączenie. Zgrzyta tu mechanizm obsługi zdarzeń generowanych przez interfejs graficzny.

Wcześniej napisałem, że możliwym rozwiązaniem problemu jest zasymulowanie w jakiś sposób delegatów, czyli – z grubsza – wskaźników na metody obiektów. To jedna z dróg radzenia sobie z kwestią obsługi zdarzeń. Ale też inna, wykorzystująca mechanizm metod wirtualnych i polimorfizmu. Polega to na zdefiniowaniu jednolitej klasy bazowej dla obiektów, które mają odbierać zdarzenia. Zwie się je zwykle event handlers, co jak zwykle nie ma dobrego tłumaczenia. Taki handler wyglądać może na przykład tak:

  1. class IEventHandler
  2. {
  3.    public:
  4.       virtual void OnClick(IControl* pSender) = 0;
  5.       virtual void OnKeyDown(IControl* pSender) = 0;
  6.       // itd.
  7. };

Mając jakiś element interfejsu użytkownika, np. przycisk, przekazujemy mu nasz własny obiekt implementujący powyższy interfejs. Metody tego obiekty są następnie (polimorficznie) wywoływane w reakcji na odpowiednie zdarzenia.
Tak oczywiście można robić w C++, ale nie jest to zbyt wygodne. Tym czego znów brakuje, to niestatyczne klasy wewnętrzne, obecne choćby w Javie, których brak w C++ nie da się do końca zastąpić wielokrotnym dziedziczeniem.

Albo delegaty, albo sposób opisany przed chwilą – zapewne nie ma żadnej innej drogi obiektowej obsługi zdarzeń. Niestety, żaden z tych sposobów nie jest obecnie wspierany w C++ i nie zanosi się, by miało się to wkrótce zmienić.

Tags: , , ,
Author: Xion, posted under Programming » 2 comments

Tu byłem?…

2007-11-08 21:05

Chyba czas się opatentować. Rozumiem, że mogę mieć czasem kłopoty z doborem przeróżnych loginów czy innych identyfikatorów, że o domenach czy adresach e-mail nie wspomnę. Wiadomo, że Internet zatacza coraz szersze kręgi. To wszystko można zaakceptować, ale co da się powiedzieć o tym:

Xion na ścianie ;]

Pic na wodę, fotomontaż? Nie, autentyczne zdjęcie pewnego krakowskiego muru, wykonane przez kolegę Asmodeusza. Sam nie wiem, co mam o tym myśleć :)


Author: Xion, posted under Internet, Life » 3 comments

Sponsorowany sklep z kolorami

2007-11-07 22:22

Kiedyś nazywało się ich mecenasami, a dzisiaj częściej sponsorami. Składali oni u artystów zamówienia na określone dzieła, a w zamian potrafili porządnie sypnąć groszem. W ten sposób powstała duża część podziwianych do dzisiaj wytworów sztuki, z których większość nosi widoczne ślady dostosowywania się do wymagań dawnych sponsorów.
Programowanie może i nie jest sztuką (choć tutaj można by długo dyskutować), ale podobne relacje chyba i tutaj obowiązują. Przede wszystkim chodzi tutaj o komercyjne wytwarzanie oprogramowania, kiedy to klient określa swoje oczekiwania i płaci później za gotowy produkt, jeśli ten je spełnia. Ale nie tylko; otóż przypadkowo odkryłem też zupełnie inną formę “sponsorowania”, gdzie pieniądze w ogóle nie wchodzą w grę…

Sprawa dotyczy programu ColorShop, który to w przypływie natchnienia popełniłem ponad cztery lata temu. Kilka miesięcy wpadłem na pomysł jego poważnego udoskonalenia i sporządziłem nawet kawałek czegoś, co można nazwać wstępną dokumentacją… Ale, jak wiadomo, koder ma dziesięć pomysłów na sekundę, zatem także i ten został odłożony na półkę i szansa na jego realizację nie była zbyt duża.
Aż tu nagle dowiaduję, że w ramach jednego z przedmiotów w bieżącym semestrze (o wiele mówiącej nazwie Programowanie w technologii .NET) jest napisanie średniej wielkości aplikacji, wykorzystującej takie-a-takie elementy .NET Framework. Zamiast więc pisać kolejną pseudobazę jakichś niby-danych, pomyślałem więc, że mógłbym wziąć ten właśnie projekt. I tak zrobiłem.

Screen z nowej wersji programu ColorShopNie obyło się jednak bez większych i mniejszych modyfikacji i usprawnień, koniecznych aby program spełniał wymagania co do użytych technologii. Trudno powiedzieć, jak wpłynęły one na jego ostateczną postać, ale jedno jest prawie pewne: bez tego program miałby spore szanse nigdy nie powstać. Mogę więc spokojnie powiedzieć, że uczelnia w tym momencie zasponsorowała go – nie pieniędzmi, ale właśnie motywacją potrzebną do jego ukończenia. W końcu nic tak nie zachęca do pracy jak perspektywa zaliczenia jakiegoś przedmiotu ;)

A co do samego programu, to właściwie pozostało już tylko kilka mało programistycznych czynności końcowych, potrzebnych aby ColorShop 2.2 mógł zostać opublikowany w sieci – co powinno się niebawem stać.

Tags:
Author: Xion, posted under Applications, Programming, Studies » 1 comment

Grubo zapakowane I/O

2007-11-06 12:02

W każdym języku programowania potrzebny jest system wejścia/wyjścia. To zresztą bardzo często wykorzystywana jego część, więc powinna charakteryzować się wysoką jakością. Chcielibyśmy mianowicie nie tylko tego, aby I/O było szybkie. Powinno być też elastyczne i proste w obsłudze. Czasami udaje się te wymagania pogodzić w całkiem zadowalający rezultat, a czasem nie.

Weźmy na przykład Javę. Posiada ona bardzo rozwinięty system wejścia/wyjścia, umożliwiający odczyt i zapis z wielu różnych źródeł: ekranu, plików, gniazdek sieciowych, potoków łączacych wątki, itp. Ponadto komunikacja może odbywać się na wiele sposobów: mamy na przykład dość “surowe” strumienie, nieco bardziej użyteczne czytacze (readers) i zapisywacze (writers), a także kanały (channel) i bufory (buffers).
Cały system wydaje się zatem bardzo zaawansowany. Niestety, w praktyce jest on zdecydowanie przerośnięty, a poza tym charakteryzuje się pewną ‘ciekawą’ cechą – nazwijmy to – projektową. Osobiście uważam, że twórcy Javy w tym momencie przedobrzyli i chcąc zastosować bardzo elastyczny w założeniu wzorzec Dekorator, stworzyli interfejsowy koszmarek. Wspomniany wzorzec polega na kolejnym “opakowywaniu” obiektów tak, aby rozszerzać ich możliwości; obiekt ‘zewnętrzny’ nie musi przy tym wiedzieć dokładnie, czym jest obiekt ‘wewnętrzny’. I tutaj rzeczywiście tak jest, lecz na nieszczęscie sami musimy zawinąć obiekt w te wszystkie warstwy.
Przykład? System.in, czyli strumień standardowego wejścia, w swej pierwotnej postaci jest niemal zupełnie bezużyteczny. Żeby zrobić z nim cokolwiek sensownego (np. odczytać linię tekstu), musimy najpierw opakować go do postaci odpowiedniego czytacza:

Podobnie jest chociażby z plikami. Za każdym razem musimy ubrać nasz obiekt na cebulkę, aby był on przydatny, przechodząc przy okazji przez cały arsenał bardzo różnych klas, od których jest wręcz gęsto w JDK.
Trzeba aczkolwiek przyznać uczciwie, że System.IO z .NET też zawiera całe mnóstwo różnych klas. Tam konieczność podobnego opakowywania zachodzi jednak o wiele rzadziej, gdyż interfejsy tych klas są trochę inteligentniejsze.

A co ze “staroświeckimi” językami, jak C++ czy Delphi? No cóż, w nich operuje się głównie pojęciem uniwersalnych strumieni i w zasadzie niczego więcej. Nie trzeba ich jednak niczym otaczać, bo fabrycznie potrafią już chociażby operować na podstawowych typach danych, a nie tylko ciągach bitów. Niby to mniej elastyczne i nie tak “obiektowo czyste”, ale o ile przyjemniejsze w użyciu.

Tags: ,
Author: Xion, posted under Programming » 3 comments

Właściwy balans

2007-11-02 22:24

Podobno nie ma głupich pytań, są tylko głupie odpowiedzi. Być może to rzeczywiście jest prawda. Jako moderator forum Warsztatu już nieraz widziałem wątki, które na pierwszy rzut oka nadawały się do eliminacji, ale akurat jakimś dziwnym zrządzeniem losu nie przykuły uwagi żadnego przedstawiciela służb porządkowych i zdążyły się rozrosnąć. Jaki był często skutek? Otóż zamieniały się one w całkiem rzeczowe dyskusje, chociaż – trzeba to przyznać – zazwyczaj trochę niezwiązane z początkowym tematem. Na pewno jednak zasługiwały na dalsze istnienie.
Z tej przyczyny jestem teraz chyba nieco bardziej tolerancyjny niż kiedyś. Zdarza się, że nawet jeśli mam uzasadnione podejrzenia (jak to ktoś ładnie nazwał: “przypuszczenie graniczące z pewnością” ;)), iż z danego wątku nie wyniknie nic dobrego, staram się nie kierować tym pierwszym wrażeniem. Aczkolwiek już ponad rok zajmuję się moderowaniem forum Warsztatu i pewnie daje mi to jakieś doświadczenie pozwalające dokonywać takich intuicyjnych przewidywań.

Zamiast (przed)wczesnych interwencji skłaniam się więc raczej do postawy wyczekującej. Można mi więc zarzucić, że zawsze czekam, aż problemami zajmie się ktoś inny. Albo że – mówiąc dosadniej – pośrednio pozwalam, by forum zalała fala lamerstwa. Ale to chyba nie jest takie proste. Prawdopodobnie bowiem każdy ma inne wyobrażenie tego, jakie wątki powinny się na forum pojawiać, a jakie nie, i oczywiste jest, że wszystkim dogodzić nie można. Plan minimum to eliminacja tych niepożądanych zachowań, co do których nikt nie ma żadnych wątpliwości. Lecz by robić coś więcej, potrzebna jest odpowiednia równowaga między restrykcyjnością a tolerancją.

Niełatwo ją znaleźć. Ale gdyby było inaczej, nie mógłbym co jakiś czas utyskiwać nad ciężką dolą moderatora ;]

Tags: ,
Author: Xion, posted under Thoughts » 3 comments
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.