Monthly archive for October, 2007

Świadomość wyboru

2007-10-06 12:34

Każdy programista posługuje się zestawem narzędzi służącym mu do pracy: językiem programowania, środowiskiem developerskim, kompilatorem, debugerem, itd. Są to takie same atrybuty jak ołówek dla rysownika czy hebel dla stolarza. Jako podobne do takich właśnie przedmiotów produkty, mogą być one oceniane pod względem różnych kryteriów, w tym najważniejszego – użyteczności.

Narzędzia, jakimi się posługujemy jako koderzy, powinny więc być przede wszystkim adekwatne do sytuacji, w której się znajdujemy. Zawsze bowiem tworzymy coś przeznaczonego do działania w określonym kontekście – środowisku, platformie sprzętowej czy we współpracy z innymi programami. Jednocześnie nakładamy też pewne wymagania na produkt wynikowy czy też na sam proces jego tworzenia.
Możemy na przykład chcieć, by był on maksymalnie efektywny albo zajmował jak najmniej pamięci operacyjnej. Innym wymaganiem może być szybkość realizacji projektu – co zwykle oznacza, że pisząc nasz program, chcemy namęczyć się jak najmniej i skorzystać z jak największej ilości istniejącego już kodu. Wreszcie może nas interesować też elegancja wynikowego kodu źródłowego – chociaż na nią największy wpływ mamy sami.

W teorii właśnie takimi przesłankami powinniśmy kierować się, gdy przychodzi nam wybrać narzędzie (na przykład język programowania) pomocne w tworzeniu. Oczywiście możemy do nich dodać własne – łącznie z tym dla niektórych najważniejszym: czy dane narzędzie znam wystarczająco dobrze i/lub czy chcę się go (pod/na)uczyć. Grunt żebyśmy byli świadomi powodów, dla których decydujemy na taki a nie inny wybór.
Dotyczy to nawet tych mniej racjonalnych powodów w rodzaju: “bo ‘wszyscy’ tego używają”, “bo dany język/biblioteka/itp. po prostu mi się podoba”, “bo przyjemnie mi się w tym pisało”, itp. Nie muszą one wcale być gorsze od tych solidnie ufundowanych i sprawdzonych argumentów. Jeżeli bowiem żadne zewnętrzne i niezależne od nas okoliczności nas nie ograniczają, powinniśmy dążyć do jak największej satysfakcji z tworzenia – zarówno z samego procesu, jak i z osiąganych rezultatów.

Tags: ,
Author: Xion, posted under Applications, Programming, Thoughts » 9 comments

Pomocna małpa

2007-10-04 16:56

Eksperymentując z grafiką 3D bardzo często zachodzi potrzeba napisania i przetestowania programu testującego jakąś konkretną technikę zrobienia czegoś – na przykład powierzchni odbijającej światło czy rzucania cieni. Można w tym celu stworzyć jakiś szablon przykładowego programu, który będziemy odpowiednio modyfikować. Nie będzie to zwykle wygodne, chyba że naprawdę się postaramy (czytaj: poświęcimy dużo czasu na rzecz nie do końca potrzebną).

Logo RenderMonkeyIstnieje aczkolwiek inne rozwiązanie i jest nim skorzystanie z wyspecjalizowanej aplikacji, jak na przykład RenderMonkey stworzonej przez ATI i dostępnej za darmo. Jest to coś w rodzaju wirtualnego środowiska dla programowania grafiki (czyli shaderów) działającego jednak na zupełnie realnym urządzeniu – przy użyciu DirectX lub OpenGL.
Ma ono całkiem spore możliwości oraz udostępnia sporą wygodę w testowaniu różnych efektów opierających się na ustalonych parametrach. O ile w kodzie zmiana jakiejś wartości wymagałaby zwykle rekompilacji, o tyle tutaj można taką wartość (zmienną) odpowiednio oznaczyć i modyfikować jej wartość przy pomocy graficznego interfejsu, natychmiast podglądając rezultat.

Screen z RenderMonkey Screen z RenderMonkey

Rzeczone zmienne ostatecznie mają po prostu odpowiedniki w rejestrach shaderów (pisanych dla DX w HLSL). Oprócz edytowania ich RenderMonkey umożliwia też dodawanie do projektów różnego rodzaju zasobów (modeli, tekstur, itp.) oraz ustawianie ich różnych stanów. Na dodatek w pakiecie z programem jest całkiem sporo takich właśnie przykładowych zasobów.

A wady? Cóż… Mogę wspomnieć o tym, że obecnie program wykorzystuje tylko DX9, czyli niestety nie pobawimy się tymi jakże użytecznymi geometry shaderami (oczywiście przy założeniu, że nasza karta potrafi się nimi bawić :)) Ale jest i dobra strona – nie trzeba instalować Visty ;P

Układy odniesienia

2007-10-02 19:06

Programując grafikę czy choćby cokolwiek, co ma się ostatecznie pokazać na ekranie, cały czas operuje się współrzędnymi w przestrzeni. Wówczas trzeba zawsze pamiętać, że ten zestaw liczb – zwykle X, Y i ewentualnie Z – nie istnieje sam dla siebie i zawsze jest podawany względem czegoś. Tak więc wszystkie współrzędne są względne, bo nawet nazywane “bezwzględnymi” różnią się tylko tym, że ich punkt odniesienia jest wyjątkowo dobrze zdefiniowany – na przykład jako lewy górny róg ekranu lub punkt (0,0,0) nieprzetransformowanego układu sceny 3D.

Kłopoty zaczynają się wtedy, gdy zaczynamy nieświadomie mieszać koordynaty korzystające z innych układów odniesienia. Nadal czasami mi się to zdarza w kodzie systemu GUI, mimo że starałem się bardzo dokładnie określić względem czego jest określona np. pozycja danej kontrolki i jakie przekształcenia (głównie odpowiednia translacja) są wykorzystywane przy rysowaniu każdego elementu.
To wszystko jest oczywiście w dwóch wymiarach. W 3D potencjalnych punktów odniesienia jest nawet więcej; wśród nich mamy chociażby ten związany z kamerą, z modelem, ze światłem, i tak dalej. A co gorsza, ocena czy taki lub inny błąd wynika właśnie z pomylenia różnych układów współrzędnych jest trudniejsza właśnie ze względu na obecność tego trzeciego wymiaru.

Wniosek stąd taki, że należy pamiętać o używanym aktualnie układzie odniesienia. Łatwo bowiem napisać:

  1. void Foo(float x, float y, float z);

i za jakiś (niedługi) czas zastanawiać się, względem czego te x, y czy z powinno tak naprawdę być liczone. A podejrzewam, że u większości programistów umiejętność rozwiązywania tego typu łamigłówek jest dość… względna :)

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

Back to school

2007-10-01 15:51

Spośród uczących się studenci są o tyle uprzywiluejowaną grupą, że ich wakacje są o cały jeden miesiąc dłuższe (oczywiście przy optymistycznym założeniu, że nie mają żadnych zaległości :)). Niestety wszystko musi się kiedyś skończyć, a początek października jest czasem nieuchronnego powrotu do zajęć. Na co osobiście oczekiwałem ze niecierpliwieniem już od jakiegoś czasu.

Ponadto nowy rok akademicki oznacza też, że znów większość czasu będę spedzał w Warszawie. Zdążyłem się już do tego całkowicie przyzwyczaić; trzeba bowiem przyznać, że duże miasta mają swój niezaprzeczalny urok. Wprawdzie stolica nie jest perełką architektury ani nie wprawia w zachwyt genialnością rozwiązań komunikacyjnych, to jednak z jakichś trudnych do określenia powodów dość szybko zyskała moją przychylność. Przynajmniej jeśli chodzi o tę jej część, którą z konieczności przebywałem i będę przebywać każdego dnia.

Zajęcią na uczelni to oczywiście pewne dodatkowe obowiązki, ale tych z każdym rokiem jest wyraźnie mniej. Mam więc uzasadnioną nadzieję, że uda mi się bez większych problemów pogodzić je z kodowaniem. Pogodzić rzecz jasna w sposób jednoznaczenie i wyraźnie faworyzujący kodowanie ;)


Author: Xion, posted under Studies » 5 comments
 


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