dabroz.scythe.pl

Zaniemówiłem, gdy zobaczyłem tego typu konstrukcję:

std::vector<int> vec;
vec.push_back(1); vec.push_back(7); vec.push_back(4);
for each (const int &vi in vec)
{
	std::cout << vi << std::endl;
}

Wygląda na to, że działa tylko pod Visual Studio - ale i tak wygląda zachęcająco w porównaniu do wersji z ::iterator.

Oto kontrolka do wyszukiwania:

Czym taka kotrolka powinna się charakteryzować?

• wizualnie:
  
  • ikonka jednoznacznie mówiąca nam "szukaj" - lupa jest już głęboko zakorzeniona w świadomości użytkowników
  • tekst zachęcający do rozpoczęcia wyszukiwania
  • w/w tekst nie może jednak przeszkadzać w korzystaniu z kontrolki. Dlatego też:
    
    • tekst zachęcający jest szary, podczas gdy wyszukiwana fraza jest czarna
    • wpisanie jednego znaku do kontrolki w czasie gdy jest w niej domyślny tekst powoduje jego zniknięcie
    • skasowanie całej frazy wyszukiwania przywraca domyślny tekst
    • tekst zachęcający nie jest zwracany jako wynik wyszukiwania (o tym za chwilę)
• użytkowo:
  
  • z resztą programu kontrolka komunikuje się, udostępniając szukaną frazę (string SearchValue) oraz zdarzenie odpalane w czasie zmiany tekstu (SearchValueChanged)
  • kluczowy feature: brak potwierdzenia wyszukiwania (naciskania Enter, klikania Search itd) - czyli stosujemy mechanizm "pisz i od razu szukaj"
  • "od razu" nie musi być równe "natychmiast" - kontrolka powinna posiadać pewną bezwładność, czyli opóźnienie między zakończeniem edycji tekstu do wyszukania a samym wyszukaniem. Jego długość powinna zależeć od skomplikowania wyszukania a także tego, jak szybko użytkownik jest w stanie sprecyzować swoje wyszukanie
  • samo wyszukiwanie powinno być zaimplementowane możliwie wydajnie - użytkownik chce na bieżąco widzieć wynik swoich poszukiwań
  • jak zrealizować powyższe? Trzeba pamiętać, że przez większość czasu użytkownik będzie myślał, a nie pisał - jeżeli więc możemy w tle budować sobie cache, to jest to doskonałe rozwiązanie

Po raz pierwszy wziąłem udział w compo w serwisie gamedev.pl. Do napisania w 3h była gra spełniająca następujący warunek: The game must contain both a pig and a cow. Utrudnieniem był zakaz korzystnia z gotowych grafik/dźwięków (czy to z netu czy to zrobionych wcześniej) czy nawet z własnego kodu (poza prostym frameworkiem).

Zdecydowałem się na symulację życia krów i świń. :)

Cóż - gry pisane w kilka godzin rządzą się swoimi prawami. :)

Rainbox Raytracer

Kilka przemyśleń:

• niestety Photon Mapping za żadne skarby nie chce działać na obecnym sprzęcie w czasie rzeczywistym ;)
• raytracing można zaimlementować na GPU na tyle wydajnie, żeby za 2-3 generacje kart graficznych można było skorzystać z niego w większości gier
• niestety raytracing sam z siebie nie jest cudownym środkiem na fotorealizm - mimo wszystko nie uwzględnia oświetlenia globalnego, przez co w sumie jego przewaga na rasteryzacją polega jedynie na:
  • odbicia i załamania - tutaj RT daje nam oczywiście możliwość zabawy z materiałami, pytanie czy jest to bardzo przydatne (płaskie materiały odbijające można załatwić dodatkowym renderowaniem, a większość "powyginanych" obiektów da się zrobić statyczną cubemapą - w większości przypadków gracz nie zauważy różnicy)
  • nie musimy się martwić o kolejność przezroczystych obiektów na scenie
  • możemy używać powierzchni dających się opisać wzorem, z pominięciem dzielenia na trójkąty. W gruncie rzeczy jest to fajna sprawa, bo znacząco zmniejsza rozmiary modeli 3D przy doskonałej jakości w dowolnych rozdzielczościach. Trzeba by jednak zmienić podejście grafików do modelowania i sposób pracy z softem do modelowania 3D
  • raytracing można bardzo łatwo zrównoleglić na dowolną ilość procesorów (w przeciwieństwie do rasteryzacji)

W najbliższym czasie postaram się wydać małe RTRT-demo. :)

Niedługo dostępny będzie C# 4.0. Z ciekawych rzeczy, które mają wprowadzić:

1. dynamic - ciekawy, aczkolwiek niepokojący feature. W skrócie - dostaniemy typy nieokreślone z możliwością wywoływania na nich dowolnych metod, które będą bindowane dopiero w czasie wykonywania (w przypadku klas .NET-owych; dla obiektów COM i obiektów z interfejsem IDynamicObject magia jest jeszcze głębsza). Ciekaw jestem, jak będzie radzić sobie z tym Intellisense. W każdym razie widzę jedno (jedyne?) całkiem sensowne zastosowanie:

   static dynamic Sum(dynamic a, dynamic b)
   {
       return a + b;
   }

   Dzięki temu będzie można w końcu napisać abstrakcyjną klasę macierzy (choć nie ukrywam, że interfejs INumeric byłby dużo bezpieczniejszym rozwiązaniem).
2. domyślne wartości parametrów funkcji. W końcu! Czy to naprawdę było tak trudne do realizacji?

   public void M(int x, int y = 5, int z = 7);

3. Covariance i Contravariance. Legalna będzie taka konstrukcja:

   IList<string> strings = new List<string>();
   IEnumerable<object> objects = strings;
   var result = strings.Union(objects); 

   Pojawią się nowe słowa kluczowe dla szablonów:

   public delegate TResult Func<in TArg, out TResult>(TArg arg);

   W skrócie: będzie możliwość rzutowania szablonu z jakimś typem na szablon ogólny (object) i odwrotnie (w zależności od kierunku parametru). Dzięki temu Func<object,string> będzie można użyć jako Func<string,object>.
4. oczywiście razem z C# 4.0 pojawi się też .NET Framework 4.0. Z ciekawszych rzeczy dostępny będzie od razu Parallel Extensions - dobra rzecz dla leniwych programistów chcących wykorzystać moc procesorów wielordzeniowych.

Źródła:
New Features in C# 4.0
Simulating INumeric with dynamic in C# 4.0

W celach edukacyjno-rozrywkowych napisałem prosty raytracer. Chciałem na własne oczy (i kod) przekonać się, czym różni się tego typu renderowanie od klasycznej rasteryzacji. Zaskoczyło mnie, że sporo elementów jest bardzo podobnych (nie sądziłem na przykład, że pixel shadery można przenosić prawie 1:1 między RT a nie-RT). Oczywiście wielkiego pożytku z takiego RT nie ma - ale popatrzeć na sfery zawsze można.