xxx

[Gość]

xxx

[Threef]

Tak, zrób globalną zmienną (global.pauza) i ustawiaj ją na 1 gdy jest okienko. A w każdym innym obiekcie wykonuj jego akcje tylko gdy global.pauza=0.

[Gość]

xxx

[Roki]

Na twoim miejscu zrobiłbym tablicę zawierającą nazwy samochodów, ceny itd. ( nie wiem do czego to ma być ) i potem pętlą for rysowałbym przyciski. Podobnie sprawdzałbym czy myszka jest nad nimi ;)

 

( Czyli opcja druga, "półobiekty" )

[MaxGaming]

Ale mniej problematyczne i optymalniejsze (chyba) będzie walnąć sprite_add_from_screen, dać w room persist, przerzucić do jakiegoś pustego roomu(ew. stworzyć taki, ale chyba optymalniej będzie raz stworzyć niż usuwać i tworzyć za jednym razem) rysować tam tego sprite jako tło, ew. zmodyfikować sprite(np: przyciemnić) dla fajniejszego efektu i potem wracać do tego romu z persist(możesz teraz persist usunąć) ;)

[Threef]

Grę piszę chyba głównie na androida, dlatego zależy mi na wydajności, a nie wiem co będzie gorsze na andka, obsługa 9 obiektów, czy narysowanie 9 "półobiektów"..

W Studio nie będzie różnicy (O ile nie zrobisz jakiś głupot).

A stworzenie 9 obiektów (1 rodzic i 9 dzieci) będzie łatwiejsze i szybsze, ale może potem będziesz musiał coś zmienić, a wtedy nie będzie już fajnie.

 

Ale mniej problematyczne i optymalniejsze (chyba) będzie walnąć sprite_add_from_screen, dać w room persist, przerzucić do jakiegoś pustego roomu(ew. stworzyć taki, ale chyba optymalniej będzie raz stworzyć niż usuwać i tworzyć za jednym razem) rysować tam tego sprite jako tło, ew. zmodyfikować sprite(np: przyciemnić) dla fajniejszego efektu i potem wracać do tego romu z persist ;)

Stworzony tak sprite (o ogromym rozmiarze) będzie przechowywany cały czas w pamięci. To bardzo zły i nie optymalny sposób.

[Gość]

xxx

[Roki]

Nie mam GM'a, ale nie ma czasem czegoś jak draw_set_depth? Btw. wydaje mi się że zmiana depth obiektu powinna pomóc tak czy siak xD

Jeszcze jedno co mi wpadło, jak używasz draw wdanym obiekcie to musisz w nim manualnie sprite rysować:

GML

draw_sprite(sprite_index, 0, x, y);

Jakoś tak ;)

[gnysek]

A w jakim evencie rysujesz ? I czy visible jest zaznaczone?

[Gość]

xxx

[gnysek]

Jak rysujesz w gui to i tak będzie zawsze na wierzchu - GUI to layer nad zwykłym DRAW i więc depth liczy się od nowa

[MaxGaming]

Stworzony tak sprite (o ogromnym rozmiarze) będzie przechowywany cały czas w pamięci. To bardzo zły i nie optymalny sposób.// Mała literówka każdemu się zdarza, ale tylko zaznaczam, żebyś poprawił o ile masz taką potrzebę :)

Nie rozumiem dlaczego. I tak musisz od groma tak to spritów, ale mniejszych rysować, przy czym oprócz tego, że jest ich dzieiątki (czasami setki) razy mniej to w sumie ile taki obraz zajmie? 2MB ramu? Przy dzisiejszych komputerach to jednorazowa wykorzystać 2 mb można, to mniej obciąża procesor, a jedynie w niewielki stopniu odciąża ram ;) Więc o co chodzi?

[Threef]

Nie rozumiem dlaczego. I tak musisz od groma tak to spritów, ale mniejszych rysować, przy czym oprócz tego, że jest ich dzieiątki (czasami setki) razy mniej to w sumie ile taki obraz zajmie? 2MB ramu? Przy dzisiejszych komputerach to jednorazowa wykorzystać 2 mb można, to mniej obciąża procesor, a jedynie w niewielki stopniu odciąża ram ;) Więc o co chodzi?

Grę piszę chyba głównie na androida, dlatego zależy mi na wydajności

Nuff said.

[Gość]

xxx

[MaxGaming]

Nuff said.

W moim staryym fonie(miał standardowo miał android 1.6 tylko zmieniłem na 2.3.7) jest procek 600mhz, a ramu 512mb, więc mi zależało by bardziej na procku, bo ramu i tak tyle będzie problem wykorzystać. Wydaję mi się, że w nowszych telefonach jest podobnie. Nie rozumiem, stracić 2 mb ramu na rzecz kilkuset operacji na klatkę mnie(wszystkie obiekty, etc.) i nie mieć problemów m.in.: z alarmami to zły układ? A zresztą ile obrazki zajmują ekranu? 80%? 100% zajmie 2 mb, a 80% 1,6mb ;)