Luke J. Li

Więc tak, pisałem sobie ten silnik 3D i cóż, okazało się, że im bardziej się rozrastał, tym więcej miałem problemów z długiem technicznym (zrobiłem coś, co wyglądało fajnie w teorii, ale w praktyce, żeby coś dodać, musiałem trochę pohakować silnik) oraz też zacząłem odczuwać problemy z wydajnością. I tutaj na tym etapie zacząłem eksperymentować z użyciem WebAssembly - ponieważ w profilerze zobaczyłem, że dużo czasu CPU schodzi na liczenie macierzy, postanowiłem liczyć macierze w WebAssembly, używając Rust-a i biblioteki do macierzy pisanej w Rust. I co się okazało? Moja "optymalizacja" nie przyniosła oczekiwanych rezultatów. Być może dlatego, że i tak w JS musiałem iterować po obiektach i masę rzeczy innych robić, a w Wasm tylko liczyłem macierze. Zbyt duża część silnika polegała na (z konieczności) kiepsko napisanym JS, że Więc pomyślałem, że może trzeba jeszcze więcej obliczeń wrzucić do Wasm, najlepiej całe drzewko sceny tam zapisywać i robić tam wszystko, w JS tylko...

Przepisałem na nowo swój silnik 3D. Już dwa tygodnie temu i teraz rozwijam. I trochę zmieniam zdanie w kwestii tego, co jest najtrudniejsze. Napisałem wcześniej: (najtrudniejsze są chyba przeliczenia matematyczne. No i optymalizacja. Nie zawsze wiem, dlaczego mam spadek FPSów na przykład). Teraz myślę tak - tych obliczeń matematycznych wcale nie ma tak dużo (przynajmniej do tej pory). Optymalizacja też jest dość prosta (przynajmniej do tej pory udało mi się zrobić jakąś tam podstawową optymalizację - np. instanced rendering, trzymanie w pamięci raz utworzonych buforów i listy obiektów do renderingu (zamiast tworzyć to co klatkę) itp. Jednak silnik się powoli rozrasta i zaczynają mieć znaczenie decyzje projektowe - jak coś zrobić nie od strony technicznej, tylko od strony architektury. Tak, żeby silnik był elastyczny, ale jednak prosty, i nie przeinżynierowany. Abstrakcje są potrzebne, ale trzeba wyczuć, jakie to abstrakcje. Wydawać by się mogło, że pierwszą rzeczą, jaką należał...

Zmieniło się trochę. Nie tylko robię edytor, ale i cały silnik do gier w JavaScript (nastawiam się na 2D). Dlaczego? Cóż, zacząłem robić ten edytor na frameworku Phaser, co początkowo dało mi kopa. Phaser ma bardzo dobre wsparcie, dużo przykładów i świetne community. Na każdy problem mogłem znaleźć szybko odpowiedź w necie. Phaser posiada również dużo przydatnych ficzerów do obsługi sprajtów (częściowo wziętych z biblioteki Pixi). Więc mogłem zrobić szybko mój prototyp edytora . Problem jednak w tym, że Phaser to framework, więc tak jak każdy framework - ogranicza . Ciężko zrobić coś większego, dopasować to pod swoje potrzeby. Dlatego postanowiłem zrobić własny silnik, dopasowany do moich potrzeb. Czy to nie jest porywanie się z motyką na słońce i niepotrzebne odkrywanie Ameryki? Nie. Zrobienie pewnych rzeczy samemu jest często o wiele prostsze niż walka z frameworkiem-kobyłą. Robiąc własny silnik mogę również wszystko kontrolować, wprowadzać tam taką architekturę oraz wz...

Ogarniam ostatnio Three.js . Piekielnie fajną bibliotekę do natywnej grafiki 3D w przeglądarce (wewnętrznie biblioteka korzysta z WebGL). W dość prosty sposób można stworzyć obiekt sceny 3D, dodać do niego obiekty, światła, kamerę, potem jakieś animacje. Tu jest link do tego, co można w tym zrobić: Three.js - przykłady (wymagają przeglądarki obsługującej WebGL ). Wietrzę w tym dużą przyszłość. Udało mi się już zaimportować prosty model z Blendera - jest to tego specjalna wtyczka: wtyczka do eksportu/importu Blender-Three.js niestety jeszcze nie udało mi się zaimportować do końca materiałów (ale może dlatego, że samego Blendera nie ogarniam zbyt dobrze, i nie wiem czy przypisałem dobrze materiały i tekstury w Blenderze). No ale że Three.js to jedynie silnik graficzny, renderer - to można robiąc swoją aplikację podpiąć pod to różne inne biblioteki - ja podpiąłem zewnętrzny silnik fizyki Chipmunk, o którym pisałem poprzednio (z tym, że on nie jest do 3D akurat, tylko do 2D). Wi...

Postanowiłem zamiast używać Phasera, skorzystać z Pixi, biblioteki graficznej na której Phaser się w duuużej mierze opiera. Czym jest Pixi ? To po prostu szybki silnik renderujący grafikę 2D w przeglądarce, korzystający z WebGL (jeśli jest dostępny), w ostateczności ze zwykłego Canvasa. Wokół tej biblioteki Phaser dodaje swoje dodatkowe funkcje. Tylko tak - "silnik renderujący" - wydaje się, że to coś strasznie niskopoziomowego? No właśnie nie. API jest może jeszcze prostsze od Phasera. W zasadzie super proste, jeśli miałeś do czynienia kiedyś z programowaniem pod Flasha - bo w Pixi większość funkcji i obiektów opiera się na klasach z ActionScriptu - mamy obiekt Stage, Sprite etc. Mamy hierarchię obiektów na scenie, filtry, zdarzenia myszy/dotyku etc. Pomyślałem więc, że jeśli i tak mi Phaser nie do końca odpowiada (i czuję, że pisząc w Phaserze po prostu musiałbym jednak dodatkowy metaframework zrobić do niego), to może wyjmę z niego samą bibliotekę, na której się on ...