Dawidds

Obiekt[] tablica = new Obiekt[x]; ?

if(asdf != null) { //istnieje } Ale rozwiń Twoją wizję sprawdzenia "czy obiekt istnieje" i czym się to ma różnic od sprawdzenia "czy zmienna istnieje".

Fajnie. Czemu nazwałeś minecrafta Terum?

Coś spierdzieliłeś, wywal na razie cały Twój kod odpowiadający za save'owanie i wtedy spróbuj.

Po co? Rogi może sobie policzyć lengthdirami jeśli chce, a rysowanie spritu przez dwa trójkąty to tylko niepotrzebne użycie paru funkcji zamiast jednej. A w ogóle to wiesz, że to co chcesz uzyskać nie ma nic wspólnego z fizyką i nawet jak Ci wyjdzie to będzie zbugowane i będzie wyglądać beznadziejnie?

ah te ciekawostki z demotywatorów/joemonstera

Rozwiń trochę Twoją wizję tego jak miało by to działać, bo jak dla mnie technicznie nie jest możliwe narysowanie czegoś _pod_ wcześniej narysowanym obiektem (a na pewno nie pod półprzezroczystym). W gmie nic nie jest sortowane, a już na pewno nie co stepa (zrób sobie test i zobacz ile by trwało sortowanie listy nawet 1k elementów 60 razy na sekundę) - po prostu w momencie tworzenia instancji jest ona wstawiana do kolekcji instancji od razu w odpowiednim (według depthu) miejscu. Ewentualna zmiana depthu wymusza po zakończeniu eventu draw (albo gdzie indziej, to akurat nieistotne) przestawienie tej konkretnej instancji w inne miejsce. Nie można narysować czegoś POD wcześniej narysowanym półprzezroczystym spritem, więc jeśli miała by istnieć możliwość zmiany depthu podczas rysowania to tylko tych instancji, które ZA CHWILĘ mają zostać dopiero narysowane. Tej, którą właśnie rysujemy nie można narysować _wcześniej_, co najwyżej można ją przesunąć kawałek dalej i wykonać drawa jeszcze raz _za chwilę_, ale to też by było troszkę pozbawione sensu (wykonywać draw dwa razy w czasie jednej klatki?).

Z 5 razy z rzędu, jak pojawia się pierwszy quest: Zróbcie z tym coś bo chcę pograć a ni uja nie mogę ominąć tego bugu, co bym nie robił to w momencie wyskoczenia tego 3 questu wyskakuje to coś i nie da się tego zignorować ani nic ;[

Jeśli to miał być symulator proszku to więcej byś an tym stracił niż zyskał ;p Problem tutaj tkwi nie tyle w grawitacji (która i tak nie wyrobi przy tylu obiektach) co w samym sprawdzaniu kolizji. Gm sprawdza kolizje na zasadzie każdy z każdym co daje nam piękną złożoność kwadratową i dla nawet 1k obiektów z których każdy sprawdza kolizję z każdym otrzymujemy 1 milion sprawdzeń kolizji (najpierw pewnie sprawdza po bboxie, ale milion to i tak dużo, dla 50k będzie 2,5kkk). Dla czegoś takiego albo się robi octree albo (jeśli obiekty są _w miarę_ równych rozmiarów) po prostu przechowuje się obiekty w siatce _kwadratów_, gdzie każdy kwadrat jest kolekcją obiektów które się w nim znajdują, i wtedy sprawdzamy kolizje tylko z tymi w aktualnym oraz w sąsiednich kwadratach. Ale jako, że pisanie własnej kolizji w gmie byłoby głupotą: nie, nie da się ogarnąć takiej liczby obiektów w gmie. Ani gml Ci na to nie pozwoli (bo jest za wolny) ani nie będziesz miał jak sprawdzać kolizji (wbudowane się nie nadadzą a swojej nie możesz napisać (patrz: gml jest za wolny)).

Po pierwsze - gm zawsze wczytuje całego sprita. Nie ma czegoś takiego jak "wczytam tylko drugą klatkę bo tylko z takiej będę korzystał" - gm nie będzie zgadywał której klatki gdzie będziesz używał i czy przypadkiem w połowie gry nie zachce Ci się zmienić jej na inną. Po drugie - nie wiem skąd wymyśliłeś to . Choćbyś miał tysiąc tych krzeseł to i tak do pamięci będzie wczytany jeden sprite. Także odpowiedź: obojętne, ale raczej wygodniej będzie mieć te różne warianty krzeseł w jednym spricie i osobnych klatkach, więc proponuję wybrać tę właśnie opcję. A, i po trzecie: sprity są przechowywane po prostu w ramie. Chyba że to nazywasz pamięcią graficzną, to ok.

Dodaj botom ślady opon, gracz je ma to dlaczego oni mają nie mieć? Najwyżej dasz możliwość wyłączenia w opcjach.

Kupić pro.

Nie mam pojęcia o co może chodzić, mogę powiedzieć tyle że to co zrobiłeś kilkanaście miesięcy temu na gml było beznadziejnym wyborem bo do czegoś takiego tablice aż się proszą żeby ich użyć. Nie wiem czy nie wiesz co to tablice/nie potrafisz ich używać/nie wpadłeś na to że mogły by do tego pasować, ale chociaż spróbuj ich użyć a nie kombinujesz na siłę ze składaniem nazw zmiennych. Masz nawet jakiś jakże złożony fragment kodu, nie wiem po co ci on ale może sie na coś przyda int[] tablica = new int[10]; tablica[3] = 4; tablica[6] = -12; for(int i=0; i<tabica.Length; i++) { Console.WriteLine("Element " + i + " w tablicy wynosi " + tablica[i]); }

http://dawidds.net/lol/polskieznaki.7z Tak na oko to dodaje polskie znaki do gdzieś 70% słów, nie _powinien_ niczego zjebać bo jak nie jest pewny słowa (ma wiele możliwości) to go po prostu nie zmienia. Pierwsze okienko to wczytywanie (plik źródłowy), drugie to zapis, ale tego się chyba domyślisz. Źródłowy może być kodowany w byle czym i _powinien_ wczytać i tak, docelowy będzie kodowany w utf8, ale to z kolei Cię pewnie gówno obchodzi więc się już nie rozpisuje D: Jeśli się nie odpala to ściągnij .net framework 4, mogłem skompilować pod jakiś starszy ale wpadłem na to teraz a wrzucać drugi raz mi się nie chce, jakoś se poradzisz.

Widzisz, odrazu lepiej

aha, dzięki kapitanie oczywistyMhm? Pieprznąłeś głupotą że zalatywało z kilometra to wyjaśniłem jak to zrobić żeby nie muliło. Skoro to takie oczywiste to trzeba było nie gadać wcześniej głupot. Chyba że to taki żarcik był, to ok.

Nie? Nie musisz przecież przelatywać całej bazy co każde słowo, robisz tylko hashtable dla wszystkich słówek które mają w sobie chociaż jedną polską literkę, gdzie kluczem jest słowo bez polskich znaków a wartością oryginalne słowo i masz ładną wydajność, gdzie ładna to u mnie 30kb tekstu przełożone w 276ms (trochę dłużej trwa przygotowanie bazy, ale te 5 sekund można na odpalenie programu poczekać). Programik w sumie mam i w sumie działa, problemik jest tylko taki, że często jest więcej niż jedna możliwość dodania polskich znaków do słowa, i przez to powstają takie abstrakcje jak "ją" zamiast "ja", czy lepiej "ód" zamiast "od" (cokolwiek znaczy "ód"). Zrobię żeby w takich przypadkach (jak więcej kilka polskich słów ma takie same bezpolskoznakowe odpowiedniki) nie zamieniał słowa w ogóle, dorobię obsługę wielkich liter i mogę wysłać. Jaki ja uczynny dzisiaj. Ed: Mhm, z kodowaniem też się będę musiał pobawić bo zamiast ł robi kwadraciki.

Daj mi jakiś plik txt z listą słów z polskimi znakami to Ci sam taki napiszę.

Ja bym proponował takie coś (bardziej złożone ale jeśli Ci wyjdzie to będzie wydajniejsze i jednocześnie nie będzie używać niepotrzbnych render targetów. A w ogóle to wykorzystanie przeszukiwania binarnego do zrobienia "lasera" ma sens tylko w gmie, gdzie wywołanie funkcji kilka razy więcej jest mniej optymalne niż sprawdzanie (przez grę już) dwa razy tyle pikseli ile rzeczywiście potrzeba <- taka uwaga do autora aby nie przyszło mu do głowy napisać własne collision_line i skopiować kod. Więc tak: 1. Lecisz w pętli po wszystkich ściankach, interesują Cię tylko te, które są zwrócone do gracza _twarzą_ (możesz sprawdzać kąt, możesz porównywać pozycje, możesz pojechać iloczynem skalarnym (vector2.dot), jak Ci będzie bardziej pasować. jeśli to tylko prostokąty to porównywanie pozycji wystarczy). I teraz tak: 2. Jeśli oba wierzchołki ścianki są w zasięgu pova (vector2.distance()) (na rysunku jasny szary) to po prostu rysujesz trójkącik <player, punkt1, punkt2>, banał 3. Jeśli żaden z wierzchołków ścianki nie jest w zasięgu pova to nic nie rysujemy, też chyba banał 4. Jeśli tylko jeden wierzchołek jest w zasięgu pova (ciemny czary) robi się ciężej, tym razem punkt2 jest poza granicą widoczności więc jego wykorzystać jako wierzchołka nie możemy. (przenosimy się na rysunek 2) 5. Na pewno musimy narysować trójkąt <player, punkt1(ten po lewej), miejsce przecięcia naszej ścianki z granicą fova (na rysunku zielona kropeczka)>. Nie bardzo chce mi się teraz myśleć jak to liczyć, ale jakoś znajdziesz na necie "line circle intersection". Trójkącik na rysunku (drugim rysunku ofc) jest zakolorowany na ciemnoszaro). 6. Na koniec zostaje _tylko_ wypełnić pozostałe białe miejsca (te, któe były białe od początku jak i te, które pozostawiliśmy czyste w punkcie 4/5) fovem, z dokładnością np. do 5 stopni - aby wyszło ładne "koło". Konkretnie jak to zrobić też nie myślałem, ale na pewno będziesz musiał mieć jakąś _kolekcję_, która będzie Ci umownie symbolizować rozpiętość kątu 0 - 360 stopni (0 - 2pi, żeby nie konwertować niepotrzebnie tych kątów co chwila), tak, że będziesz mógł z niej dowolnie "wycinać" fragmenty - dla przykładu masz czystą kolekcję: 1. 0 - 360 //usuwamy fragment 100-200 2. 0-100, 200-360//usuwamy fragment 50-150 3. 0-50, 200-360 Itd. To co "usuwamy" to ofc wszystkie trójkąty, które narazie rysowaliśmy. I teraz już naprawdę _tylko_ lecisz po tych segmentach, które zostały w tej kolekcji i je rysujesz, odpowiednio zwiększając liczbę trójkątów coby wyszło bardziej okrągłe (no wiesz, coś jakbyś rysował koło). Gdybyś sobie z tym nie dał rady albo ta technika sama z siebie by nie działała (mogłem na coś nie wpaść, chociaż wydaje się dobrze) to zostaje sposób graficzny - robisz render targeta o rozmiarze jaki ten fov ma mieć, i najpierw na nim rysujesz (niech będzie na biało) całe koło, później "wycinasz" (niech będzie rysujesz na czarno) z niego obszary zasłonięte przez ścianki - coś, jakby te ścianki rzucały cienie. Wcześniej cieniowaliśmy wszystko PRZED ścianką (i trzeba było kombinować żeby nie wyjechać poza dystans fova) - teraz rysujemy wszystko ZA ścianką - i nie ma tu żadnego kombinowania, dla każdej ścianki która potencjalnie znajduje się w fovie "tak samo" rysujesz za nią dwa trójkąty. Ten sposób jest dużo prostszy i pewniejszy, ale z wydajnością będzie troszkę gorzej - więc jeśli tych jednostek ma być dużo to zastanów się nad tą pierwszą techniką.

16 lat życia w błędzie ;( Dobrze, że nie wpadłem na to żeby dać sobie głowę uciąć bo bym teraz biegał lżejszy o te parę kilogramów ;( Biję się w pierś, zwracam honor i takie tam.

Platyna, gamoniu. Jeśli dasz move_towards_point() w Create to pocisk ruszy się tylko jedną klatkę i stanie. Jeśli dasz w Stepa to wiadomo, będzie skręcał cały czas do myszki. Kodem Konrada pocisk wyleci w kierunku myszki, i już _do końca_ będzie się w tamtym kierunku poruszał -> dobrze.

A mi się oczywiście nie podoba : D Czołgi kręcą lufami z nieskończoną prędkością (nieważne, że mogło by zmniejszyć dynamizm, tak wygląda lipnie), strzelają 4 rakietami na sekundę (które też lecą z przeogromną prędkością), po zabiciu byle kogo wyskakują _teksty_ na pół ekranu (słowo mi uciekło), czołgi spokojnie mogą strzelać do celów oddalonych od siebie może z metr, boty zachowują się inaczej niż gracze (w ogóle nie mają limitu obracania się, obracają się natychmiast tam gdzie chcą (tak jak gracz steruje lufą). Nawet gdyby było w tym multi to ta gra i tak będzie lipna, sama idea strzelających do siebie czołgów nie ma przyszłości. Do tego jakoś nie jestem w stanie dostrzec w tym elementów jakiegoś "skilla" - jakiegokolwiek poziomu trudności, czegokolwiek, przez co rozgrywka była by ciekawa (wciągająca) a nie ograniczała by się do klikania w czołgi przeciwników i zasypywania ich seriami rakiet niczym z karabinu maszynowego. Ale nie grałem więc mogę się mylić.

GML ilosc_klatek_w_sekundzie = fps

:thumbsup: I rzeczywiście, odkąd pamiętam zawsze mi brakowało trampolin w minecrafcie. Biorę się za pobieranie, ocenę dam w edicie

Lolmentos, jesteś epicki : D Filozofujesz na siłę, nie żadne magiczne "jeśli się nakładają i mają różny depth to ta z mniejszym narysuje się na tej z większym" i "najpierw wykonują się beginstepy w kolejności id w najdalszych warstwach", tylko po prostu "instancje są sortowane po depthu", i to Ci rozwiązuje wszystkie pytania. Instancje z mniejszym depthem rysują się "wyżej" dlatego, że rysują się później, jeśli mają taki sam depth to "wyżej" narysuje się ta wcześniejsza dlatego, że tylko depth jest wyznacznikiem przy sortowaniu - jeśli depth jest taki sam to dwie instancje nie zmieniają się miejscami -> później utworzone rysują się później. A wszystkie eventy wykonują się w takiej samej kolejności co Draw bo zwyczajnie nie opłaca się zmieniać kolejności rysowania dwa razy na klatkę jak i tak nic by to nie zmieniło. Po to są te wszystkie Beign Stepy Stepy i End Stepy aby po nich rozróżniać kolejność i nie zagłębiać się w to w jakiej kolejności wykonują się eventy.