Exigo

Tzn. przedstawię to w inny sposób, bardziej praktycznie obrazując: Jak napisalibyście przesyłanie pozycji za pomocą 39dll postaci znajdującej się w układzie pełnym skrzynek zintegrowanych z silnikiem fizycznym. :) A tak po za głównym wątkiem, mamy bajta, czyli całkowite od 0 do 255. Jak zapisać do niego binarnie dwie wartości o zakresie 0-128?

Dzięki za odnośniki. Wyjaśniły parę rzeczy. Ponadto w tych artykułach jest sporo linków do stron dalej pogłębiających tematykę. : )

Tak, to jest układ w kwadracie o czym ty mówisz. Już o tym napisałem. ; ) Zostaję jednak przy kierunku i długości, ze względu na sposób poruszania. Porównując pole kwadratu do koła, ok, masz to samo. Tylko że pierwotna opcja pasuje bardziej ze względu na sposób poruszania (hm, jak by to powiedzieć: "lengthdirowo"), czyli w kwadracie obszary skrajnie odległe jak rogi by nie byłyby wykorzystywane. Poza tym nie muszę tego przeliczać, tylko od razu mam gotowe do przypisania dane.

Najpierw napiszę o co mi chodzi. ; ) Jeśli założymy, że przemieszczamy obiekt w układzie który nie jest w stanie wpłynąć na zmianę pozycji. Najprostszym przesyłaniem danych będzie zwykły "input-output", gdzie filozofią będzie przewidywanie ruchów na serwerze. W grę wchodzi tylko TCP, a dane są zawsze bezbłędne na wszystkich klientach. Proste jak flaki z olejem. Ale do tego tematu trzeba podejść inaczej, jeśli układ w którym jest nasz obiekt, może czasami losowo (lub na pewnych, ale nadal nieprzewidywalnych zasadach) na niego wpłynąć. Wtedy powyższy pomysł input-output zwyczajnie odpada. Prostszym rozwiązaniem jest wtedy mityczne przesyłanie pozycji, i mamy to z głowy. Tylko że jeśli przesyłamy dwa shorty co klatkę, rozmyślamy się bo wiemy że to za dużo, i kombinujemy dalej. Jakiś pomysł? Moje zasady obiektu (jakie przychodzą mi do głowy) są dwie: - przemieszcza się w układzie o szerokości i wysokości shorta (czyli od -32768 do 32767). - co stepa maksymalnie może przemieścić się w polu koła o promieniu od 0 do 255, i o kącie od 0 do 360 (kąt możemy przekształcić na zakres byte (0-255), dzieląc przez 1,4). (Przemieszczenie możemy też opisać wektorowo, odejmując nową pozycję od starej. Uzyskamy to samo, ale w polu kwadrata o szerokości 255x255. Bardziej odpowiadającym tym wymaganiom będzie jednak pierwszy sposób, w kole, ze wzg. na sposób poruszania (trygonometryczny)). To co wymyśliłem to: - Jeśli nastąpi jakiekolwiek przemieszczenie, przesyłam trzy wartości (np. co 2 klatki), gdzie pierwsza to identyfikator (bajt mówiący jakie są dalsze bity), druga (bajt) to długość, trzecia (bajt) to kąt. - Co parę sekund przesyłam pozycje korygujące, czyli identyfikator paczki i dwa shorty (x i y). Wektory są obsługiwane w ten sposób, że co stepa aktualizują przemieszczenie, nawet jeśli gracz nie przesyła żadnych danych - w pewnym sensie "przewiduje" jego drogę, bo wiadomo że się przemieszcza. Wszystko jest przesyłane w miarę szybko, ale nie za dokładnie. Często skacze. Zakładam, że ktoś już miał kontakt z podobną tematyką i problemami, dlatego też jeśli macie jakieś pomysły lub pisaliście jakąś sieciówkę, podzielcie się doświadczeniem, proszę. :)

Orientuje się ktoś w jakiejś bibliografii czy artykułach w internecie na temat pisania architektury sieciowej do gier? Wiecie, serwer-klient, przewidywanie ruchu, synchronizacje pomiędzy graczami i niwelowanie opóźnień, kompresja i sposoby przesyłania danych, cała filozofia tego etc. Coś dla osoby która pisze bardziej fps'a niż turówkę. Temat obszerny. : )

Wyłącz autodraw na starcie, a w np. jakimś stepie targetuj surface wielkości ekranu i wywołuj redraw. Step będzie wyglądał tak (po kolei): targetujesz surface od ekranu, robisz redraw, zamykasz target, rysujesz surface (draw _surface). Pomiędzy resetem targeta a rysowaniem, masz jedyne miejsce w kodzie gdzie dokonujesz wszelkich operacji, np. robisz sobie z tego wodę, i nadpisujesz do surface przed końcowym rysowaniem.

Wolne, bo rysujesz wszystkie drawy x2. Słowo klucz: set_automatic_draw(false);. : )

Gramy kulką, i robimy różne rzeczy z "łapami", np. przeciągamy przedmioty, strzelamy do przeciwników, łapiemy za przeszkody, czy po prostu przemieszczamy się. ; )

O to mi chodziło Will, dzięki. : ) (Powinieneś pracować w yoyogames!)

Czyli - czy istnieje jakaś funkcja, sposób pozwalający na sprawdzenie czy obiekt koliduje z czymkolwiek, oraz zwrócenie identyfikatora body z którym jest ta kolizja? (ExtremePhysics)

Teraz lata przy 60 fps na 6 światłach i 16 dynamicznych casterach (przy statycznych, wszystkie cienie mógł bym sobie na starcie wypalić). Dużo optymalizacji, szybko chodzi, zadowolony. Wszystko się ogranicza do "dodaj światło", "zgaś światło", tak grubym uogólnieniem, muahaha. ; )

Ostatnio piszę sobie coś jak "framework" (silniczkiem tego nazwać nie wolno), gdzie wpisuję wymyślne systemy obsługi świateł, bloomy, motion blury, depth of fieldy, i inne niepotrzebne pierduty. Połowy efektów nie widać (trzeba je widzieć w ruchu). Wrzucę gmk jak będą z tego ręce i nogi. ; ) Narazie kminię penumbrę i jakiś fake-normalmapping.

Dzięki za wszystkie linki, problem przeminął. (zrobiłem na chama, czyli, jak poradził Shock, wyczyszczam białego surface subtractem).

Pierwszy obrazek (od lewej) to świeży surf, bez niczego. Drugi, to ten gdy go prze-blenduje invertem, gdzie nie wiem czemu kolory zostają odwrócone bardzo dziwnie (sprawdziłem wszystkie mixy blendowania, żaden nie odpowiada). Trzeci to surface, jaki niesamowicie pragnę uzyskać. Porady? ; ) !Edit: Uwaga, rozkminiłem że mogę dodać (bm_add) przed invertem kolory w postaci 128 (szary), przez co "przekraczam granicę" w tym że szary to biały, a czarny to czarny.

Ok, w takim razie zakładamy że masz tablicę w której trzymasz mapę, tak? Dobra, tak opisowo: Tak wyglądają nasze dane: int x = 256, y =256, gracz_x = 33, gracz_y = 79, x2, y2, rozmiar_kafelki = 15; int mapa[x][y] = {0}; (0 oznacza nic) Teraz musisz przypisać komórkom jakieś wartości. Nie wiem jak to robisz, czy wczytujesz to jakoś z tekstu, czy bitmapy, może generujesz, nie wiem. Wszystko jedno. Zakładamy że w tej tablicy masz opisaną mapę. ; ) x2 = floor(gracz_x/rozmiar_kafelki); (czyli gracz jest np. na pozycji 215, to po przekształceniu 14,3333, co daje 14 - indeks komórki) y2 = floor(gracz_y/rozmiar_kafelki); I w ten sposób, liczby x2 i y2 to adres do komórki, która jest "na graczu". Na podstawie tego pobierasz sobie wartość, i liczysz kolizję na prawach fizyki jakie sobie tam wymyślisz. Komórka "pod graczem" to k = mapa[x2, y2 + 1];

Najpierw określ się, czym jest dla ciebie mapa. Bo tak chaotycznie piszesz że już sam nie wiem co tam masz. Jeśli masz mapę w postaci tablicy, to czy: a ) wartości jakie przyjmuje to 0 (jest to pusty "blok"), czy 1 - (kolidujący blok). b ) wartości masz takie, aby obsługiwać jakiegoś tileseta (tzn. liczba reprezentuje grafikę którą chcesz rysować), czyli 0 - nic, 1 - trawa, 2 - kamienny blok, 3 - woda, etc. i potem na podstawie tego z czym mamy do czynienia dostosowujemy odpowiednie zachowania postaci, np. spadamy w dół, odbijamy się, pływamy, etc. ???

Jeśli mapa kafelkowa oznacza pojęcie tablicy 2d z wartością reprezentującą typ obiektu (np. 0 nic, 1 kolizja), to sposób jest prosty. Jeżeli każda z kafelek ma np. 16x16 pikseli, to x=floor(gracz_x/16) i otrzymujesz indeks (w tym przypadku poziomy) tablicy. Podobnie robisz z y, i otrzymujesz w ten sposób adres do komórki będącej "w" pozycji gracza. W taki sam sposób możemy sprawdzić co jest pod nim (dodajemy do y wartość 1), po lewo (x - 1), w prawo (x + 1), gdzieś (x + 3, y - 15), itd. Skracając: x = floor(gracz_x / 16); y = floor(gracz_y / 16); if tablica[x, y + 1] = 1 to znaczy że mamy coś pod sobą, na czym można stać (1 oznacza że komórka jest, em.. "twarda"). Grunt to "przerobienie" pozycji gostka na pozycję w tablicy.

Enya - Caribbean Blue

Rysując GUI bez żadnego podkładu, szczególnie jeśli jest to jeden z ważniejszych elementów grafiki (widzimy to w zasadzie przez większość czasu gry) powinieneś postarać się o dokładność. Najlepszą techniką w tym przypadku jest wyrenderowanie (w czymkolwiek) bazy, zawierającej światła, cienie i proste kolory z oświetleniem globalnym. Potem wrzucasz to do PSa i robisz resztę ręcznie. Ta technika jest dobra z bardzo prostej przyczyny - nigdy nie uda ci się odwzorować do perfekcji skali, proporcji, idealnych cieni i świateł. No ale od tego masz komputer i pojęcie render. ;D Jeśli ci zależy na dokładności, powinieneś to robić własnie tak. ; )

To jak się już dostanie, niech zmieni hasło, na coś mocniejszego. Odpalasz antywirusa, jak nic, to uruchamiasz hijackthis i szukasz potencjalnego keyloggera.

Tak, dla odmiany, dzisiaj był pixelart. ; D

Trochę po bazgrałem przy tym mutancie co zamieściłem tu wcześniej. Poprzednio były marudy na temat sumetrycznej pozy. W tym przypadku ją trochę "ożywiłem".

Źle zrozumiałeś funkcję. Ona zwraca, czyli działa to w ten sposób: GML pytanie = show_message_ext('Co chcesz zasadzic??.','Zasadz Ziemniaki','Zasadz Marchew','Nie sadz nic'); Po wyświetleniu okienka i zaznaczeniu opcji, "pytanie" otrzyma wartość 0 w przypadku gdy naciśnie escape, 1 - pierwsza opcja ('Zasadz Ziemniaki'), 2 - druga, 3 - trzecia. Do wykonywania akcji na podstawie "pytania", możesz użyć switcha: GML pytanie = show_message_ext('Co chcesz zasadzic??.','Zasadz Ziemniaki','Zasadz Marchew','Nie sadz nic'); switch (pytanie) { case 1: { sadzimy_ziemniaki(); break; } case 2: { sadzimy_marchewki(); break; } case 3: { nic(); break; } }

Z tds'em jest ciężko. W zamierzeniu chciałbym zrobić z tego jakiś multiplayer, ale nie starcza mi umiejętności w tym celu. ; D W obecnym momencie projekt jest w pewnym sensie zamrożony (nie wiem jak się za to zabrać), a model zrobiłem dla samego robienia. ; ) PS: Btw. ktoś miał by ochotę włożyć swój grosz do projektu, tzn. pomóc przy napisaniu architektury klienty-serwer (osoba która wie jak się za to zabrać), niech da znać, bo wydaje mi się że szkoda to tak po prostu porzucić. ^^

W zbrushu pipeline przebiega zazwyczaj tak, że zaczynasz od "zsphere" - czyli klejenia jakiegoś ludka z kulek. Potem to się "rasteryzuje" na mapę 3d voxeli, i masz siatkę na której pracujesz. Np. w sculptrisie masz na odwrót, gdzie nie martwisz się o to czy starczy ci poly. ; ) No a to po lewej to właśnie "zsphere".