Jak odbywa się renderowanie oprogramowania?

Chciałbym zbadać rasteryzację opartą na oprogramowaniu w czasie rzeczywistym. Wiem, że teraz wszystko idzie w kierunku GPU, ale jest kilka gier, w których nadal warto używać renderera oprogramowania.

Na przykład: Voxeltron

Voxatron to strzelanka na arenie, rozgrywająca się w świecie zbudowanym z wokseli (małe kostki). Wszystko w grze jest wyświetlane na wirtualnym ekranie wokselowym 128x128x64, w tym menu i ekwipunek gracza. Jeśli przyjrzysz się uważnie, możesz czasem zobaczyć, jak ekwipunek (ocena / życie / amunicja) rzuca cień na niektóre obiekty na ziemi.

Od dłuższego czasu pracuję nad narzędziami do renderowania i modelowania wokseli, których ostatecznym celem jest stworzenie dużej przygodowej gry eksploracyjnej. Około pół roku temu połączyło się z pracą, którą wykonywałem dla strzelców na arenie dla Conflux, i to jest wynik.

Jest to dość prosta gra w sercu - głównie tylko Robotron osadzony w zniszczalnym świecie 3D z głupimi stworzeniami. Nie jestem pewien, jak poważne będą konsekwencje niszczenia w rozgrywce, ale z pewnością fajnie jest wysadzić ściany. Dodałem również eksperymentalny pickup do budowania ścian, którego możesz użyć do budowy barier, aby ukryć się przed przerażającymi potworami.

Gra toczy się na niewielkim zestawie aren. Niektóre z nich zawierają pokoje z ustawionymi elementami akcji, gdzieś między Knightlore a Smash TV. Jest to część oryginalnego projektu przygodowego, który wrócił do gry, i pretekst do stworzenia środowisk tematycznych.

Cechy:

• Niestandardowe renderowanie oprogramowania z miękkimi cieniami.
• Wbudowany syntezator dźwięku i muzyki (wykorzystywany również do tworzenia zwiastuna).
• Odtwarzanie i nagrywanie po zakończeniu gry.

Zakładam, że znasz już podstawową algebrę liniową, taką jak: projekcje 3d, konfiguracja kamery, przekształcanie wierzchołków w pozycję światową itp. Jeśli nie, możesz się wiele nauczyć. Oto dwa, które lubię:

Architektura silnika gry

• Krótki opis podstawowej algebry liniowej, ale obejmuje wszystko, co musisz wiedzieć. Książkę warto też mieć z wielu innych powodów.

Renderowanie w czasie rzeczywistym

• Troszkę bardziej szczegółowy zasięg, ale znowu dotyczy tylko tego, co możesz potrzebować wiedzieć. Ponownie polecam ten temat do tematów omówionych w pozostałych rozdziałach.

Gdy już wiesz, jak reprezentować i obsługiwać obiekty 3d, możesz sprawdzić, jak narysować je na ekranie. Zazwyczaj odbywa się to za pomocą techniki rasteryzacji trójkąta linii skanowania. To właściwie dość prosta koncepcja. Rysujesz jeden rząd jednego trójkąta na raz, interpolując współrzędne koloru i tekstury UV. Ten proces jest kontynuowany dla wszystkich trójkątów na ekranie. Możesz nawet zaimplementować bufor głębokości do obsługi renderowania poza kolejnością.

Bardziej szczegółowo opisano to w tych artykułach:

Samouczek - Wprowadzenie do renderowania programowego: Rasteryzacja trójkątów

Software Rendering School: Część I

I dla zabawy sprawdź następujący artykuł:

Quake 2 Review Code Source 3/4 (Software Renderer)

To dość szeroki temat. Są jednak dwie podstawowe części: rzeczywista teoria transformacji grafiki i proces rasteryzacji oraz rzeczywiste bity implementacyjne, które pozwalają wysyłać piksele na ekran w dowolny sposób. Do tego dochodzi również optymalizacja (szczególnie tego ostatniego).

Pierwsza część jest na szczęście taka sama jak teoria zastosowana w potoku graficznym ujawniona przez nowoczesny sprzęt i interfejsy API. Jeśli już to wiesz, jesteś gotowy. Jeśli nie, polecam dobrą książkę. Ten jest całkiem niezły.

Istnieje wiele opcji dla drugiej części. Zależą one w dużym stopniu od systemu operacyjnego i wyboru narzędzi. Jeśli używasz C lub C ++, w systemie Windows możesz po prostu drukować piksele bezpośrednio do mapy bitowej GDI ( SetPixeljest to proste, ale boleśnie, bezużyteczne spowolnienie - CreateDIBSectiondaje ci kawałek nieprzetworzonych bajtów, którymi możesz manipulować znacznie szybciej).

Możesz także nabyć powierzchnię DirectDraw i pisać do niej lub pisać do tekstury Direct3D lub OpenGL. W tych ostatnich przypadkach nadal będziesz korzystać ze sprzętu, ale tak długo, jak sam zrobisz całą kompozycję ostatecznego obrazu na procesorze i po prostu użyjesz sprzętowych interfejsów API do skopiowania wyników na ekran, nadal się to liczy. Na nowoczesnych komputerach nie można uzyskać dostępu do surowej pamięci VRAM ani niczego innego bezpośrednio.

Jeśli chcesz dowiedzieć się więcej, prawdopodobnie powinieneś stworzyć bardziej szczegółowe pytania. Ja lub inni chętnie odpowiemy na nie.

Dobra, podchodzę do tego pytania od podstaw; cokolwiek poza tym jest drogą do szerokiego dla prostej kontroli jakości; musisz kupić książkę na ten temat.

Najbardziej podstawowa różnica między renderowaniem w oprogramowaniu a użyciem procesora graficznego sprowadza się do kreślenia pikseli. Oznacza to, że podczas renderowania programowego jesteś ostatecznie odpowiedzialny za kreślenie każdego przeklętego piksela, podczas gdy w przypadku procesora graficznego wykreślanie pikseli jest w dużej mierze zautomatyzowane przez sprzęt i po prostu „masujesz” piksel przy użyciu shaderów.

Pomyśl na przykład, co musisz zrobić jako programista, aby wyświetlić na ekranie trójkąt 3D. Dzięki GPU właściwie mówisz sprzętowi, jakie są współrzędne X, Y, Z wierzchołków, a następnie karta wideo wypełnia wszystkie piksele na ekranie, które składają się na obraz trójkąta. Możesz użyć modułu cieniującego, aby nakazać GPU zmianę koloru każdego piksela na podstawie tekstury lub czegoś, ale ostatecznie sprowadza się to do tego, że GPU automatycznie wypełni wszystkie piksele za Ciebie.

Podczas renderowania programowego musisz obliczyć, które piksele na ekranie należy wypełnić, a następnie wykonać blitting, aby faktycznie wypełnić te piksele. Oznacza to, że robisz matematykę macierzy, aby przekształcić z przestrzeni współrzędnych sceny 3D w przestrzeń widokową, a następnie rzutować punkty z przestrzeni widokowej na ekran itp.