Dawidds

Nie zoptymalizujesz tego, room_speed jest ustawiony na 90 (swoją drogą lepiej ustawić to na 60, monitory niezbyt często mają tempo odświeżania ekranu większe niż 60 (60MHz)) to znaczy, że 90 razy na sekundę okno gry jest rysowane od nowa - i nie działa to tak, że odrysowywane jest tylko to, co się zmieni - po prostu 90 razy na sekundę cały ekran gry jest rysowany jeszcze raz. I nic nie "zostaje" na ekranie - wszystko, tzn. tło, tilesy, wszystkie obiekty, punkty (wszystkie eventy draw) rysują się od nowa.

0-255 = 8 bitów, 0-127 = 7 bitów. 14 bitów ewidentnie nie zmieści się w ośmiu : p Zmieścisz dwie wartości 0-15, i zapis: liczba = (a << 4) + b; Odczyt: a = liczba >> 4; b = liczba mod 16;

collision_line nie zwraca ani true ani false, zwraca id pierwszej napotkanej instancji lub noone (-4). Użyj samego "if collision_line()", nie dodawaj żadnego "= true" na siłę, bo poza takimi błędami nic Ci to nie da ; )

Jak trigger?

Pewnie się jakoś da ale zawsze możesz nie obciążać exe tymi czterystoma grafikami i wczytywać je z plików

No to normalnie collision line, x1y1 to pozycja gracza, x2y2 to origin dachu, i sprawdzasz kolizje ze ścianami domku czy co tam chcesz.

Poszukaj wzoru na siłę grawitacji i GML motion_add(point_direction(x, y, planeta.x, planeta.y), moc);

1. Pierdzielisz particle i robisz to na obiektach - wtedy sobie dasz radę i będzie bardzo dokładnie 2. Dajesz obiektowi emitera jakąś okrągłą maskę i wtedy każdemu obiektowi możesz dać event "Collision with o_dym_emitter" 3. W każdym obiekcie sprawdzasz dystans do obiektu emitera (albo obiektów) i jeśli jest mniejszy niż x to ktoś jest zakażony Spróbuj sobie wersji 2., jeśli uznasz że jest za mało precyzyjna odwzoruj sobie particle na obiektach i będziesz miał normalne kolizje. Threef, co to za magiczne odwołanie "i.x, i.y"? : D

https://gmclan.org/index.php?sciagnijplik=182

Tutaj podam drugi pomysł na rozmycie w gmie - wykorzystanie interpolacji przy rysowaniu. Rysujemy surface (z włączoną interpolacją) na dwa razy mniejszy surface, po czym przywracamy go do pierwotnego rozmiaru (powiększamy dwa razy). Później znowu zmniejszamy, znowu powiększamy itd. Można tutaj stosować różne kombinacje skali surfaców (zmniejszyć go dwa razy, potem zwiększyć dwa, zmniejszyć cztery, zwiększyć cztery itd.) i kombinować z nimi w celu uzyskania najlepszego stosunku jakośći do fpsu. Jakiś sample który dla kogośtam robiłem kiedyś, w sumie sam nie pamiętam kogo: http://dl.dropbox.com/u/25762547/blur.gmk Fps tej techniki może nie powala (choć można to jeszcze zoptymalizować) ale jakość rozmycia jest myślę znacząco lepsza niż wersji z półprzezroczystymi surface'ami. Istnieje:GML draw_set_blend_mode_ext(bm_zero, bm_inv_src_color); draw_sprite(sprite, 0, 0, 0); draw_set_blend_mode(bm_normal); Rysujemy to oczywiście na surfacie (surface_set_target()). Maska "sprite" powinna być cała czarna i wtedy jej kanał alpha zostanie przeniesiony na surfejsa (tam gdzie sprite jest przezroczysty na x% tam surface będzie przezroczysty na x%). W sumie pisze te blendy z pamięci ale chyba się nie pomyliłem : p

Niech sobie ta latarka trzyma tego surfejsa nawet w roomach w których go nie używasz (będzie jeden obiekt, z persistent, tak jak teraz masz), i wtedy tylko cały step i draw rozpoczynasz kodem GML if(global.latarka) { I zostaw w Game End to surface_free(). Będzie się bugować, bo obiekty w innych roomach i tak by się tworzyły, tyle, że te następne by nie miały stworzonego surfejsa (game start) a próbowały z nich korzystać (step/draw)

Tworzy Ci się pare obiektów od światła, zadbaj o to żeby był jeden na mapie (ustaw persistent temu na pierwszej mapie z następnych wywal te obiekty albo odznacz persistent i zostaw obiekt od światła na każdej mapie).

I w jaki sposób surface'y pomogły Ci uzyskać ten efekt ^^ ? Rysuj primitivami i będziesz miał broblem z głowy i nawet wydajniejsze rysowanie, chociaż w sumie nie wiem co Ty wykombinowałeś dokładnie z tymi surfami.

Może zacznijmy od tego po co rysujesz liny za pomocą surfaceów, tym bardziej że sam stwierdziłeś, że "wiele surface'ów musi być odmalowywane w każdym stepie".

W ogóle oświeć mnie po kiego grzyba rysować wygenerowaną mapkę jako grafikę tylko po to żeby potem znowu czytać z niej kolory? : / Taka tam konwersja [wartość] -> [kolor] -> [wartość], coby przypadkiem wszystko nie chodziło za szybko i żeby mieć pretekst do użycia draw_getpixel() bo to ogólnie bardzo fajna funkcja. Normalnie liczysz sobie tą heightmape niech bedzie perlin noisem do tablicy i tyle, po co rysować to na ekran i znowu czytać z tego ekranu, chyba tylko po to żeby stracić fps i trochę na precyzji.

Nie, chodziło mu o to że brama (to nad tymi kratami) nie ma żadnej faktury tylko gładki kolor.

Rób aa, ale nie dla konkretnego koloru tylko na kanale alpha. Żeby Ci się strasznie sposób tworzenia nie różnił to zrób sobie warstwę tła z trawą i ludzika rysuj na położonej wyżej przezroczystej warstwie - i wtedy rysując ludzika zmieniasz krycie ołówka aby zrobić aa. Zasada tworzenia w sumie podobna to sobie jakoś poradzisz, i ludizk będzie pasować niezależnie czy postawisz go na trawie, kostce czy na dachu epickiego drewnianego domku ;)

Tak, jest.

Musisz sam napisać. A jak już sobie napiszesz system scen nie powinieneś mieć problemu z menu :)

Kumpel ma zielony 10mw i taki też bym Ci polecił, w nocy widać wiązkę (w dzień niestety nie, chyba że zadymione/ciemne pomieszczenie, na zewnątrz nie masz szans w dzień promienia zobaczyć) a jednocześnie niczego nie podpali i nawet jak komuś pierdzielniesz niechcąco "lekko" w oko to żadnej trwałej usterki na wzroku nie powinien doznać.

Ogólnie to założyliście temat i sami sobie w nim rozmawiacie, fajnie to wygląda : D Powiedzcie jeszcze w czym to ma być lepsze od gmc, bo jak dla mnie to jest mniej wygodne, trzeba to ściągnąć, będzie tam mniej przykładów, będą one gorzej opisane niż na forum i nie będzie pod nimi raczej żadnej sensownej dyskusji. I jest brzydkie. Listbox jako lista przykładów? No proszę : /

Jeśli masz win7 to download i upload procesu możesz sprawdzić w menadżerze zasobów, zobaczyć porty w sumie możesz w firewallu jak się pyta czy zezwalasz na połączenie procesu z netem.

GML //Przygotowuje stuelementowa tablice i liste wypelniona jakims niczym lista = ds_list_create(); repeat(100) { ds_list_add(lista, 1234); } for(i=0; i<100; i+=1) { tablica = 1234; } //Czas odczytu czegos z listy _time = current_time; repeat(200000) { a = ds_list_find_value(lista, 50); } CzasOdczytLista = current_time - _time; //Czas odczytu z tablicy _time = current_time; repeat(200000) { a = tablica[50]; } CzasOdczytTablica = current_time - _time; //Czas zapisu do listy (zastapienia wartosaci elementu, aby dzialalo analogicznie do tablicy) _time = current_time; repeat(200000) { ds_list_replace(lista, 50, 4321); } CzasZapisLista = current_time - _time; //Czas zapisu do tablicy _time = current_time; repeat(200000) { tablica[50] = 4321; } CzasZapisTablica = current_time - _time; //Wyniki show_message("Odczyt z listy: " + string(CzasOdczytLista) + "#Odczyt z tablicy: " + string(CzasOdczytTablica) + "##Zapis do listy: " + string(CzasZapisLista) + "#Zapis do tablicy: " + string(CzasZapisTablica)); Wstaw to sobie w jakieś create i odpal. Wyniki u mnie to ~dwukrotna przewaga czasowa na korzyść, niespodzianka, tablic. Nie, nie wiem. Skoro taki "ficzer" JUŻ JEST, i używanie go jest WYGODNIEJSZE (krótsze) i jednocześnie SZYBSZE (bo "już jest", ale jak chcesz to przeprowadź test ;)) niż pisanie tego samemu to po kiego grzyba tego nie robić. I nie przyrównuj gma do innych języków bo to się zwykle źle kończy.

Hmm. Tutaj nie wiem na podstawie czego tak twierdzisz. Wolisz obracać sprite wrzucając w to pisane z ręki obliczenia niż po prostu ustawiając origin tam, gdzie ma się on obracać? Dla gma to żadna róznica, czy narysujesz sprite z originem na 0,0 czy gdzieś indziej ("żadna", nie "mała"). A dla Ciebie to troszkę bardziej długi kod rysowania grafiki i malutka strata na wydajności (malutka bo malutka ale jest - sam stwierdziłeś że lepiej użyć tego co jest wbudowane w gma niż robić to samemu). I jeśli chodzi o wygodę używania tego to też lepiej będzie mieć origin tam, gdzie obiekt ma wyobrażony przez nas "środek" - wtedy np. licząc dystans do tego obiektu użyję sobie x,y a nie x+ileś,y+ileś Akurat głupie porównanie bo lista to po prostu co innego niż tablica (mimo że technicznie listy w gmie są niby tablicami). I są szybsze w sensie że gdybyś chciał sam zaimplementować listy na tablicach (usuwanie dowolnego elementu "przesuwając" resztę, sortowanie itd.) to Twoja implementacja by była wolniejsza niż gmowe listy. ALE, same tablice są szybsze niż listy (zapis/odczyt). Tylko że mówię, to porównywanie tablic do list jest głupie. Jak chcę mieć kolekcję która reprezentuje bardziej pewną grupę danych, z której później będę mógł sobie dowolnie usuwać i dodawać elementy (będzie miała zmienny rozmiar) to użyję listy. Jak ma to być kolekcja o stałym rozmiarze, gdzie do każdego indeksu (jakieśtam cyfry) powiążę wartość to użyję tablicy. Tylko że jeśli używasz list w sytuacjach w których normalnie byś użył tablic bo myślisz że tak będzie wydajniej to się mylisz, o. Z ciekawości - jakie konkretnie gmowe funkcje masz na myśli ;p ?

A właściwie to co ma kompas do akcelerometru?