Amaterasu

@Exigo: Mi mapę 100x100 z bitmapy wczytało w ~1.3s, więc nie jest to najszybsza metoda.

Metro 2014

Zależy, co chce zrobić: 1. ma poruszać się tylko, gdy kliknięty jest RMB: GML //Event Step if(mouse_check_button(mb_right)&&targeted) { xx=mouse_x; yy=mouse_y; if(distance_to_point(xx,yy)>32) mp_potential_step(xx,yy,v,false); } 2. kliknięcie ma tylko wybierać cel, do którego obiekt ma się dostać, sam obiekt ma cały czas się poruszać, dopóki nie dotrze do celu: GML //Global RMB button released if targeted { xx=mouse_x; yy=mouse_y; } GML //Event Step if(distance_to_point(xx,yy)>32) mp_potential_step(xx,yy,v,false)

Pozbądź się while i wstaw to do eventu Step.

Rozmiar save'a nie jest problemem (np. w Spellforce save'y ważą po kilka MB), ale lepiej go zaszyfrujcie albo coś, bo to żadna frajda podmienić sobie parę linijek w save i przejść całą grę na godmode.

Gdzie jest Korodzik, kiedy go potrzebujemy : (

Tak bardzo chcę, żeby mógł swoim mieczem przywoływać słupy ognia

Napis powinien wyglądać mniej więcej w tym stylu: GML str = string(miejsce)+f_miejsce(miejsce)+' '+nazwa+' '+string(punkty)+' pnk' draw_text(xx,yy,str) Funkcja f_miejsce wybierze, czy po numerze miejsca powinno pisac 'st', 'nd', 'rd', czy 'th': GML switch argument0 { case 1: return 'st' case 2: return 'nd' case 3: return 'rd' default: return 'th' }

Ja bym posłuchał z chęcią Antego i spółkę

Poczytaj w dokumentacji o string_format(val,tot,dec)

Jestem pod wrazeniem, jak mocny musi byc twoj komputer. Twoj drugi kod tworzy wszystkie bloki naraz. A raczej tworzylby, gdybys w polowie kodu nie zapomnial usuwac ifa z Ctrl-C - Ctrl-V. W sumie ten drugi kod jest bez sensu, skoro pierwszy w zamierzeniu robi dokladnie to samo.

Wystarczy przejrzeć dokumentację, aby dostrzec, iż jest możliwa wymiana danych między aplikacją a serwerem.

+

Ach, czyli nie ma to być jakaś super realistyczna symulacja wody, ale oparta na blokach. W takim przypadku poczytaj sobie o automatach komórkowych, a następnie zbuduj taki, który kontroluje ruch wody w twojej grze. Z matematycznego punktu widzenia jest to dosyć proste, natomiast aby to rozwiązanie działało w czasie rzeczywistym, trzeba pomyśleć nad strukturą wody w grze (np. częstotliwość symulacji, zachowanie i przeznaczenie obiektów-woda znajdujących się w grze i na ekranie).

Zależy, ile tej wody ma być. Jeżeli chcesz mieć jakieś morze, to lepiej po prostu zrobić wszystko jako efekt graficzny, a jeśli chcesz móc przelewać wodę z miejsca na miejsce, wtedy tej wody nie może być zbyt dużo, bo komputer ci się stopi. Najważniejsza sprawa: ta twoja gra, ma być 2D platformówką, top-down, izometryczna czy 3D?

1. Stwórz listę, w której będziesz przechowywał indeksy załadowanych grafik 2. Stwórz strukturę danych, w której będziesz przechowywał dane nt. kości (czyli ID obiektu-kości, ID parenta kości) oraz zapisz w każym obiekcie-kości dane nt. jej graficznej reprezentacji (np. sprite kości, długość kości, kierunek, w którym kość jest skierowana) 3. Stwórz zestaw funkcji, które pozwolą ci na edycję danych nt. kości w trybie graficznym (przeciąganie kości, zmiana jej rozmiaru, dodawanie/usuwanie kości) 4. Stwórz key editor, czyli obiekt, który pozwoli ci na zapisywanie i edycję informacji nt. animacji kości (m. in. ilość klatek animacji, zapis matematyczny każdej kości w każdej klatce, typy interpolacji dla każdej kości) 5. Stwórz możliwość zapisania animacji w takim formacie, aby mogła z niej korzystać twoja gra w czasie rzeczywistym I tyle, jeśli chodzi o najważniejsze elementy : ) draw_sprite przyjmuje za argumenty pozycje X i Y, to, w jaki sposób modyfikujesz te pozycje zależy tylko od ciebie. Czyli, interpolacja działa.

Jak jesteś hardkorem, to możesz nawet w Notatniku Jakbym ja miał robić animacje szkieletowe, to albo napisałbym sobie własny edytor, albo skorzystał z Blendera i ignorował jeden z wymiarów.

Właśnie sprawdziłem, działa dla każdego rooma.

Funkcja window_set_size zmienia rozmiar okna aplikacji, view_wview i view_hview zmieniają rozmiar widoku gry. Nie da się zmienić rozdzielczości ekranu, o ile dobrze rozumiem.

kriso99, nie wiem, czy na pewno w tym kodzie powinno być image_yscale

Poprawiłem czytelność kodu, nie zmieniłem w nim żadnej funkcjonalności: GML switch other.sprite_index { case spr_lrocket1: { x = other.x+12; y = other.y+12 if vspeed = 5 {vspeed = 0; hspeed = 5} else if hspeed = -5 {hspeed = 0 vspeed = -5} else if(vspeed = -5)||(hspeed = 5) {instance_destroy()} break } case spr_lrocket2: { x = other.x+12; y = other.y+12 if vspeed = -5 {vspeed = 0; hspeed = 5} else if hspeed = -5 {hspeed = 0 vspeed = 5} else if(vspeed = 5)||(hspeed = 5) {instance_destroy()} break } case spr_lrocket3: { x = other.x+12; y = other.y+12 if vspeed = -5 {vspeed = 0; hspeed = -5} else if hspeed = 5 {hspeed = 0 vspeed = -5} else if(vspeed = 5)||(hspeed = -5) {instance_destroy()} break } case spr_lrocket4: { x = other.x+12; y = other.y+12 if vspeed = 5 {vspeed = 0; hspeed = 5} else if hspeed = 5 {hspeed = 0 vspeed = 5} else if(vspeed = -5)||(hspeed = -5) {instance_destroy()} break } default: break } Wiele rzeczy w twoim kodzie powtarza się niepotrzebnie. Zerknij na funkcję dot_product i zastanów się, w jaki sposób pomoże ci załatwić ten problem w jednej-dwóch linijkach.

GML d3d_light_define_ambient(c_white) //rysuj bez świateł d3d_light_define_ambient(c_black) //rysuj ze światłem</span> Nie obiecuję, że będzie działać, nie sprawdzałem.

Zmiene view_xview i view_yview odpowiadają za położenie viewu w roomie (więcej w dokumentacji) - jest to pozycja lewego górnego rogu ekranu w roomie.

To jest brzydkie rozwiązanie, bo zostawia śmieci w danych projektu, których nie da się usunąć (np. jeśli usuniesz sprite o indeksie 0, nie zmieni to indeksów kolejnych sprite'ów, a żaden nowy nie będzie miał takiego indeksu).

-Budynek i drzewo porażają swoją kanciastością. Nawet w GM-ie można rysować modele, które nie są prostopadłościanami. -Brak rozdzielenia na światło i cień powodują, że powstają jednolite plamy barwne, które wyglądają paskudnie -Nie istnieją kontury obiektów, co sprawia wrażenie patrzenia na płaski rysunek -Brak tekstur lub niska ich jakość dopełniają dzieła zniszczenia -Brak antyaliasingu powoduje powstawanie "ząbków" na krawędziach obiektów, a na teksturach widoczne są prążki moiré (nie chce mi dodać linku z polskimi znakami, ale można wyszukać na wikipedii) To tak z grubsza, nie poruszyłem sprawy odwzorowania budynku na podstawie danych historycznych, kompozycji barwnej, czy kształtu drzewa (które nie powinno być kuliste).