gnysek

https://wordpress.org/plugins/wp-server-stats/ i inne podobne wtyczki pokazują zużycie serwera.

Tam jest taki milion zmian, że na razie się odnajdź

Właśnie nie mogłem znaleźć info jaki jest ten limit.

3 sekundy i wiesz, że jest wersja trial za free: https://www.yoyogames.com/get

W tak starym GM, to nawet nam się nie chce szukać, jakie funkcje były dostępne, ale raczej nie. Tam cały pipeline od rysowania inaczej działał, to jest jednak 8/9-letnie oprogramowanie, jeszcze przed Windowsem 8...

Cytat roku jak znalazł.

tile_add(background,left,top,width,height,x,y,depth) Adds a new tile to the room with the indicated values (see above for their meaning). The function returns the id of the tile that can be used later on. No chyba już sam odpowiedziałeś, raczej nic więcej w GM8 nie ma.

Dlatego mi działa bez problemu, jednak coś tam optymalizują

Ja robiłem już gry, gdzie jest 10000 instancji w roomie (5MB ma plik samego rooma!) i 60fps aż miło. Więc coś masz ostro źle

FPS spadł, bo rysujesz surface wielkości roomu a nie view. A z kursorem nie wiem, chodzi o kursor windowsowy czy gra miała jakiś własny ?

1) nie rysujemy poza draw w Studio 2) trzeba sprawdzać czy surface istnieje w każdym kroku // create surf = -1; // draw if (!surface_exists(surf)) { surf = surface_create(...); } surface_set_target(surf); ... rysujemy surface_reset_target(); ... draw_surface(....); Nie mniej to niewiele pomoże, bo GM i tak sam odrzuca z rysowania to co jest poza ekranem A efekt pojawia się bo robisz jakieś draw_set_blend_mode_ext nie wiadomo po co.

starsze GM: value = -15 + round(random(30.1)) nowsze GMS: value = irandom_range(-15, 16); random zawsze losuje liczbę a <= value < b, więc nigdy nie dostaniesz b, dlatego piszemy 16 (i 30.1 w przypadku pierwszym)

OK, a weź daj screena tych obrazków, ale ze sprite editora, żeby origin było widać (i coś na około, nie przycinaj tak dokładnie). Mały hint - możesz robić ctrl+v obrazka w poście

Ja z kolei nie rozumiem twojego rysunku. Dobra, inaczej, mamy dwa sprite. Każdy ma origina na środku, więc jak robisz draw_sprite(spr_A, 0, x, y), no to origin tego sprita jest właśnie na pozycji x i y. To wiemy. Teraz mamy drugi sprite, on też ma origina i działa to na tej samej zasadzie. Jak napiszesz, zeby środek pierwszego sprite był 20px od środka drugiego, to robisz tak: draw_sprite(spr_B, x+lengthdir_x(20, dir), y+lengthdir_y(20, dir)); oczywiście za dir podkładasz kierunek, np. dla kierunku 0 i kierunku 45 będzie to tak (sorry za jakośc, to jakiś onlinowy edytor grafiki): Oczywiście spr_B nie jest tutaj obracany, jakbyś chciał, żeby zawsze się obracał względem siebie, to musisz o to zadbać sam. Fioletowa linia to jest te 20px. Oczywiście jak origin bedzie gdzie indziej, to sie wszystko zmienia: Mniej wiecej tak (tutaj jeden spite ma origin w 0,0, a drugi ma w np. 20,0). Będzie wrażenie, że ten sprite ucieka i się zbliża. Dlatego najlepiej, jak masz origin na środku (albo środku przynajmniej jednego boku i obracać dobrze). Po prostu zawsze na początku i końcu linii jest origin, a sprite się rysuje o tyle przesunięty (jak masz origin 30,40, to sprite będzie się zaczynał -30px w lewo i -40 w górę od punktu wynikowego).

No właśnie cała specyfika lenghtdira polega na tym, ze nie musisz pitagorasów/tangensów liczyć, tylko podajesz od razu długość przeciwprostokątnej. Patrzysz zatem na swój sprite który ma się obracać względem pierwszego i na to, jaki ma origin x. To będzie ten width. x + lengthdir_x(w, 0) i y + lengthdir_y(w,0), powinny ustawić origin sprita drugiego, względem origina sprita pierwszego (gdzie x i y to pozycja pierwszego, a w to jest origin x drugiego). Przypominam - 0 to w prawo, 90 w górę, 180 w lewo, 270 w dół, 360 == 0. Zatem jak chcesz następny obrazek ustawić nie względem origina, a prawego końca, to musisz policzyć lengthdira z całej szerokości. Jak kolejny sprite ma origin na środku, ale ma nie zaczynać się na prawej stronie, ale na środku wzgledem tej strony, to kolejny raz liczysz od ostatniego punktu lenghtira o długosci origina. Nie mam żadnego fajnego painta na linuxie żeby to narysować

Czyli tamta jest uber-trudna.

Hm, może po prostu punktem wokół którego postać sie porusza nie powinny być stopy, a klatka piersiowa ? Wtedy kładzenie sie by lepiej działało (i by się obracał względem środka, a nie nóg). No i cień by był w dobrym miejscu (tylko na leżąco powinien się powiększać).

ja robię tablice

No ej, http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/drawing 3d/3d transformations/index.html owszem, mniej niż w http://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/matrices/index.html ale jednak

Generalnie, można by zajebiste gry z tego zrobić. Chyba nie widziałem takiego birds-view z pełnym obracaniem jeszcze. Kurde, jakbym coś takiego do mojego tech-dema gry farmerskiej dodał, ciekawe jakby wyszło... takie Stardew Valley, ale można się obracać we wszystkie strony... i ciekawe czy na zwierzętach też by się dało taki efekt uzyskać, bo generalnie wygląda, że lepiej wyjdzie to na wysokich a wąskich obiektach.

No stringa się wysyła tak jak inta, tylko wysyłasz stringa Serwer-klient też tam jest z tego co widzę, bo w końcu to przykład gry online. Przykładu krok po kroku nie dostaniesz, bo takowe na marketplace są, trzeba je tylko pobrać i wypróbować.

a nie możesz na application surface w post draw zrobić ? (i wyłączyć automatyczne rysowanie application surface).

Jak przypisujesz surface do view, to w ogóle nie powinno kolidować z GUI. Chyba, że robisz to w evencie draw gui, to robisz to wtedy źle, bo GUI jest niezależne od view jeśli dobrze kojarzę. Może tutaj jest problem.

Na pewno robisz dobrze shader_set i shader_reset ? no i pytanie jakie mają depth te oba obiekty (przypominam, że nawet jak wszystkie mają 0, to draw gui rysuje się dopiero po wszystkich normalnych draw).