funkcja znajdujaca pozycje sprita

[gol350]

jak najprosciej znalezc pozycje sprita podczas gry , kiedy to obiekty beda sie przemieszczaly po calym roomie. myslalem o tablicach gdzie beda zapisane wspolrzedne spritow ,ale nie wiem jak to zastosowac w praktyce tzn. nie wiem jak z tej tablicy odczytac te dane ,zeby ulozyc jakis warunek ,ktory by stwierdzal ,ze na pozycji pierwszej jest sprite_red , a na pozycji drugiej sprite_black. moze istnieje jakas funkcja do tego.

 

bede wdzieczny za odpowiedz ,niekoniecznie szybka.

[ediepl]

Jak zmieniasz pozycje spritów?

[Piedro]

jak najprosciej znalezc pozycje sprita podczas gry , kiedy to obiekty beda sie przemieszczaly po calym roomie. myslalem o tablicach gdzie beda zapisane wspolrzedne spritow ,ale nie wiem jak to zastosowac w praktyce tzn. nie wiem jak z tej tablicy odczytac te dane ,zeby ulozyc jakis warunek ,ktory by stwierdzal ,ze na pozycji pierwszej jest sprite_red , a na pozycji drugiej sprite_black. moze istnieje jakas funkcja do tego.

 

bede wdzieczny za odpowiedz ,niekoniecznie szybka.

pozycja spritów jest zawsze taka jak pozycja obiektu który ma go przypisanego

orgin sprita decydoje gdzie sprit ma środek

[ediepl]

YYY nie zawsze, gdy rysujesz sprite np draw_spirte(sprite,-1,30,13) to wtedy pozycja jest 30,13 a nie x,y obiekty.

[gol350]

Jak zmieniasz pozycje spritów?

za pomoca klikniec myszka . tzn. jak naciskam na sprite_red to on zmienia kolor na sprite_black. no i wszystkie sprity w tym samym rzedzie zmieniaja kolor na odwrotny. jak maja czarny to zmieniaja sie na czerwony i na odwrot.

[gol350]

pozycja spritów jest zawsze taka jak pozycja obiektu który ma go przypisanego

orgin sprita decydoje gdzie sprit ma środek

origin sprita mam ustawiony na x = 0 i y = 0 .

 

wracajac do postu ediepl.

czyli ,ze jak ustawie origin na x = 0 i y = 0 to pozycja sprita jest taka sama jak pozycja obiektu.

czy dobrze rozumiem , a moze nie.

 

sorry za double post. pojechalo mi sie.

[Madness]

Używamy opcji Edytuj

Nawet nie przeprosiłeś za double posta

[ediepl]

orgin to jest takie przesunięcie sprite np: jeśli ustawie orgin x i y na 10,5 to gdy napiszę draw_sprite(sprite0,-1,70,30) to lewy górny róg(pierwszy piksel) będzie znajdować się na pozycji 60,25.

[gol350]

orgin to jest takie przesunięcie sprite np: jeśli ustawie orgin x i y na 10,5 to gdy napiszę draw_sprite(sprite0,-1,70,30) to lewy górny róg(pierwszy piksel) będzie znajdować się na pozycji 60,25.

 

no dobrze , ale jak to origin wykorzystac ?

[Sernat]

Chłopie! Do czego masz to wykorzystać? Istnieją dwie zmienne: x i y. Określają położenie sprite'a. Nieważne już w którym miejscu. Określają i tyle. Originów w ogóle nie ruszaj i ustawiaj na zero, taka moja rada. Wówczas wystarczy mieć id obiektu, by określić jego współrzędne:

GML

wsp_x = obiekt.x;

wsp_y = obiekt.y;

Jest wiele sposobów na uzyskanie id, np. w czasie tworzenia instancji:

GML

obiekt = instance_create( lalala... );

[Rudy]

Originy to bardzo przydatna rzecz. Dzięki originom można poprawnie użyć image_angle obracając postać. Łatwiej o sprawdzenie pozycji przy wszelkich kolizjach i obiektach, zwłaszcza okrągłych. Świetnie się prezentują przy wyglądzie wszelkich obiektów (jedynie kwadratowym ujdzie jakoś)

1. Masz okrągłe przyciski?

a ) originy na środek

b ) sprawdzaj odległość myszki od pozycji

2. Kwadratowe?

a ) originy na środek

b ) sprawdź czy myszka jest w zakresie x, y

3. Romb?

a ) originy na środek

b ) sprawdzaj czy liczba abs(x-mouse_x)+abs(y-mouse_y)*k (gdzie k to pozioma przekątna/pionowa) nie przekracza połowy poziomej przekątnej

 

Inny? napisz :P

[Sernat]

To kontrargumenty, tak na szybko:

Originy to bardzo przydatna rzecz.

Przy większych projektach: kłopotliwa.

Dzięki originom można poprawnie użyć image_angle obracając postać.

Sinus & cosinus, ewentualnie lengthdir, bo może nawet szybsze.

Łatwiej o sprawdzenie pozycji przy wszelkich kolizjach i obiektach, zwłaszcza okrągłych.

Nie rozumiem :) .

Świetnie się prezentują przy wyglądzie wszelkich obiektów (jedynie kwadratowym ujdzie jakoś)

Co to ma do wyglądu? Jeżeli to co myślę - patrz punkt pierwszy.

 

Inny? napisz

Innych przykładów jest pełno, ale po co obciążać komputer suchymi obliczeniami, jak można skorzystać z gotowych kolizji? Instance_free, instance_empty oraz instance_place.

[Rudy]

Przy większych projektach: kłopotliwa.

Zależy w sumie w jaki sposób ich użyć ;)

 

Sinus & cosinus, ewentualnie lengthdir, bo może nawet szybsze.

Właściwie lengthdir = sin/cos tylko z pomnożeniem przez długość i łatwiejszą nazwą ;) .

Ale ustawisz origin i żadnych poprawek nie musisz robić ;)

 

Nie rozumiem :) .

Przykładowo, masz dwie koła o rożnych promieniach, chcesz wykonać odbicie sprężyste niecentralne. Jeżeli nie masz ustawionych originów, musisz tworzyć dodatkowe zmienne żeby przesunąć pozycję na środek kuli.

 

Co to ma do wyglądu? Jeżeli to co myślę - patrz punkt pierwszy.

Przesuwają obrazek o origin :) . Wtedy np jeżeli chcesz odbicie lustrzane robisz po prostu image_yscale = -1; Jeśli origin będzie na górze, to będzie na dole i to już nie to samo :) . Ale jeśli na środku to będzie środek i tak :) .

 

Innych przykładów jest pełno, ale po co obciążać komputer suchymi obliczeniami, jak można skorzystać z gotowych kolizji? Instance_free, instance_empty oraz instance_place.

Suche obliczenia to to, co komputer lubi najbardziej :) . Funkcje to też obliczenia, ale jest ich więcej i niektóre nie są potrzebne (mam na myśli to, że tworząc własne obliczenia możesz dokonywać optymalizacji).

 

Ale faktycznie, można również użyć tych funkcji, efekt będzie taki sam :)

[ediepl]

@Sernat:Instance_free, instance_empty-chyba place_free i place_empy.Co do reszty to masz rację, ale nie zgodzę się z tym że origin jest kłopotliwy, na pewno mniej niż

Sinus & cosinus

[Sernat]

@Sernat:Instance_free, instance_empty-chyba place_free i place_empy.Co do reszty to masz rację, ale nie zgodzę się z tym że origin jest kłopotliwy, na pewno mniej niż

Hehe, fakt, dopiero przeczytałem co napisałem ;) . Bywa kłopotliwy, przede wszystkim jego odczyt i zmiana w czasie projektu. A sinus i cosinus to żaden kłopot.

Właściwie lengthdir = sin/cos tylko z pomnożeniem przez długość i łatwiejszą nazwą ;) .

Ale ustawisz origin i żadnych poprawek nie musisz robić ;)

Nie zaprzeczyłem i nie zaprzeczam :) .

Przykładowo, masz dwie koła o rożnych promieniach, chcesz wykonać odbicie sprężyste niecentralne. Jeżeli nie masz ustawionych originów, musisz tworzyć dodatkowe zmienne żeby przesunąć pozycję na środek kuli.

Widzisz, mówiąc o "problemie" mam na myśli sytuacje niekontrolowane, bo dopisanie nawet kilku linijek kodu jest niczym przy szukaniu błędu i naprawianiu go.

Suche obliczenia to to, co komputer lubi najbardziej :) . Funkcje to też obliczenia, ale jest ich więcej i niektóre nie są potrzebne (mam na myśli to, że tworząc własne obliczenia możesz dokonywać optymalizacji).

To znaczy ja staram się nigdy nie odbiegać od funkcji danych przez GMa, zwłaszcza, że w wielu wypadkach domyślne funkcje są szybsze niż własne metody, np. listy > tablice, siatki > tablice dwuwymiarowe itd.

[Rudy]

Widzisz, mówiąc o "problemie" mam na myśli sytuacje niekontrolowane, bo dopisanie nawet kilku linijek kodu jest niczym przy szukaniu błędu i naprawianiu go.

Błędy pojawiają się tylko, jeżeli programista o czymś zapomni/nie zna się na używanym kodzie. Można więc powiedzieć, że u ciebie jest więcej błędów jeżeli chcesz dojść do porozumienia z originami, u mnie z kolei jeżeli próbuję się obyć bez nich :).

 

To znaczy ja staram się nigdy nie odbiegać od funkcji danych przez GMa, zwłaszcza, że w wielu wypadkach domyślne funkcje są szybsze niż własne metody, np. listy > tablice, siatki > tablice dwuwymiarowe itd.

Możliwe, chociaż zależy od tego, czym są te listy w rzeczywistości. Może to są "obudowane" tablice, a może jakieś coś szybszego :)

 

W ogóle o co się kłócimy :D . Każdy ma swój styl i swoje narzędzia pracy :) .

[Sernat]

Możliwe, chociaż zależy od tego, czym są te listy w rzeczywistości. Może to są "obudowane" tablice, a może jakieś coś szybszego

Tutaj akurat odniosłem się do dokumentacji i tego, co stwierdził Mark Overmars ;) .

[Dawidds]

Hmm.

Sinus & cosinus, ewentualnie lengthdir, bo może nawet szybsze [niż origin].

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ś

 

zwłaszcza, że w wielu wypadkach domyślne funkcje są szybsze niż własne metody, np. listy > tablice, siatki > tablice dwuwymiarowe itd.

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.

 

Funkcje to też obliczenia, ale jest ich więcej i niektóre nie są potrzebne (mam na myśli to, że tworząc własne obliczenia możesz dokonywać optymalizacji).

Z ciekawości - jakie konkretnie gmowe funkcje masz na myśli ;p ?

[Sernat]

Dawidds, piękny wykład niepoparty jakimkolwiek testem wydajności ;) .

 

Spróbuj sam dokonać jakiegoś z listami i tablicami. Ja się po prostu powołałem na logikę i Marka Overmarsa, ty jakbyś napisał sobie od tak ;) .

 

A apropos sinusów i cosinusów nie mam zamiaru się kłócić. Programuję wiele lat w JS z Jquery, ostatnio korzystam z apletów Javy. Nigdy w żadnym silniku graficznym nie widziałem implementacji czegoś takiego jak "origin". Wiesz, do czego zmierzam ;) ? Widziałem natomiast odpowiedniki list i oczywiście, w obydwu językach, tablice dynamiczne. Wydajności nie ma co porównywać, ponieważ listy są BARDZIEJ ograniczone niż tablice, rozumiesz ;) ?

 

Funkcjonalność list jest ograniczoną funkcjonalnością tablic. W dodatku GM do odczytu wartości i ich edycji w listach może wykorzystywać funkcje inline. A te, jak wiadomo, są predefiniowane przez preprocesor i nie odbijają się negatywnie na wydajności programu.

[Dawidds]

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.

 

Wiesz, do czego zmierzam ?

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.

[Rudy]

Nigdy w żadnym silniku graficznym nie widziałem implementacji czegoś takiego jak "origin".

Ja widziałem :P . HGE -> Link

 

Listy a tablice to jednak co innego, ośmielam się stwierdzić, że ich działanie w GML podobne jest do działania w C++, tzn tablice to proste przesunięcie wskaźnika, a listy to przeskakiwanie co wskaźnik do kolejnego elementu. W drugim znajduje się pętla, w pierwszym nie ;) .

 

Z ciekawości - jakie konkretnie gmowe funkcje masz na myśli ;p ?

Ogólnie tak, np point_direction. Strzelam, chociaż pewny nie jestem, że może korzystać on z tangensa. Czyli pewnie przed samym obliczeniem robi sobie test warunkowy, żeby uniknąć crasha. A załóżmy, że z gra jest tak zbudowana, że na 100 procent możemy założyć, że ten warunek zawsze będzie prawdziwy. Czyli mamy o jedną instrukcję mniej :) . (i około 5 komend asma ;D )

[Sernat]

Dawidds, gz, zadeklarowałeś listy i tablice.

 

Jak tylko dorwę GMa przeprowadzę szersze badania.