Archive for Programming

Fragmenty a piksele

2008-04-22 22:25

W terminologii DirectX programowalny potok graficzny ma dwie ważne części: vertex shader i pixel shader. Nazwa tej drugiej jest zasadniczo trochę myląca. Sugeruje ona, że shader jest wykonywany dla każdego piksela na ekranie, co tak naprawdę jest dalekie od prawdy.
Tak naprawdę bowiem “piksele” te są dopiero kandydatami do zapisania w buforze tylnym. Po drodze mają bowiem wiele okazji na to, aby być całkowicie wyeliminowane z renderingu. Może to się stać z któregoś z poniższych powodów, które jednak nie wyczerpują wszystkich możliwości:

  • Test alfa. W przypadku włączenia tego rodzaju testu, możliwe jest odrzucenie “pikseli”, których wartość kanału alfa nie jest dostatecznie duża. Zwykle jako wartość porównawczą wykorzystuje się 127, 128 albo domyślnie 0. Nie zawsze można sobie oczywiście pozwolić na takie skwantowanie informacji o przezroczystości, ale ma ono niebagatelną przewagę wydajnością nad alpha-blendingiem.
  • Test głębi. To najbardziej oczywisty test, a związany jest z przesłanianiem obiektów. W wielu przypadkach możliwe jest wykonanie go przed pixel shaderem, lecz w określonych sytuacjach może być konieczne testowanie już przetworzonych “pikseli”. W zależności od powodzenia testu wartość głębi zapisana w buforze może być oczywiście uaktualniona, co wpływa na dalsze testy.
  • Test stencila. Test wykorzystujący stencil buffer jest sprzężony z testem głębi, wobec czego podlega podobnym ograniczeniom. W szczególności możliwe jest na przykład zapisanie innej wartości do wspomnianego bufora w zależności od tego, czy “piksel” wyłoży się na teście głębi czy stencila.

A zatem wyjście pixel shadera niekoniecznie musi bezpośrednio trafić na ekran. Nie powinniśmy więc brać liczby pikseli w buforze ekranu za średnią liczbę wywołań tego shadera, a już na pewno nie jako górną granicę.
Dlatego też trzeba przyznać, że używana w OpenGL nazwa ‘fragment program‘ jest o wiele lepsza niż ‘pixel shader’. Fragment (wyjście shadera) nie jest bowiem jeszcze pikselem, a jedynie kandydatem na niego, który może odpaść przy wielu okazjach.

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

Pomijanie klawiszy w C#

2008-04-21 19:50

Czasami dobrze jest reagować na wszystkie przychodzące do okna wciśnięcia klawiszy w jednym miejscu. W C# ustawia się wtedy właściwość KeyPreview dla formy. Sprawia to, że dostaje ona zdarzenia klawiatury niezależnie od tego, która z potomnych kontrolek ma aktualnie fokus. Dzięki temu można implementować polecenia aktywowane wciśnięciami określonych klawiszy lub ich kombinacji, których nie da się przypisać np. do skrótów klawiszowych w menu:

  1. private void MainForm_KeyDown(object sender, KeyEventArgs e)
  2. {
  3.     switch (e.KeyCode)
  4.     {
  5.         case Keys.Oemtile:
  6.             // tylda - pokaż/ukryj konsolkę
  7.             txtConsole.Visible = !txtConsole.Visible;
  8.             break;
  9.     }
  10. }

Jeśli jednak nic w tej kwestii nie zrobimy, zdarzenia klawiatury domyślnie i trafią do kontrolki aktywnej, co niekoniecznie musi nam się podobać. W powyższym przykładzie nasza prosta konsolka “złapałaby” na przykład wszystkie wciśnięcia klawisza tyldy jako znaki ~.
Jak temu zapobiec? Wystarczy wykorzystać właściwość SuppressKeyPress z klasy KeyEventArgs:

  1. e.SuppressKeyPress = true;

To sprawi, że zdarzenie wciśnięcia klawisza nie będzie przekazywane dalej i żadna kontrolka go nie otrzyma. To przydatne, jeśli mamy ręcznie zakodowane skróty klawiszowe, które pokrywają się ze standardowymi sekwencjami.

Tags:
Author: Xion, posted under Programming » Comments Off on Pomijanie klawiszy w C#

Być albo nie być

2008-04-18 20:08

W programowaniu relacja ‘jest’ najczęściej oznacza możliwość potraktowania pewnej wartości (lub ogólniej: obiektu) jako należącego do określonego typu (klasy). Od kiedy wynaleziono dziedziczenie, obiekty mogą być polimorficzne – czyli być traktowane tak, jakby należały do kilku różnych typów danych. Dwa proste przypadki obejmują: zwykłe dziedziczenie publiczne, gdy obiekt klasy pochodnej jest też obiektem klasy bazowej, oraz implementowanie abstrakcyjnych interfejsów.

Czasami jednak to, co w związku ze słówkiem ‘jest’ bywa intuicyjne, nie zawsze sprawdza się w praktyce. Tak jest chociażby wtedy, gdy bierzemy pod uwagę:

  • Dziedziczenie prywatne. Ten rzadko spotykany typ dziedziczenia (obecny w C++) sprawia, że choć obiekt klasy pochodnej jest nadal obiektem klasy bazowej, to wie o tym tylko on sam. Dlatego nie jest możliwe bezproblemowe rzutowanie w górę, które dla dziedziczenia publicznego jest przeprowadzane automatycznie. Mimo tego nadal mamy do czynienia z normalnym dziedziczeniem i jeśli przy użyciu jakichś brzydkich sztuczek (czyli na przykład reinterpret_cast) skonwertujemy odwołanie do obiektu na odwołanie do klasy bazowej, będziemy mogli z niego poprawnie skorzystać.
  • Kolekcje obiektów.Teoretycznie zbiór obiektów typu B jest też zbiorem obiektów typu A, jeśli typ B jest rodzajem typu A (np. klasą pochodną). W praktyce jednak kolekcja może się zmieniać, a przy traktowaniu jej w sposób bardziej ogólny istnieje możliwość dodania do niej obiektów będących wprawdzie typu A, ale nie mających nic wspólnego z B.
    Stąd też wynika fakt, że w językach programowania nie można ot tak sobie rzutować pojemników na takie, które przechowują “bardziej ogólne” obiekty. Jeśli więc chcemy zmienić np. List<string> na List<object> w C#, musimy świadomie wykonać kopię pojemnika.
  • Niewirtualne wielodziedziczenie. W bardziej skomplikowanych przypadkach, gdy klasa ma więcej niż jedną klasę bazową, mogą się pojawiać problemy z niejednoznacznością. Jeżeli bowiem idziemy w górę więcej niż dwa pokolenia, może mieć znaczenie ścieżka w grafie dziedziczenia, którą przy okazji obieramy. Ten problem eliminuje dziedziczenie wirtualne, przy okazji wprowadzając jednak spory zestaw nowych kłopotów. I dlatego właśnie wielodziedziczenia powinno się nie unikać, o ile się nie wie dokładnie, co chce zrobić :)

Zatem proste, zdawałoby się, stwierdzenie “coś jest jakiegoś typu”, w programowaniu może wcale nie być takie oczywiste. Takie są aczkolwiek uroki naszego ulubionego OOP-u :]

Tags: , ,
Author: Xion, posted under Programming » Comments Off on Być albo nie być

Rozdzielanie pakietów

2008-04-16 14:06

Protokół TCP ma to do siebie, że możemy mu zaufać – zawsze mamy gwarancję, że dane wysłane trafią do odbiorcy (a jeśli nie trafią, to będziemy o tym wiedzieli). Dlatego możliwe jest traktowanie przesyłu danych tą drogą podobnie, jak chociażby wymiany danych między pamięcią operacyjną a plikiem na dysku. Z tego też powodu wiele języków programowania pozwala na opakowanie połączeń TCP/IP w strumienie o identycznym interfejsie jak te służące na przykład do manipulowania zawartością pliku.
W praktyce jednak nie da się pominąć zupełnie tego prostego faktu, iż odbierane dane pochodzą z sieci i wysyłane także tam trafiają. Dotyczy to na przykład takiej kwestii jak dzielenie informacji na małe porcje u nadawcy i ich interpretacja po stronie odbiorcy.

Jak bowiem wiadomo, dane przesyłane przez TCP/IP mogą być po drodze dzielone i składane, a zagwarantowana jest jedynie ich kolejność. Nie ma natomiast pewności, że kawałek danych wysłany jednym wywołaniem w rodzaju Send zostanie odebrany także jednym wywołaniem Receive. Granice między porcjami danych każdy protokół musi więc ustalać samodzielnie. Można to zrobić na kilka sposobów, jak chociażby:

  • Jawne zapisanie długości pakietu. Polega to na wysłaniu przed właściwymi danymi nagłówka o stałym rozmiarze, który ma ustalony format i którego częścią jest długość następującej dalej porcji danych. W najprostszym wypadku może być po prostu wysłanie najpierw np. czterobajtowej liczby z długością pakietu, a następnie reszty danych. Dzięki temu program odbierający zawsze będzie wiedział, ilu bajtów należy się spodziewać (a więc najpierw czterech, a potem tylu, ile wynosi odebrana długość).
  • Używanie ustalonego rozdzielacza. To rozwiązanie polega na określeniu jakiejś sekwencji bajtów jako znacznika końca pakietu. Bardzo często (HTTP, FTP, IRC, itd.) jest to znak końca wiersza, oddzielający poszczególne żądania i odpowiedzi, lub znak o kodzie zero (\0). Odbieranie danych polega wtedy na odczytywaniu kolejnych bajtów do bufora i interpretacji pakietu dopiero po otrzymaniu końcowego znacznika.
  • Korzystanie z własności pewnych formatów danych. Można mianowicie przesyłać informacje wyłącznie w określonym formacie, którego struktura pozwala określić, gdzie kończy się jedna porcja, a zaczyna druga. Jeśli przykładowo wykorzystamy XML i będziemy przesyłali wyłącznie pojedyncze jego elementy – np. <foo>...</foo> – to koniec takiego elementu będzie jednocześnie wiadomością o końcu pakietu. Można to więc traktować jak nieco bardziej skomplikowany wariant znaczników końca.

Jeśli tworzymy nowy protokół dla własnych aplikacji, to który wariant wybrać? Pierwszy wydaje się być dobry dla protokołów binarnych; tych jednak generalnie nie powinno się używać ze względu na liczne problemy z kodowaniem i pakowaniem danych. Druga opcja jest bardzo szeroko stosowana w wielu powszechnie używanych usługach sieciowych i wydaje się sprawdzać całkiem dobrze. Trzecia jest w gruncie rzeczy podobna, ale nieco bardziej złożona i może być kłopotliwa od strony kodu odbierającego dane.

Tags:
Author: Xion, posted under Internet, Programming » 1 comment

RAII-skie kwiatki

2008-04-11 19:43

Jako język nie posiadający słowa kluczowego finally, C++ preferuje nieco inną metodę na radzenie sobie z nieprzewidzianymi “wyskokami” z funkcji i związaną z tym możliwością wycieku zasobów (resource leak). Ten inny sposób jest znany skądinąd jako RAII: Resource Acquisition Is Initialization i polega na związaniu z każdym użyciem zasobu jakiegoś obiektu lokalnego, np.:

  1. {
  2.    ThreadLock lock;
  3.    // (wykonywany tylko przez jeden wątek)
  4. }

Proste i całkiem wygodne, jeśli tylko posiadamy już (lub zechcemy napisać) odpowiednią klasę, która w konstruktorze pozyskuje dany zasób – tutaj blokadę muteksa – a w destruktorze go oddaje.

Ale ten nieskomplikowany mechanizm daje możliwości popełnienia błędów, które są na swój interesujące, ale w realnym kodzie na pewno niezbyt przyjemne :) Pierwszy z nich związany jest z faktem, że lokalnych obiektów nie tworzy się znowu aż tak dużo i można popełnić w ich składni drobne, acz wielce znaczące faux pas z nawiasami:

  1. ThreadLock lock();

Taki wiersz nie stworzy nam bowiem żadnego obiektu, ale zadeklaruje funkcję lock, zwracającą obiekt typu ThreadLock i niebiorącą żadnych argumentów. Zaskakujące? A to tylko prosta konsekwencja faktu, że cokolwiek, co można zinterpretować w C++ jako deklarację funkcji, zostanie tak właśnie zinterpretowane.

Można jednak ripostować, że nic takiego nie zdarzy się, jeśli do konstruktora naszego obiektu-blokady przekażemy chociaż jeden parametr. A zwykle tak właśnie będzie; tutaj np. byłoby nim odwołanie do obiektu typu mutex lub semafora, który chcemy zająć. Jednak nie zmienia to faktu, że w większości przypadków obiekt realizujący RAII wystarcza nam przez samo swoje istnienie, co z kolei sprawia, że w dalszym kodzie w ogóle się do niego nie odwołujemy. To zaś może spowodować, że pominiemy i tak nieużywany składnik jego deklaracji – czyli nazwę:

  1. ThreadLock (&mutex);

Takie zagranie również nie powinno wywołać protestów kompilatora, ale prawie na pewno nie jest tym, o co nam chodzi. Tworzony obiekt jest teraz bowiem nie lokalny, ale tymczasowy: jego zasięg ogranicza się do wyrażenia, w którym został wprowadzony. Czyli do… średnika kończącego powyższą instrukcję! Taki też zakres ma opakowana przez ów obiekt blokada międzywątkowa.

Jak zatem widać, jest tu kilka okazji do popełnienia błędów, które mogą być trudne do wykrycia. Powinniśmy więc zwrócić na nie uwagę tym bardziej, że wobec braku w C++ instrukcji finally technika RAII jest jedynym sensownym wyjściem dla lokalnego pozyskiwania i zwalniania zasobów.

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

Wiosenne porządki #3 – Miękki refaktoring

2008-04-10 17:24

Kiedy piszemy jakieś klasy, wydaje nam się, że dokładnie przemyśleliśmy ich interfejs, który jest intuicyjny, łatwy w użytkowaniu, wydajny, rozszerzalny, i tak dalej. Musi tak być, skoro sami go napisaliśmy, prawda? ;-) Cóż, życie niestety aż nazbyt często weryfikuje to jakże naiwne założenie. A wtedy pozostaje nam przyjrzeć się, co zaprojektowaliśmy nie dość dobrze i próbować to zmienić.
Jest tylko jedno “ale”: do chwili, gdy zdecydujemy się na zmiany w interfejsie, nasza klasa może być już wykorzystywana w innych fragmentach projektu lub zgoła nawet w innych projektach. To może dotyczyć i takich, których nie jesteśmy autorami – jeżeli tylko zdecydowaliśmy się udostępnić naszą twórczość szerszej publiczności. A wtedy sprawa staje się co najmniej problematyczna, bo każda nieprzewidziana modyfikacja może spowodować kaskadę kolejnych zmian, jakie trzeba będzie poczynić w odpowiedzi na nią.

Jeśli naturalnie bardzo tego chcemy możemy je wszystkie przeprowadzić. Wówczas przynajmniej nasz interfejs będzie znów elegancki – przynajmniej do czasu, gdy stwierdzimy, że znów już taki nie jest ;] Jest to jak najbardziej możliwe, ale pewnie nie trzeba wspominać, jak pracochłonna może być taka operacja.
Spójrzmy raczej na sposób, w jaki radzą sobie z tym problemem twórcy szeroko wykorzystywanych bibliotek programistycznych różnego rodzaju. To, co jest ich cechą wspólną w kolejnych wersjach, to zachowywana zawsze kompatybilność wstecz. Jest ona osiągana przez modyfikacje polegające wyłącznie na dodawaniu elementów interfejsu bez zmiany już istniejących. Pewnie najbardziej znanym przejawem takiej praktyki jest istnienie funkcji z końcówką Ex w Windows API, które robią trochę więcej niż ich “zwykłe” odpowiedniki i mają nieco zmienioną listę parametrów.

To oczywiście nie jedyna droga nieinwazyjnego poprawiania interfejsu. Takich sposobów jest co najmniej kilka, jak chociażby:

  • Wprowadzanie całkiem nowych klas rozszerzających funkcjonalność już istniejących. Można w tym celu wykorzystać agregację (obiekt nowej klasy zawiera obiekt starej), dziedziczenie prywatne czy nawet publiczne. Ważne jest, aby nowa klasa na tyle różniła się od oryginalnej, by jej istnienie było uzasadnione i nie powodowało dylematów pod tytułem “Której klasy mam użyć?…”.
  • Uzupełnienie istniejących klas o nowe metody. Dzięki temu, że nie zmieniamy żadnego z już istniejących składników klasy, stary interfejs nadal będzie dostępny.
  • Dodanie do metod wersji przeciążonych i/lub parametrów domyślnych. Jest to odpowiednik wspomnianego przyrostka Ex. Zauważmy, że po takiej operacji możemy zmienić implementację starych metod tak, aby wewnętrznie korzystały one z nowych, rozszerzonych wersji. Póki nie zmieni się sposób ich wywoływania, kod pozostanie kompatybilny wstecz.

Można się zastanawiać, czy taki “miękki refaktoring” nie jest odkładaniem na później tego, co i tak należy wykonać? Zapewne tak: przecież każdy kod można zawsze napisać lepiej, czyli od nowa :) Trzeba jednak odpowiedzieć sobie na pytanie, czy korzyści z tego będą większe niż włożony wysiłek. Jeżeli nie kodujemy jedynie dla samej przyjemności kodowania, to nie ma cudów: odpowiedź najczęściej będzie negatywna.

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

Sinus, cosinus

2008-04-08 16:18

Jeśli w praktyce obliczamy wartości funkcji sinus lub cosinus dla danego kąta, to bardzo często zdarza się, że tak naprawdę potrzebujemy ich obu. Jest tak przy obliczaniu punktów okręgu, przy rozkładzie wektorów sił i jeszcze dla wielu innych okoliczności. Zależy nam naturalnie, aby policzyć to wszystko tak szybko, jak tylko się da, dlatego dobrze jest stosować funkcje w rodzaju sincos, które wyznaczają obie wartości jednocześnie.

Niestety nie każdy język programowania taką funkcję posiada. Mają ją języki shaderowe (GLSL, HLSL i asembler GPU) oraz np. Delphi, ale już nasz ulubiony C++ nie. Można by oczywiście uzupełnić ten brak poprzez taką implementację:

  1. void sincos(float angle, float* sine, float* cosine)
  2.     { *sine = sin(angle); *cosine = cos(angle); }

ale chyba nie trzeba nikogo przekonywać, że większego sensu ona nie ma :) Nie występuje tu bowiem żaden zysk na wydajności, bo wartości są obliczane oddzielnie.

Co więc można zrobić? Ano wykorzystać to, co drzemie w jednostce zmiennoprzecinkowej procesora, ale nie jest używane przez wszystkie języki wyższego poziomu. Istnieje mianowicie instrukcja FSINCOS, która wykonuje całą potrzebną “magię”. Należy ją tylko opakować:

  1. void sincos(float angle, float* sine, float* cosine)
  2. {
  3.     __asm
  4.     {
  5.         mov eax, sine
  6.         mov edx, cosine
  7.        
  8.         fld     angle
  9.         fsincos
  10.         fstp    dword ptr [edx]
  11.         fstp    dword ptr [eax]
  12.     }
  13. }

Jakkolwiek tajemniczo to może wyglądać, funkcja ta po prostu ładuje argument (kąt) na stos FPU, by potem odebrać wyniki – cosinus i sinus. W przypadku operowania na liczbach typu float nie ma możliwości podania zbyt dużego/małego argumentu, więc nie trzeba sprawdzać rejestru flag.

I tyle – funkcja mała, acz użyteczna. Asembler czasem się przydaje, proszę państwa ;P

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


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