TO_mek

Witam! Jak uzyskać coś takiego: mam ekran 800x600, gra platformowa, przeciwnik idzie z lewej do prawej, gdy dochodzi do punktu x=700 to ma zaczynać "znikać" a to co zniknie ma się pojawiać w punkcie x=100 z zachowaniem alphy, animacji. Czyli dla x>700 ma istnieć niewidzialna ściana za którą ma wchodzić przeciwnik i w tym samym czasie ma się on zacząć wyłaniać zza niewidocznej ściany kończącej się w punkcie x>100. Coś jakby scena teatru gdzie ta sama postać wychodzi z prawej strony i zaraz pojawia się z lewej strony. Najlepiej żeby nie stosować obiektów zasłaniających za które wchodziłby obiekt i zza których by się pojawiał. Kombinowałem z draw_sprite_part() ale to raczej nie działa przy automatycznym rysowaniu animacji obiektu i nie mam pomysłu jak to zrobić.

Z tym że ten kod wyklucza tylko ostatnią akcję. Dla wykonania wszystkich przykładowych 5-ciu akcji bez powtórzeń lepiej to wpakować do tablicy lub ds_list. Wygodniej będzie użyć ds_list bo łatwiej sprawdzać czy istnieje w tablicy wylosowana wartość (ds_list_find_index(id,val) Find the position storing the indicated value. If the value is not in the list -1 is returned).

No tak ale warunkiem jest to, że musiałbym także obsługiwać rysowanie sprajtów obiektów potworków i bohatera, bo to że w odpowiedniej kolejności to wiem bo chociażby HUDa mam z kilku kawałków zachodzących na siebie. Chyba na obecnym etapie mojego projektu dodam drugi obiekt rysujący który będzie rysował grafiki na ostatnim planie (czyli te za hero i przeciwnikami) a ten pierwszy który mam teraz będzie odpowiadał za rysowanie HUDa (czyli za plan pierwszy).

Witam! Mam w jeden obiekt odpowiadający za rysowanie na roomie sprajtów nie będących obiektami. Obiekt ten rysuje zarówno HUDa (który zawsze musi być na pierwszym planie) jak i elementy grafiki znajdujące się "w głębi" rooma które mają być na ostatnim planie np. obrazki wiszące na ścianie itp. (widok z boku jak w platformówce). Pomiędzy HUDem a takimi przykładowymi obrazkami chodzą postacie przeciwników (osobne obiekty) oraz hero. Problem w tym, że nie da się tak ustawić parametrów depth obiektu rysującego aby obiekty hero i przeciwników "wchodziły" między HUDa a obrazki bo albo chodzą "na" HUDzie albo "pod" obrazkami. Czy jest jakiś sposób aby za pomocą tego jednego obiektu odpowiadającego za rysowanie uzyskać efekt taki jaki potrzebuję? Wspomnę, że ustawianie odpowiedniej "głębokości" parametrem depth tuż przed rysowaniem HUDa i obrazków nie daje żadnego efektu.

Najpierw poczytaj o tablicach w helpie. Później stwórz tablice dwuwymiarową gdzie będziesz miał informacje o parametrach broni. Przykład wycięty żywcem z mojej produkcji: Tablica broni: GML i:=0; global.obiekt[i,0]:=4;//"Wielkosc siatki X (ilosc kolumn x 32)"; global.obiekt[i,1]:=2;//"Wielkosc siatki Y (ilosc wierszy x32)"; global.obiekt[i,2]:=bron_spr; global.obiekt[i,3]:=0;//Animowany (-1), lub IMAGE_INDEX sprajta (dla sprajtow zawierajacych wiele obrazow roznych obiektow)"; global.obiekt[i,4]:=0;//"Typ obiektu (0-bron, 1-ammo, 2-granaty, 3-apteczki, 4-kamienie)"; global.obiekt[i,5]:="Mosin"; //N A Z W A global.obiekt[i,6]:=1000;//"CENA - warto zachowac proporcje cen danych typow obiektow"; global.obiekt[i,7]:=4;//"Waga broni pustej bez magazynka (w kg)"; global.obiekt[i,8]:="7.62"; //Kaliber; global.obiekt[i,9]:=5;//Pojemnosc max magazynka/bebenka (czyli rewolwer 7) global.obiekt[i,10]:=130;//Zasieg w metrach (skuteczny); global.obiekt[i,11]:=700;//Predkosc poczatkowa w m/s global.obiekt[i,12]:="P";//Tryb strzelania: P-pojedynczy, S-Seria global.obiekt[i,13]:=3;//Czas (w sek) przeladowywania pocisku pomiedzy kolejnym wystrzalem ((60/szybkostrzelnosc) - czas wymiany) global.obiekt[i,14]:=6;//Czas (w sek) przeladowania calego magazynka/pestki(dla pestkowcow czas wymiany 1 pestki, dla magazynkowcow czas wymiany calego magazynka) global.obiekt[i,15]:="M";// M/N czy bron zasilana Magazynkiem czy pojedynczymi Nabojami (pestkami), global.obiekt[i,16]:="";//Y3-szybkostrzelnosc (ilosc wystrzalow na minute) - chyba niepotrzebne ewentualnie jako info global.obiekt[i,17]:=1;//"Typ broni (0-bron kr. (pist., rewol.), 1-karabiny, 2-automaty)"; global.obiekt[i,18]:="";//wolne global.obiekt[i,19]:="";//wolne //i=1;(to inaczej ID tablicy) i+=1; //WAZNE ZEBY TO TEZ KOPIOWAC! //WAZNE ZEBY PRZYPISYWAC ID BRONI DO ID POCISKOW global.obiekt[i,0]:=2;//"Wielkosc siatki X (ilosc kolumn x 32)"; global.obiekt[i,1]:=2;//"Wielkosc siatki Y (ilosc wierszy x32)"; global.obiekt[i,2]:=bron_spr; global.obiekt[i,3]:=1;//Animowany (-1), lub IMAGE_INDEX sprajta (dla sprajtow zawierajacych wiele obrazow roznych obiektow)"; global.obiekt[i,4]:=0;//"Typ obiektu (0-bron, 1-ammo, 2-granaty, 3-apteczki, 4-kamienie)"; global.obiekt[i,5]:="Glock 17"; //N A Z W A global.obiekt[i,6]:=500;//"CENA - warto zachowac proporcje cen danych typow obiektow"; global.obiekt[i,7]:=0.625;//"Waga broni pustej bez magazynka (w kg)"; global.obiekt[i,8]:="9"; //Kaliber; global.obiekt[i,9]:=17;//Pojemnosc max magazynka/bebenka (czyli rewolwer 7) global.obiekt[i,10]:=50;//Zasieg w metrach (skuteczny); global.obiekt[i,11]:=360;//Predkosc poczatkowa w m/s global.obiekt[i,12]:="P";//Tryb strzelania: P-pojedynczy, S-Seria global.obiekt[i,13]:=0.5;//Czas (w sek) przeladowywania pocisku pomiedzy kolejnym wystrzalem ((60/szybkostrzelnosc) - czas wymiany) global.obiekt[i,14]:=4;//Czas (w sek) przeladowania calego magazynka/pestki(dla pestkowcow czas wymiany 1 pestki, dla magazynkowcow czas wymiany calego magazynka) global.obiekt[i,15]:="M";// M/N czy bron zasilana Magazynkiem czy pojedynczymi Nabojami (pestkami), global.obiekt[i,16]:="";//Y3-szybkostrzelnosc (ilosc wystrzalow na minute) - chyba niepotrzebne ewentualnie jako info global.obiekt[i,17]:=0;//"Typ broni (0-bron kr. (pist., rewol.), 1-karabiny, 2-automaty)"; global.obiekt[i,18]:="";//wolne global.obiekt[i,19]:="";//wolne //i=2 (to inaczej ID tablicy) i+=1; // WAZNE ZEBY TO TEZ KOPIOWAC! //WAZNE ZEBY PRZYPISYWAC ID BRONI DO ID POCISKOW</span> Tablica amunicji: GML //**************** ponizej wklejamy tablice dla TYP 1 - AMMO ********** i:=0; global.obiekt[i,0]:=1;//Dla ammo nie przewidujemy wiekszych niz 1x1 global.obiekt[i,1]:=1;//Dla ammo nie przewidujemy wiekszych niz 1x1 global.obiekt[i,2]:=ammo_spr;//nazwa sprajta - kazdy obiekt docelowo animowany (wszystkie?) ma miec wlasnego sprajta"; global.obiekt[i,3]:=1;//"Animowany (-1), lub IMAGE_INDEX sprajta (dla sprajtow zawierajacych wiele obrazow roznych obiektow)"; global.obiekt[i,4]:=1;//"Typ obiektu (0-bron, 1-ammo, 2-granaty, 3-apteczki, 4-kamienie)"; global.obiekt[i,5]:="7.62 Soft"; //Nazwa obiektu (np. Karabin Kałasznikow - AK47)"; global.obiekt[i,6]:=10;//"CENA - warto zachowac proporcje cen danych typow obiektow"; global.obiekt[i,7]:=0.0108; //"Waga calego naboju (w kg)- plecakowa (bo naboje posiadac beda jeszcze wage samego pocisku)"; global.obiekt[i,8]:="7.62"; //Kaliber global.obiekt[i,9]:=0.0058; //Waga pocisku (do obrazen); global.obiekt[i,10]:="S" //Twardosc S/H, Soft/Hard (Soft - duzy odrzut, nie przelatuja; Hard - brak odrzutu, przelatuja); //i=global.il_broni+1; i+=1; global.obiekt[i,0]:=1;//Dla ammo nie przewidujemy wiekszych niz 1x1 global.obiekt[i,1]:=1;//Dla ammo nie przewidujemy wiekszych niz 1x1 global.obiekt[i,2]:=ammo_spr;//nazwa sprajta - kazdy obiekt docelowo animowany (wszystkie?) ma miec wlasnego sprajta"; global.obiekt[i,3]:=0;//"Animowany (-1), lub IMAGE_INDEX sprajta (dla sprajtow zawierajacych wiele obrazow roznych obiektow)"; global.obiekt[i,4]:=1;//"Typ obiektu (0-bron, 1-ammo, 2-granaty, 3-apteczki, 4-kamienie)"; global.obiekt[i,5]:="7.62 Hard"; //Nazwa obiektu (np. Karabin Kałasznikow - AK47)"; global.obiekt[i,6]:=10;//"CENA - warto zachowac proporcje cen danych typow obiektow"; global.obiekt[i,7]:=0.0105; //"Waga calego naboju (w kg)- plecakowa (bo naboje posiadac beda jeszcze wage samego pocisku)"; global.obiekt[i,8]:="7.62"; //Kaliber global.obiekt[i,9]:=0.0055; //Waga pocisku (do obrazen); global.obiekt[i,10]:="H" //Twardosc S/H, Soft/Hard (Soft - duzy odrzut, nie przelatuja; Hard - brak odrzutu, przelatuja); //i=global.il_broni+2; i+=1; global.obiekt[i,0]:=1;//Dla ammo nie przewidujemy wiekszych niz 1x1 global.obiekt[i,1]:=1;//Dla ammo nie przewidujemy wiekszych niz 1x1 global.obiekt[i,2]:=ammo_spr;//nazwa sprajta - kazdy obiekt docelowo animowany (wszystkie?) ma miec wlasnego sprajta"; global.obiekt[i,3]:=3;//"Animowany (-1), lub IMAGE_INDEX sprajta (dla sprajtow zawierajacych wiele obrazow roznych obiektow)"; global.obiekt[i,4]:=1;//"Typ obiektu (0-bron, 1-ammo, 2-granaty, 3-apteczki, 4-kamienie)"; global.obiekt[i,5]:="9mm Soft"; //Nazwa obiektu (np. Karabin Kałasznikow - AK47)"; global.obiekt[i,6]:=10;//"CENA - warto zachowac proporcje cen danych typow obiektow"; global.obiekt[i,7]:=0.0125; //"Waga calego naboju (w kg)- plecakowa (bo naboje posiadac beda jeszcze wage samego pocisku)"; global.obiekt[i,8]:="9"; //Kaliber global.obiekt[i,9]:=0.008; //Waga pocisku (do obrazen); global.obiekt[i,10]:="S" //Twardosc S/H, Soft/Hard (Soft - duzy odrzut, nie przelatuja; Hard - brak odrzutu, przelatuja); //i=global.il_broni+3; i+=1; Tablica łącząca bron z amunicją GML //************** TABELA AMMO vs BRON ************ //Po dodaniu broni lub ammo TRZEBA przypisac co do czego pasuje TAKZE DLA WSZYSTKICH JUZ wczesniej dopisanych //Zerowanie przypisan for (i=1; i<=global.il_ammo; i+=1;){ for (j=1; j<=global.il_broni; j+=1;){ global.ammo_bron[i,j]:=0; } } //global.ammo_bron[X-ammo,Y-bron]:= 1-Pasuje, 0-nie pasuje// X-ID Ammo, Y-ID Broni //global.ammo_bron[AMMO, BRON]:=0/1; global.ammo_bron[global.il_broni+1,1]:=1; //(7.62 Soft)) przypisujemy bron nr 1 (Mosin) global.ammo_bron[global.il_broni+2,1]:=1; //(7.62 Hard)) przypisujemy bron nr 1 (Mosin) global.ammo_bron[global.il_broni+3,1]:=0; //9mm S NIE pasuje do MOSINA //TEGO NIE TRZEBA BO JUZ W PETLI WYZEROWANE global.ammo_bron[global.il_broni+4,1]:=0; //9mm H NIE pasuje do MOSINA //TEGO NIE TRZEBA BO JUZ W PETLI WYZEROWANE global.ammo_bron[global.il_broni+1,2]:=0; //(7.62 Soft nie pasi do Glocka //TEGO NIE TRZEBA BO JUZ W PETLI WYZEROWANE global.ammo_bron[global.il_broni+2,2]:=0; //(7.62 Hard nie pasi do Glocka //TEGO NIE TRZEBA BO JUZ W PETLI WYZEROWANE global.ammo_bron[global.il_broni+3,2]:=1; //9mm S pasuje do Glocka global.ammo_bron[global.il_broni+4,2]:=1; //9mm H pasuje do Glocka global.ammo_bron[global.il_broni+1,3]:=0; //(7.62 Soft nie pasi do UZI //TEGO NIE TRZEBA BO JUZ W PETLI WYZEROWANE global.ammo_bron[global.il_broni+2,3]:=0; //(7.62 Hard nie pasi do UZI //TEGO NIE TRZEBA BO JUZ W PETLI WYZEROWANE global.ammo_bron[global.il_broni+3,3]:=1; //9mm S pasuje do UZI global.ammo_bron[global.il_broni+4,3]:=1; //9mm H pasuje do UZI</span> To tylko wycinek mający Ci uzmysłowić jak mniej więcej można rozwiązać przechowywanie informacji o broni. Wiele z tych informacji jest zbędnych ale tak jak pisałem wyżej jest to przykład wyjęty żywcem z mojej produkcji. Czyli w skrócie robisz jedna tablice dla rodzajów broni, drugą dla rodzajów amunicji i trzecią gdzie przypisujesz broń do amunicji. U mnie jest tak bo jest wiele typów amunicji dla jednego typu broni.

No nie do końca :) Tło składa się z 11 poziomych pasków które mają 3 punkty przyjmujące różne stany on/off czyli w zapisie binarnym jeden pasek tła może przyjmować 8 różnych stanów (000, 001, 010, 011, 100, 101, 110, 111) czyli inaczej 2^3. Czyli dla 11 pasków to 88 kombinacji. W grze na ekranie w tym samym czasie widać zawsze 4 pasy czyli maksymalnie 2^12 kombinacji on/of (4096). Łącznie dla wszystkich 11 poziomych pasków jest 2^88 kombinacji czyli ogromnie dużo. Aby nie rysować do emerytury tych 2^88 backgroundów poszatkowałem tła na paski. Stany on/off wszystkich poziomych pasków i poszczególnych 3 punktów na pasku przechowuje tablica "swiatlocien". Z niej układam nazwę danego paska (pierwsza liczba to nr paska 0-10, kolejne 3 liczby to stany on/of punktów na danym pasku). Proste i czytelne. Początkowo zrobiłem to na ładowaniu plików z zewnątrz a obecnie "tłumaczyłem" skrypt na wczytywanie tych poszczególnych pasków z zasobów umieszczanych bezpośrednio w pliku exe bo chcę porównać działanie na słabych komputerach (prawdopodobnie gra mająca wszystko w exe wcale nie odpali na słabych maszynach więc wrócę do opcji wczytywania zasobów z plików). EDIT: Jeszcze jedna istotna uwaga. Musiałem zmienić nazwy backgroundow z cyfrowych na znakowe, teraz zamiast 0000 mam _0000 bo to powodowało, że źle mi szukało np. dla tła o nazwie 0000 szukało mi tła o nr zero a nie tła które się tak nazywało. Więc musiałem dodać prefiks do nazwy cyfrowej i wszystko działa ok.

To nie jest przyczyną (zauważ, że tam nigdzie nie ma przecinka). Ale w końcu mnie olśniło. Przyczyną jest ta linijka: GML background_replace(tlogm, tlo, 0, 1); Wcześniej miałem ładowanie tła z plików i przy przepisywaniu na ładowanie tła z pamięci z rozpędu podmieniłem tylko parametr "tlo" ze ścieżki na nazwę zdefiniowanego bacgrounda który definiuje w resources. Ale to nie ma prawa działać bo parametr tło to nic innego jak "fname" czyli ścieżka do pliku na dysku. Więc wystarczy w moim kodzie usunąć tą linijkę oraz zapisać tlogm=tlo; lub od razu przypisywać pod tlogm wartości z tablicy global.swiatlocien. Kocham "czeskie" błędy. Znowu kilka godzin na marne :(

Witam! Szukam od godziny i nic mi nie wychodzi. Mam zdefiniowanych kilkanaście podkładów (poszatkowane części kilku dużych teł) o nazwach składających się z 4 cyfr: 0000 0001 0010 1000 1001 0010 itd. Trzy ostatnie cyfry przechowywane są w tablicy (jako osobne cyfry). W poniższy kod zaczytuje (powinien) kawałki tła i skleja je w jedno duże tło. Gdy kawałki przechowywane były na dysku i wczytywane z plików png wszystko działa ok. W momencie gdy załadowałem te wycinki do exe mam problem z zamiana nazwy tych kawałków tak by to działało. GML ip=2; ik=0; for (i=ip; i>=ik; i-=1) { TO DZIAłA BEZ PROBLEMU //tlo:=working_directory+"\room\"+string(i)+string(global.swiatlocien[i,0])+string(global.swiatlocien[i,1])+string(global.swiatlocien[i,2])+".png"; NIE DZIALA //tlo:=string(i)+string(global.swiatlocien[i,0])+string(global.swiatlocien[i,1])+string(global.swiatlocien[i,2]); NIE DZIALA tlo_tmp:=string(i)+string(global.swiatlocien[i,0])+string(global.swiatlocien[i,1])+string(global.swiatlocien[i,2]); tlo:=variable_global_get(tlo_tmp); NIE DZIALA execute_string(' tlo = '+tlo_tmp); POKAZUJE ZAWSZE NAZWE PIERWSZEGO BG //show_message(background_get_name(tlo_tmp)); NIE DZIALA //execute_string("tlo="+string(i)+string(global.swiatlocien[i,0])+string(global.swiatlocien[i,1])+string(global.swiatlocien[i,2])); PKOAZUJE PRAWIDLOWE NAZWY TLA show_message(tlo); background_replace(tlogm, tlo, 0, 1); draw_background(tlogm,0-korekta,(j*213)+(j*17)); j+=1; } DZIALA OK //tlo:=working_directory+"\room\B000.png" DZIALA OK tlo:=B000;//working_directory+"\room\B000.png" background_replace(tlogm, tlo, 0, 1); draw_background(tlogm,0-korekta,(j*213)+(j*17)); Próbowałem też variable_global_get i variable_local_get ale też nie zadziałało. Czyli podsumowując: w jaki sposób przekształcić stringa który powstał z kawałków w nazwę zdefiniowanego tła tak by GM to zrozumiał?

Już próbowałem dawać te komendy i efekt jest taki, że w następnym wywołaniu program krzyczy o to że te indeksy nie istnieją (zresztą prawidłowo). Dziwi mnie tylko to, że wywołanie: background_index[0]:=background_create_from_surface(global.surfejs2,0,0,room_wid th/2, 800,0,1) tworzy KAŻDORAZOWO nowy indeks w pamięci.

Witam! Mam następujący skrypt który powoduje ładowanie tła składającego się z 4 pasków zapisanych w postaci plików png których nazwy przechowuje tablica swiatlocien. GML //argument0 = nieuzywany //argument1 = L/P - ktora czesc tla korekta:=0; if argument1 == 'P' then korekta:=room_width/2; global.surfejs2:=surface_create(room_width/2, 800); surface_set_target(global.surfejs2); draw_clear_alpha(c_black, 0); //czyszczenie surfejsa tlogm:=background0; j:=0; ip:=global.aktywne_pietro+1; ik:=global.aktywne_pietro-2; for (i=ip; i>=ik; i-=1) { tlo:=working_directory+"\room\"+string(i)+string(global.swiatlocien[i,0])+string(global.swiatlocien[i,1])+string(global.swiatlocien[i,2])+".png"; background_replace(tlogm, tlo, 0, 1); draw_background(tlogm,0-korekta,(j*213)+(j*17)); j+=1; } surface_reset_target(); if korekta <> 0 then { //PRAWE background_index[1]:=background_create_from_surface(global.surfejs2,0,0,room_width/2, 800,0,1); background_x[1]:=korekta; background_visible[1]:=true; background_y[1]:=((10-global.aktywne_pietro)*230)-12; } else { //LEWE background_index[0]:=background_create_from_surface(global.surfejs2,0,0,room_width/2, 800,0,1) background_y[0]:=((10-global.aktywne_pietro)*230)-12; } surface_free(global.surfejs2); Zauważyłem, że w takiej formie każdorazowe wywołanie skryptu powoduje utworzenie dwóch nowych backgroundow w pamięci i zużycie kolejnych kilkunastu MB. Winne są te 2 linijki: background_index[1]:=background_create_from_surface(global.surfejs2,0,0,room_wid th/2, 800,0,1); background_index[0]:=background_create_from_surface(global.surfejs2,0,0,room_wid th/2, 800,0,1); Wydaje mi się, że teoretycznie jak przypisuje tworzone tlo z surfejsa do istniejących indeksów to nie powinny być tworzone za każdym razem kolejne nowe a niestety tu po każdym wywołaniu skryptu mam 2 nowe. Co jest nie tak?

Już przysypiam i pewnie pytanie będzie banalne. Jak uzyskać z liczby całkowitej liczbę heksadecymalna którą później chcę zapisać jako string. Czyli taki kawałek kodu: GML for (i=0; i<12; i+=1) { tlo:=working_directory+"\gotowe\"+string(i)+string('.png'); aaa=background_replace(tlogm, tlo, 0, 1); draw_background(tlogm,0,218+(i*125)); } tlo ma mieć ścieżkę w postaci "working_directory\gotowe\(i).png", gdzie i ma przyjmować wartości 0,1,2,3,4,5,6,7,8,9,A,B,C (oczywiście bez tych nawiasów).

No jeszcze tak myślę czy może nie zrezygnować z obiektów, grawitacji kolizji a zrobić to na tablicy dwuwymiarowej przechowującej współrzędne kostek (albo raczej originów sprajtów). W momencie klikania myszką mógłbym usuwać z tablicy dany "obiekt" oraz zmienić położenie wszystkich tych nad tym zniszczonym i ponownie je rysować. Jedyny warunek to taki, że klocki muszą być ustawiane na roomie na siatce 4x4. Opadanie klocków następowałoby od razu o 4px.

Czyli w takim razie co? W GM8 grafika od razu ładowana jest do video memory czy wręcz przeciwnie dopiero w momencie użycia? I czy to się zmieniło od GM v8 czy w v7 też już tak było? EDIT: Znalazłem, że to zmieniło się od v8 ale dalej nie wiem czy obecnie ładują się wszelkie grafiki od razu do pamięci graficznej. Czy mam rozumieć że w przypadku jeśli jednak od razu grafika ładowana jest do pamięci video to jak stworze sobie w resorces 90 backgroundow to one od razu są zasysane do video memory? Wydaje mi się że chyba nie do końca.

No chyba nie do końca jest tak że GM wczytuje od razu wszystkie zasoby. Z tego co pamiętam to sprajt jest ładowany dopiero w momencie użycia czyli mogę mieć zdefiniowanych (w resorces) 20 sprajtów a póki ich nie załaduję do obiektu i nie użyję tego obiektu to sprajt nie zajmuje pamięci graficznej. Wiadomo, że cała grafika zawarta w exe jest zaczytywana do RAMu ale nie jest od razu wrzucana do pamięci grafiki a o to mi najbardziej chodzi czyli dokładnie o optymalizację gry w taki sposób aby uruchamiała się na słabym sprzęcie (np. z kartą grafiki np riva tnt m64 z 64MB ramu czy innych niewiele lepszych wbudowanych w NETbooki czy słabe laptopy). Podobnie jest z backgroundami - możesz mieć ich dziesiątki ale póki ich się nie użyje to siedzą sobie w RAMie a nie w pamięci karty graficznej. Dlatego też rozważam podzielenie tych przykładowych krzeseł na osobne sprajty bo wg mnie w przypadku gdybym miał jednego dużego sprajta (ze wszystkimi klatkami), użycie pamięci będzie takie same jedynie wtedy kiedy na aktywnym ekranie będą obiekty wykorzystujące wszystkie osobne sprajty a już w przypadku gdy na aktywnym widoku będą tylko niektóre rodzaje krzeseł to tej pamięci powinien GM zużywać mniej dla obiektów używających sprajtów jednoklatkowych (wszelkie obiekty poza aktualnym widokiem zawsze dezaktywuję).

Witam! Czy jak zrobię sprajta dwuklatkowego (każda klatka ok. 256kb pamięci) zajmującego łącznie 500kb pamięci i użyję go w 2 instancjach obiektu z tym że w pierwszym użyję tylko klatki pierwszej a w drugim tylko klatki drugiej to ile pamięci zużywa GM? Czy jest to po 256kb/obiekt bo używam tylko po jednej klatce czy jednak zużywa 512kb na obiekt czyli łącznie 1mb? Chodzi mi o to czy kumulować w jednym sprajcie kilka klatek używanych niezależnie ale w obiekcie tego samego typu czy robić osobne sprajty po jednej klatce? Przykładowo mam 4 rodzaje krzeseł różniące się tylko wyglądem i czy lepiej je wpakować do 4-ro klatkowego sprajta i przy tworzeniu instancji obiektu ustawiać odpowiednią klatkę (image_index oraz image_speed=0) czy lepiej rozbić to na 4 osobne sprajty i przy tworzeniu obiektu ustawiać odpowiedni sprajt (sprite_index). W którym przypadku użycie pamięci graficznej będzie mniejsze? A może nie ma różnicy bo liczy się użyta pojedyncza klatka niezależnie od ilości klatek z jakiej składa się sprite?

Witam! Mógłby ktoś podsunąć pomysł jak rozwiązać taki problem: - room 1024x768 (room_speed=60) - obiekt kostka4x4_obj o wielkości 4px na 4px posiadający grawitację oraz w zdarzeniu kliknięcia lewym klawiszem myszy instance_destroy() - obiekt podloga32x4_obj o wielkości 32px na 4px bez grawitacji, z kolizją na kostka4x4_obj. - room wypełniam szczelnie jeden obok drugiego obiektami koastka4x4_obj czyli powstaje jedna wielka masa kostek z grawitacją oraz na samym dole rooma kładziemy podłogę z obiektów podloga32x4_obj. Uruchamiam to na mocnym kompie C2D 3,2GHz z dobrą grafą i dużą ilością RAMu i mam 3-4 FPS. Jak dodam jeszcze kolizje obiektów kostka4x4_obj z samą sobą to mam 0 FPS i praktycznie zwis. Pytanie czy GM jest na tyle powolny, że w nim nie ma szans na zrobienie gry z grawitacją wszystkich obiektów (kostek), gdzie "podkopanie" (zniszczenie kostki) powodowałoby "obsunięcie" kostek położonych wyżej? Już nawet nie chodzi mi o symulowanie fizyki czyli efekty tupu sypiącego się piasku ale o zwykłe spadania kostek w obrębie zniszczonej kostki (wszystkie kostki powyżej powinny spaść o wysokość 1 kostki w dół). A może ja się biorę za to od złej strony.

Działa nawet Begin i End zamiast { i } :) Mi chodzi bardziej o błąd samego GM (nieprawidłowe działanie funkcji eyboard_check(vk_tab), keyboard_check_pressed(vk_tab) a raczej całkowity brak działania) a nie błędy kompilatora.

Witam! Natrafiłem na problem z obsługą klawisza TAB w GMie v.8.0. Wg dokumentacji TAB traktowany jest jak każdy inny klawisz i powinny działać na nim funkcje keyboard_check(vk_tab), keyboard_check_pressed(vk_tab) i keyboard_check_released(vk_tab) a działa tylko i wyłącznie ostatni. Dodatkowo działa też keyboard_check_direct(vk_tab) mimo, że wg dokumentacji akurat TAB nie powinien. Czyli na upartego mamy działanie ciągłe oraz działa sprawdzanie "puszczania" klawisza TAB. Czy możecie to potwierdzić na Waszych wersjach GMa? Na razie rozwiązałem to tak, że w create mam dodatkowa zmienna tab:=false; i w stepie (lub w evencie "any key"): GML if keyboard_check_released(vk_tab) then tab:=false; if keyboard_check_direct(vk_tab) and tab==false then { //KOD KTORY MA SIE WYKONYWAC PO JEDNOKROTNYM NACISNIECIU TABA tab:=true; //WYLACZENIE POWTORNEGO DZIALANIA TAB }

Mój stary generator. Nie ukrywam, że nie bez wad ale u mnie sprawdził się idealnie. GML //Sadzi obiekty w obrebie podanych namiarow //argument0 - x1 //argument1 - y1 //argument2 - x2 //argument3 - y2 //argument4 - ile obiektow //argument5 - jakie obiekty //argument6 - ilosc powtorzen dla nieudanego sadzenia (zeby nie zapetlic gry jak nie znajdzie wolnego placu) //argument7 - gestosc x1:=argument0; y1:=argument1; x2:=argument2; y2:=argument3; ile:=argument4; czego:=argument5; powt:=argument6; gestosc:=argument7; zasadzone:=0; //ilosc obiektow jakie uda sie zasadzic nieudane:=0; //ilosc nieudanych prob przerwac:=false; //przerywamy kiedy ilosc prob przekroczy dozwolona liczbe if powt < 1 then powt:=1; //jesli ilosc prob zostala ustawiona na za mala daj 1 if powt > 50 then powt:=50; //jesli ktos przedobrzy z iloscia prob to moze podwiesic kompa na dluzszy czas if gestosc < -2 then gestosc:=-2; //jesli zageszczenie zbyt male to daj -2 if gestosc > 2 then gestosc:=2; //jesli zageszczenie zbyt duze to daj 2 tmp:=instance_create(-300,-300,czego); //tworzymy obiekt tymczasowy zeby dx2:=(tmp).sprite_width/(4+gestosc); //odczytac jego szerokosc dy2:=(tmp).sprite_height/(4+gestosc); //i wysokosc dzielac ja przez 4+ gestosc with (tmp) instance_destroy(); //niszczymy obiekt tymczasowy do { do //Pętla typu "do" wykonuje akcje w klamrach dopóki przy until jest "false" (fałsz) { dx:=random(x2-x1)+x1; // losuj pozycje x od x1 do x2 planszy dy:=random(y2-y1)+y1; // losuj pozycje y od y1 do y2 planszy if nieudane > (ile*powt) then przerwac:=true; //jesli ilosc prob przekroczy max to przerywamy sadzenie nieudane+=1; } //w until sprawdzanie elipsy w prostokacie wylosowanym +/- dl i szer obiektu until (przerwac==true or collision_ellipse(dx-dx2,dy-dy2,dx+dx2,dy+dy2,all,1,1)<=100003);//collision_circle(dx,dy,64,all,1,1)<=100003);// place_free(dx,dy)); //Powtarzaj az pozycja bedzie wolna if przerwac==false then {instance_create(dx, dy, czego); //jesli wyszlismy z powyzszej petli z prawidlowa pozycja to posadz obiekt zasadzone+=1;} //i zwieksz licznik obiektow o 1 } until (zasadzone >= ile or przerwac==true) //lub jesli wszystkie proby zakonczone pomyslnie lub przekroczony max limit prob to zakoncz</span>

Witam! Wiem, że kiedyś ktoś już o to pytał bo nawet czytałem o tym ale nie mogę teraz tego znaleźć. Czy można zablokować działanie lewego alta, który powoduje pauze (przy grze uruchamianej w oknie)?

Nie do końca się zgodzę :). Pomijając piracenie GMa, można przecież uruchomić wersję lite gdzie kod oraz help będzie dostępny a jeśli użyto w przykładach funkcji z GM Pro to zawsze ktoś na forum może przekompilować przykład do exe. A link do artykułu o którym pisze Tymon to https://gmclan.org/index.php?czytajart=74

Poszukaj przykładu "Latarka.gmk" tu na gmclanie opartego na surfaces. Niestety nie pamiętam dokładnie gdzie to leży a autor nie raczył nic wpisać do game information. EDIT: Sorki faktycznie przeoczyłem ze C# a nie GM.

Sorki dopiero teraz zauważyłem że już ktoś kiedyś o to pytał i dostał odpowiedź https://forum.gmclan.org/index.php?showtopi...+kilka+obiektow

Witam! Jak wykrywać kolizje hero z wieloma przeciwnikami na raz poprzez collision_line, unikając tego by kod wykonywany był we wszystkich obiektach przeciwnikach. Czyli idzie sobie hero, "strzela" i wszystko co znajduje się na linii hero.x-100 do hero.x+100 zostaje "trafione" i w tych obiektach zmniejszana jest wartosc zmiennych "energia". Normalnie collision_line zwraca ID jednego obiektu a ja potrzebuje wszystkie znajdujące się w danej chwili na linii.

ma byc: if(global.map==1)