Monthly archive for December, 2009

Shadery i pliki efektów – sprostowanie

2009-12-11 16:58

Płynne przejście od programowania grafiki 3D przy pomocy fixed pipeline do wykorzystania shaderów nie jest z początku takie proste. Jest oczywiście w sieci mnóstwo tutoriali, które to ułatwiają. Zauważyłem jednak, że mają one tendencję do przekazywania naciąganych – mówiąc delikatnie – faktów na temat tego, w jaki sposób shadery oraz pliki efektów .fx (często omawiane łącznie) muszą być wykorzystywane w aplikacjach DirectX.
Dlatego pomyślałem sobie, że dobrze byłoby sprostować kilka mitów, jakie się tutaj pojawiają i wprowadzają zamieszanie do i tak niełatwej dziedziny programowania. Warto bowiem wiedzieć, iż to nieprawda, że:

  • …korzystając z shaderów, musimy używać też plików .fx. Shader wierzchołków czy pikseli możemy samodzielnie wczytać z pliku (w wersji skomplikowanej lub przeprowadzić kompilację przy pomocy funkcji D3DX) czy nawet wygenerować dynamicznie, a potem zwyczajnie ustawić go jako aktualny VS/PS przy pomocy metod SetVertex/PixelShader urządzenia DirectX. Plik efektów nie jest wtedy do niczego potrzebny.
  • …pliki .fx są tylko po to, by łatwiej wczytywać/aplikować shadery do renderowania. W rzeczywistości celem istnienia plików efektów jest uproszczenie kodowania różnych efektów graficznych w wersjach zależnych od możliwości poszczególnych kart. Zamiast samodzielnie sprawdzać capsy (możliwości) sprzętu, na którym uruchamia się nasza aplikacja, możemy po prostu pozwolić DirectX-owi wyszukać w pliku .fx tą wersję efektu (tzw. technikę), która na danej konfiguracji sprzętowej będzie działać. W ten sposób możemy na przykład napisać dwie wersje oświetlenia: jedną per pixel z użyciem shaderów i drugą, używającą fixed pipeline i oświetlającą wierzchołkowo. Nie musi ona wtedy korzystać z żadnych shaderów.
  • …aby stosować shadery, musimy porzucić FVF na rzecz vertex declaration. Jest to piramidalna bzdura, która na szczęście rzadko bywa wygłaszana wprost, ale często wynika ze sposobu omawiania tematu VD w tutorialach. W istocie stałe D3DFVF tak samo dobrze opisują format danych dla vertex shaderów, jak deklaracje wierzchołków (IDirect3DVertexDeclarationX) i DirectX nie ma problemu z łączeniem jednego z drugim. Analogia działa zresztą też w drugą stroną: użycie fixed pipeline nie wymusza korzystania z FVF.
    Oczywiście bardziej zaawansowane techniki pisane z użyciem shaderów najczęściej potrzebują na wejściu danych, których w FVF zapisać się nie da (np. wektorów stycznych i binormalnych). Wtedy rzecz jasna potrzebne jest określenie formatu wierzchołków poprzez vertex declaration. Dla prostych VS-ów (jak choćby zwykłego m4x4 oPos, v0, c4) sam fakt korzystania z programowalnego potoku grafiki nic nie wymusza w zakresie formatu danych wierzchołków.
  • …vertex i pixel shadery musimy zawsze stosować łącznie. To prawie logiczna konsekwencja częstego stwierdzenia (też niespecjalnie prawdziwego), że wyjście VS-a jest wejściem PS-a. W rzeczywistości nie jest to prawdą i łatwo można podać przykłady technik, w których możemy np. użyć pixel shadera bez vertex shadera – jak choćby zamiana wszystkich kolorów w scenie na odcienie szarości.
  • …shadery zastępują cały potok renderowania. Chociaż oświetlenie, teksturowanie, transformacje macierzowe wierzchołków itp. to spory kawałek potoku renderowania, zastąpienie ich shaderami wcale nie oznacza, że nic już poza tym nie zostało. Rzeczy takie jak alpha blending, usuwanie tylnich ścian (culling), różne testy pikseli (głębokości, alfa, stencil) i przycinanie (np. płaszczyznami oraz scissor test) to tylko niektóre z elementów potoku, które są dostępne niezależnie od tego, czy obecne są w nim także załadowane przez użytkownika shadery.
Tags: , ,
Author: Xion, posted under Programming » 2 comments

Triki z PowerShellem #12 – Rozpakowywanie

2009-12-07 23:18

Powtarzające się katalogiWiele programów z sieci wciąż jeszcze ściąga się w postaci archiwów do samodzielnego wypakowania, jak choćby w formacie .zip. Ma to swoje zalety i wady – do tych drugich należy fakt, że nie bardzo wiadomo, jak wygląda wewnętrzna struktura katalogów takiej paczki. Używając opcji typu Wypakuj tutaj ryzykujemy zaśmiecenie folderu Downloads plikami programu. Dlatego osobiście zawsze stosuję polecenie Wypakuj do nowego katalogu.
I tu czasem jest mały zonk, gdy twórca archiwum zdecydował się na spakowanie całego folderu, a nie tylko zawartych w nim plików. Powstają wtedy nadmiarowe katalogi, wydłużające ścieżki do plików (co widać obok – w wersji trochę przesadzonej ;)).

Ponieważ podobne sytuacje zdarzają mi się dość często, postanowiłem im zaradzić przy pomocy najlepszego narzędzia na takie okazje, czyli PowerShella rzecz jasna :) Wynikiem jest poniższy skrypt do sprytniejszego rozpakowywania archiwów:

  1. # unpack.ps1
  2. # Sprytne rozpakowywanie archiwów
  3. param ([string]$archive = $(throw "No archive specified"))
  4.  
  5. # Bierzemy nazwę archiwum i tworzymy odpowiadający mu katalog
  6. $name = [IO.Path]::GetFileNameWithoutExtension($archive)
  7. Set-Location -Path (New-Object IO.FileInfo @($name)).DirectoryName
  8. $dir = [IO.Directory]::CreateDirectory($name)
  9.  
  10. # Rozpakowujemy archiwum do tego katalogu
  11. $shell = New-Object -ComObject Shell.Application
  12. $src = $shell.Namespace($archive)
  13. $dest = $shell.Namespace($name)
  14. $dest.CopyHere($src.items())
  15.  
  16. # Rekurencyjnie badamy zawartość rozpakowanego archiwum
  17. while (($items = $dir.GetFileSystemInfos()) -eq 1)
  18. {
  19.     # Sprawdzamy, czy jego pierwszy i jedyny element jest katalogiem
  20.     $fsi = $items[0]
  21.     if (($fsi.Attributes -band [IO.FileAttributes]::Directory) -eq 0)
  22.         { break }
  23.    
  24.     # Jest - dokonujemy skrócenia ścieżki
  25.     $fsi.MoveTo([IO.Path]::GetRandomFileName())
  26.     $dir.Delete()
  27.     $dir = $fsi
  28.     $dir.MoveTo($name)
  29. }

Jego działanie polega wpierw na zwykłej dekompresji archiwum. Jak można zauważyć, używa do tego obiektu COM-owskiego Shell.Application. To sprawia, że skrypt ma pod tym względem te same możliwości co zwykły windowsowy Eksplorator (dla większych plików pokaże nawet pasek postępu ;]).
Później wypakowana zawartość jest poddawana operacji, którą nazywam tutaj ‘skróceniem ścieżki’. Polega ona wyrzuceniu jednego poziomu drzewa folderów, o ile tylko pewien katalog jest jedynym elementem swojego katalogu nadrzędnego. Takie właśnie sytuacje powstają przy dekompresji do nowego folderu archiwów źle zapakowanych (przynajmniej z mojego punktu widzenia ;P). Wynikiem działania skryptu będzie więc w sumie jeden nowy podkatalog zawierający bezpośrednio całą interesującą zawartość archiwum.

Oczywiście używanie powyższego skryptu tylko z poziomu linii komend PowerShella nie jest specjalnie wygodne; lepiej jest dodać go do menu kontekstowego archiwów, czyli np. plików .. O tym, jak można tego dokonać, napisałem dość obszernie przy okazji prezentacji skryptu do wysyłania przez FTP.

Tags: , ,
Author: Xion, posted under Applications, Internet, Programming » 5 comments

I co się w tej grze robi?…

2009-12-04 21:14

Przeglądając znalezione niedawno czasopisma o grach sprzed kilku lat, zauważyłem ciekawy schemat pojawiający się w ówczesnych recenzjach. Wiele z nich wskazywało mianowicie na liniowość jako cechę bardzo niepożądaną w każdej właściwie grze, niekoniecznie przygodówce czy RPG-u (gdzie istotnie byłaby ona zbrodnią). Gracz miał bowiem mieć jak najwięcej swobody i jak najwięcej możliwości dokonywania znaczących wyborów – wtedy rozgrywka uznawana była za interesującą.

Gdy przyjrzymy się teraz tytułom wychodzącym obecnie, to da się zauważyć, że lata forsowania tej idei zrobiły swoje. Już niewiele jest jakich gier, w których trzeba przechodzić kolejne etapy/misje/poziomy/itp. w dość ściśle określonej kolejności. Zamiast tego mamy coraz więcej produkcji, gdzie właściwie cały rozwój rozgrywki znajduje się w rękach gracza.
Przykłady? Chociażby cały podgatunek MMORPG: zwykle poza jedną linią głównych questów (zadań) wszystkie pozostałe są poboczne, a gra polega generalnie na współpracy z innymi graczami, by osiągnąć wyznaczone grupowo cele. Podobny schemat występuje też niekiedy w rozgrywce single player (np. cała seria Grand Theft Auto). W końcu mamy całą paletę gier symulacyjnych, z ikonicznymi “simsami” na czele.

Można więc przypuszczać, że liczba gier z dużym stopniem swobody dla gracza będzie się zwiększać. Po części jest tak może dlatego, że ciężko usłyszeć opinie, aby ten kierunek rozwoju był złym. Kto wie, może faktycznie tak nie jest? :)
Jednak mam pewne wątpliwości. Wysoka nieliniowość gry może bowiem oznaczać tyle, że jej twórcy poszli na łatwiznę i tak naprawdę nie zainteresowali się tym, jak będzie ostatecznie przebiegać rozgrywka. Postawienie na samą mechanikę i uczynienie jej maksymalnie elastyczną może z początku wyglądać na działanie wielce innowacyjne, ale po bliższym przyjrzeniu się na wierzch mogą wyjść duże zaniedbania od strony fabularnej. (Wydaje mi się na przykład, że to właśnie była przyczyna chłodnego przyjęcia długo oczekiwanej gry Spore).

Achievement unlocked :)Jest jeszcze jeden aspekt tej sprawy: czy wysoce nieliniowe gry są tym, czego gracze faktycznie oczekują? Nie byłbym tego taki pewien, a poważnym argumentem, który za tym przemawia, jest “ostatni krzyk mody” w grach wszelakich, czyli tzw. osiągnięcia (achievements). Twór ten przyszedł z produkcji konsolowych, a jego oczywistą funkcją jest przedłużanie czasu życia gry poprzez wskazywanie graczowi, co jeszcze mógłby w niej zrobić (i jak mógłby być lepszym od innych).
Popularność tego mechanizmu dowodzi, że jego wprowadzanie jest zazwyczaj dobrym krokiem. Dlaczego? Poza widocznym wyraźnie czynnikiem rywalizacji z innymi (zawsze pożądanym), osiągnięcia mogą organizować przebieg rozgrywki i subtelnie wskazywać jej właściwy kierunek.

Inaczej mówiąc, jest to sposób na ponowne wprowadzenie do gier liniowości – tym razem w wersji light, jako opcji. Czy oznacza to więc cofanie się w rozwoju? Otóż nie wydaje mi się; to raczej odpowiedź na zapotrzebowanie. Bo po co nam gry, w których można robić wszystko, skoro w rzeczywistości oznacza to, że niczego robić nie warto?…

Tags:
Author: Xion, posted under Games, Thoughts » 2 comments
 


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