Exigo

Nie no spoko. Jak obiecałem, jest topic z exekiem.

Pomyślałem że wrzucę. Dawno temu napisałem shootera, projekt się rozrastał (za bardzo), ale sposób w jaki wszystko implementowałem był "addytywny". Doszło do tego że nie mogłem tego ogarnąć, a zmiana kodu gry była niemożliwa. Teraz piszę wszystko od nowa, z głową, i z planem. Poniżej link w wersji "_v15". ; ) https://gmclan.org/uploader/3290/exigotestgame.zip Hasło "gmclan". Fajnie jeśli napiszecie czy wam wogóle się odpala, jak chodzi, etc. @Edit:

Huder, powiem ci tak: nie mam gm81. A jeśli chodzi o całą "technologię", to: Cała gra ma miejsce w jednym obiekcie. Create jak create, robię surface wielkości ekranu. Draw, mam całą logikę i rysowanie. Begin step: Targetuje tego surface, robię redraw, zamykam target. Potem go rysuję (surface). Destroy: Usuwam. Cały post process jest liczony w begin step, od momentu zapisania redrawa do surface, a wyświetleniem go. Btw. postaram się zaraz upnąć exe, na potwierdzenie że działa. ; )

Całość jest renderowana do surface (użycie funkcji redraw). Na każde światło przypada po 1 surface, tylko że z określoną jakością (zeskalowanym rozmiarem) (tutaj mają po .25, czyli na 1 piksel cienia, odpowiada za 4x4). Po wypaleniu świateł (czyli po uwzględnieniu cieni), wszystko jest mixowane do jednego, i potem naklejanie na ekran. Do post processingu używam jeszcze surface służącego za bufor, tzn. przeskakuje z jednego (ekranowego) na drugie, czy ewentualnie odwołuję się do jakiegoś. No i jest jeszcze jeden, odpowiedzialny za interface. Plus jeszcze parę. Tak, bez świateł, to będzie z 8 (z czego 3 mają rozmiar 512x512, i jeszcze jeden, ale istnieje tylko chwilę, bo generuje i zapisuje "szum"). Namieszałem. Ciężko się odnaleźć ogólnie. ; ) (a ten "blur" jest wynikiem utraty jakości świateł przez skalowanie. Mógł bym też rysować penumbrę, ale to jest z założenia wolne)

Uzjel, to co widzisz, jest pisane od nowa. Btw. przed chwilą napisałem proste wykrywanie krawędzi. ^^ Sprawne oko zauważy: Btw. https://gmclan.org/uploader/3290/wykrywanie_krawedzi.jpg

I tak nic nie widać przez tego blura. Ale po kolorach można rozpoznać że działają dynamiczne światła, z czego jestem dumny. Pozostaje jedynie kwestia napisania edytora do plansz. No i udało się cały "post" zintegrować z biblioteką do shaderów. ; )

Zaznaczyłem "nie-altruistyczne". Znaczy: kod jest zamknięty. ; )

Są jakieś generatory, schematy, wzorce do użycia, których treść zapewnia autorowi wygodną pozycję prawną w razie czego? Wiadomo, takie "nie-altruistyczne", ale rozsądne zasady, w stylu "użytkowniku! odpalasz na własną odpowiedzialność, nie kopiuj plików i nie podszywaj się pod moje autorstwo, baw się dobrze, a jak coś, to pisz na maila". Hm? ; )

Dzięki za zainteresowanie. Już wpadłem na rozwiązanie. ; ) (kawałek kodu z gry (wczytywanie nazw sprite z pliku, np. 'nazwa', i po przerobieniu 's_nazwa' z adresowaniem)) static[static_max, 0] = file_text_read_string(plik); file_text_readln(plik); execute_string('static[static_max, 0] = s_' + string(static[static_max, 0])); ..od tego momentu odwołanie do static[i, 0] zwraca sprita.

Wczytuję sprite: Przykładowo (w kodzie): s_sprite = add_sprite(...); Mamy dalej coś takiego: x = "s_sprite"; I chcę zrobić coś takiego: draw_sprite(domysl_sie(x), 0, 0, 0); Gdzie funkcja domysl_sie() zwraca mi adres do sprite na podstawie treści stringa. ; ) Dobre, co? Jakiś pomysł? ;)

Bump. Wymyśliłem żeby dodać zmienną reprezentującą pozycję view-a jako "kamerę". Dokonuje w niej wszelkich obliczeń, i na koniec nadaję pozycje view-om. Potem obliczam różnicę z tego, i na podstawie wyniku rysuję surface ekranu (fun fact, trzymam wszystko w surface) z tym przesunięciem (różnicą). Strata jest w tym, że na krawędziach ekranu są artefakty, ale przynajmniej nie rzuca nim przy dużym przybliżeniu. Tak to mniej więcej wygląda: (pozycja kamery jest centrowana na pozycję gracza) GML view_xview = kamera_x - (view_wview / 2); view_yview = kamera_y - (view_hview / 2); view_wview = startowy_view_wview / kamera_zoom; view_hview = startowy_view_hview / kamera_zoom; kamera_xview_roznica = (view_xview + (view_wview / 2) - kamera_x) * kamera_zoom; kamera_yview_roznica = (view_yview + (view_hview / 2) - kamera_y) * kamera_zoom; draw_surface_ext(ekran, kamera_xview_roznica, kamera_yview_roznica, 1, 1, 0, c_white, 1); Jeśli ktoś wpadnie na inny pomysł, niech pisze. ; )

Problem istniał od dawna, ale dopiero teraz zaczął mnie wnerwiać. Pytanie klucz: czy istnieje opcja aby pozycja viewa (np. view_xview) miał wartość zmiennoprzecinkową? A chodzi mi o to: Mój problem leży w zoomie, który działa natywnie w bardzo prosty sposób: view_wview = staly_view_wview / zoom; view_hview = staly_view_hview / zoom; (gdzie zoom >= 1) I tyle. Przy przybliżeniu np. dwukrotnym (zoom = 2), kiedy przypiszę wartości view_xview wartość nie-całkowitą, tak czy siak pozycja ekranu zwraca mi wartość zaokrągloną. W efekcie przemieszczanie kamery jest równoznaczne ze "skakaniem" (przez to zaokrąglanie!) co jest bardzo widoczne przy sporym przybliżeniu. Pomysły? ; )

Z tego przykładu jest AŻ tekstura. I na tym się kończy. Takie małe sprostowanie. ; )

Wygląda żywiej. : )

Faktycznie, bf3 miałem na myśli. A tobie Tymon wyślę natychmiast po powrocie do domu. ; )

Właśnie skończyłem pisać przestrzenny interface coś na wzór technologii Scaleform (crysis, unreal, bf2 etc.). Btw. znowu robię shootera. Tylko tym razem wszystkie składniki rozplanowałem. ; D

Tak, przyznaję ci rację, gra jest warta uwagi. Stonowana, z klimatem. Mimo wszystko gameplay nie jest tu wabikiem. Nie rozumiemy się. ; )

Czy jesteście w stanie wskazać przykłady których grywalność nie jest definiowana przez obsesyjną ilość contentu (epickość AAA np.), ale przez oryginalny gameplay będący głównym wabikiem na grę? - i będących studnią inspiracji? Pomijając gry spod imion takich jak Edmund McMillen (Gish) czy Kyle Gabler (World of Goo), z którymi miałem już spotkania (btw. dobry przykład, co mam na myśli). Co?

Niektóre gry mają fajny sposób informowania gracza o pozycji obiektu, celu, czegokolwiek ważnego, mimo że nie widzimy tego "w rzeczywistości" (tzn. jest poza ekranem). Dobrym przykładem było by przytoczenie GTA, gdzie strzałeczki pokazywały kierunek do głównych celi znajdując się wokół gracza. Mi natomiast chodzi o reprezentację w taki sposób, aby symbole pokazywane były na krawędzi, nie w kole, ale dostosowując się do rozmiaru i proporcji okna. Tzn. w pewnym sensie "punkt dążący od środka ekranu, do celu, zatrzymywany przez krawędź okna". Rozrysowałem to mniej więcej tak: Jakiś pomysł, jak to napisać? ; )

Używanie lengthdirów w tym przypadku jest przekombinowane: Ustalasz różnicę pozycji, dzielisz przez dwa, i dodajesz to do pozycji kamery: (kod kamery) GML x += (gracz.x - x) / 2; y += (gracz.y - y) / 2; Albo używasz gmowych wektorów: (kod kamery) GML friction = 0.25; motion_add(point_direction(x, y, gracz.x, gracz,y), 1);

Podoba się. Pusto w tle, brakuje czegoś. Może tło warstwowe? Wiesz, rysujesz tak, aby było zjawisko paralaksy gdy przemieszczasz kamerą. (tzn. jakieś zapętlone laski/pagórki o 1/2 pozycji kamery plus "odległe" góry). Od tego białego koloru wszystko jest kontrastowe i dostaje się oczopląsu. ; )

Poszukuję software do renderowania atraktorów. Miał ktoś styczność z tym tematem? ; )

http://www.youtube.com/watch?v=MnkAldKbGzs He he.

Z mojej strony: - Sacrifice - AoE2 - Rise of Nations - Rome Total War - Warrior Kings - Total Annihilation (oraz słowo klucz: "Spring RTS")

Nie chce cię wykorzystywać, ale możesz powiedzieć coś o przesyłaniu pozycji w almorze/aliensach? ;)