jeżeli chodzi o samo symulowanie trójwymiaru to tak jak Threef powiedział wszystko ogranicza się do split screenu i dwóch kamer. Problemem jest po prostu sterowanie. Na pewno da się napisać jakiś DLL co by dekodował sygnał z akcelerometru/żyroskopu z Oculusa, ale chyba nikt czegoś takiego jeszcze nie zrobił, dlatego trzeba by było po prostu ograniczyć sterowanie do samej myszki jak w normalnym fpsie. Tutaj jest jakiś prosty przykład z neta http://www.mediafire.com/file/dbgtdvon94077jk/GM+VR+custom+HMD.gmk
Tak czy inaczej może pytanie trochę infantylne, ale jak chcesz coś takiego zrobić, to nikt Ci nie broni Jakieś gogle VR masz ogólnie, by móc sobie to testować? Jak masz np tylko takie na komórkę, to i tak nie ma większego problemu, by streamować obraz z komputera na ekran smartphona.
nie no, jeżeli naprawdę jesteś rocznik 97, to siłą rzeczy musiałeś trochę tej wiedzy na matmie zgłębić. Szczerze mówiąc co jak co, ale podstawowa licealna matematyka jest jak najbardziej na miejscu jeżeli chodzi o tworzenie gier. Ale jedynie starczy ci szczątkowa znajomość właśnie trygonometrii i układu kartezjańskiego. To całkowicie starcza, by sprawnie się game makerem posługiwać na moje oko. Jeżeli rozumiesz naturę sinusoidy i masz przestrzenne wyobrażenie jak można ją przekształcać to nie miałbyś z tym najmniejszego problemu. A animowanie przy jej użyciu jest naprawdę proste. Przykładowo jeżeli do poruszania postaci wykorzystujesz zmienną speed, to starczy stworzyć jakąś nową zmienną od animowania np. tułowia postaci (anim=0;). Później w stepie starczy wpisać coś pokroju anim+=speed, a później rysując tułów w draw wystarczy do współrzędnej Y dodać coś w ten deseń: draw_sprite(tulow_spr,0,x,y+sin(anim/20)*20). I teraz sprawa wygląda tak - dziedzina sinusoidy jest zawsze w radianach, czyli jednostkach opartych na pi. Pełen okres sinusoidy wynosi 2 pi, czyli około 6,28. Teraz na chłopski rozum jeżeli speed gracza wynosi mniej więcej 3, to wyciągając sinus z anim ta sinusoida wykona pełen okres w ciągu zaledwie około dwóch stepów (2 pi/3), więc zdecydowanie za szybko. Dlatego trzeba zwykle podzielić to anim na jakąś sensowną liczbę, w tym przypadku 20. Wtedy zakładając, że prędkość rooma to 60, teraz sinusoida wykona jeden okres po mniej więcej właśnie 60 stepach, czyli sekundzie. Do tego starczy pamiętać, że amplituda sinusoidy wynosi 1 (czyli przyjmuje wartości od -1 do 1), więc jeżeli chcesz, by w tej animacji tułów wychylał się np na 20 pixeli, to mnożysz tego sinusa razy dwadzieścia. I to naprawdę wszystko, jeżeli coś pamiętasz ze szkoły to spokojnie szybko to łykniesz i będziesz się tymi sinusami posługiwał biegle. Do tego strasznie to satysfakcjonująca rzecz moim zdaniem :). Wielkim plusem takiego rozwiązania jest też to, że prędkość animacji jest już wtedy automatycznie uzależniona od prędkości gracza, a dodatkowo jeżeli gracz porusza się do tyłu (speed<0), to animacja również automatycznie się odwraca. Dobra, nie mam daru tłumacza, ale mogę szybko wykonać jakiś prosty przykład w game makerze 8.0.
animacja.gmk
