TO_mek

Witam! Denerwuje mnie to że obsługa klawiszy poprzez dodawanie eventów wymaga dodawania osobno w każdym zdarzeniu kolejnych klawiszy i wpisywanie kodu obsługi dla tego konkretnego klawisza. Pomyślałem sobie że zrobię jeden skrypt obsługi w którym dopiszę wszelkie kolejne klawisze i będę to miał w jednym miejscu a też pozwoli mi to uprościć kod dla powtarzających się klawiszy (np. 1 z klawiatury numerycznej i zwykłej ma u mnie to samo działanie) oraz w prosty sposób pozwoli na wyłączenie obsługi grupy pewnych klawiszy w pewnych przypadkach (np. hero wchodzi do "sklepu" i następują inne akcje dla tych samych klawiszy). No i zastanawiam się czy wywoływać ten skrypt na początku zdarzenia step czy może podpiąć go pod zdarzenie dla "klawisza any key". Ma to jakiś wpływ na prędkość działania? A może samo użycie skryptu to zły pomysł i lepiej ładować jednak w osobne zdarzenia klawiszy? A może wywoływać w osobnych zdarzeniach klawiszy skrypt podając jako argument kod klawisza (to chyba całkiem bez sensu).

Ja bym zrobił to tak: Deaktywacja (instance_deactivate_region(left,top,width,height,inside,notme) przy inside=false) 1. Wyłączyć wszystko dla regionu mniejszego 2. Włączyć otoczenie 3. Wyłączyć wszystko dla regionu większego 3. Włączyć potrzebne obiekty (hud, Kontrol, Major) chociaż chyba Major i hud jest zawsze wewnątrz stref wiec i tak są aktywne. Tylko tak się zastanawiam o co biega z tym wchodzeniem obiektów pod budynki. Przecież jak wszystko masz zdefiniowane prawidłowo to deaktywując obiekty są one nieaktywne i nie przesuwają się jak ich nie widać a przy aktywacji pojawiają się w miejscu ich wyłączenia. Jedyne logiczne wyjaśnienie to takie, że obiekty otoczenia są większe i są dłużej wyłączone niż obiekty wroga dlatego wróg wchodzi na miejsce gdzie jest dane drzewo czy budynek. Przy okazji zobacz jak masz ustawione wysokość i szerokość (na 1280) a punkt początkowy (lewy, górny ustawiasz na -1024,-1024) więc zostaje ci margines z dołu i z prawej tylko 256 (różnica). Pamiętaj, że trzeci i czwarty parametr określa wysokość i szerokość a nie współrzędne punkt przeciwnego.

Witam! Szukam i szukam i nie widzę. Chce rysować obrys elementu żółtą linią o grubości np. 3px za pomocą komendy draw_rectangle(a-50,b-50,a+50,b+50,true). Kolor ustawić potrafię (np. draw_set_color(c_yellow)) natomiast szukam odpowiednika dla grubości rysowanej linii i nie widzę. Jest coś takiego w GM8 czy trzeba kombinować?

A może używasz tej komendy deaktywacji i aktywacji obiektów nie tylko w obj_controller

Ok brzmi prosto :) Do tej pory aby wczytać całe tło, używałem: GML tlo:=working_directory+"/obraz_tla.jpg"; tlogm:=background0; aaa=background_replace( tlogm, tlo, 0, 1); i to było banalnie proste. Jaką komendą mam wczytać kawałek tła z pliku i od razu narysować na surface?

Ale kto mówi o room edytorze?! To to samo jak instance_create czyli kolejność tworzenia obiektów na roomie. Mi chodzi o zdefiniowanie (utworzenie definicji obiektu, nadanie mu nazwy) samego obiektu w edytorze GMa. I właśnie ta kolejność decyduje o kolejności o której wspominam wcześniej. Poczytajcie na spokojnie jeszcze raz od początku wszystko.

Witam! Jak w najprostszy sposób wczytywać z plików (jpg, png, bmp) grafiki do surface. Chodzi mi o to, że mam kilka kawałków tła (prostokąty różnej wielkości) z którego chcę otrzymać tło całkowite a później używać go (już posklejanego) za pomocą surface. Czy muszę najpierw wczytywać z pliku jeden kawałek grafiki do tła tymczasowego, narysować na roomie w odpowiednim miejscu, wczytać następny, narysować obok itd. aż skompletuję całe tło i wtedy wycinać do surface? Może macie jakiś sprawdzony gotowy prosty sposób.

Nie do końca bo to zbyt ogólnie powiedziane. Duże znaczenie ma kolejność utworzenia obiektu w edytorze i to jest chyba najpierw brane pod uwagę oczywiście w ramach pewnych eventów (begin step, step, kolizje). Drawem rządzi depth. ID ma wpływ na samym końcu.

W pewnych przypadkach stosowanie surfaces przyspiesza działanie. Wyświetlanie tekstów też potrafi spowolnić, ja swego czasu podczas przerabiania moich starych wypocin z gm4 do gm7 i 8 w pewnym momencie stanąłem przed problemem takim że gry wcześniej działające na 30fps osiągały nagle 3-5fpsów na słabych komputerach (netbook z marną grafiką). Po odpowiedniej optymalizacji spadki są tylko w momencie gdy dużo się dzieje na ekranie a wystarczyło tylko pomyśleć aby wyświetlać teksty nie co krok a tylko w momencie gdy te teksty się zmieniały (np. zmiana punktacji). Także niepotrzebne tworzenie obiektw, które służyły tylko do wyświetlania grafiki a wystarczyło użyć draw_sprite w jednym obiekcie który odpowiada tylko za rysowanie. Pomijam drobiazgi o których też warto pamiętać np. i=i+1; zastąpić przez i+=1; choć różnicy pewnie nie zauważysz ale jak to mówią ziarnko do ziarnka itd. A z gotowych artykułów znalazłem kiedyś taki Także ładowanie dużych grafik tła w jednym kawałku wymaga odpowiedniej ilości pamięci graficznej i na komputerach ze słabą grafiką gra się albo nie uruchamia albo część tła się nie wyświetla więc warto np. podzielić tło przy dużym roomie na kawałki i ładować je w momencie kiedy są widoczne. Jedynie nie jestem pewny czy trzymane grafiki w exe są na dzień dobry ładowane do pamięci graficznej czy dopiero w momencie użycia więc najlepiej wczytywać je z plików wg aktualnych potrzeb. EDIT: Przykładowo ostatnie moje testy przeprowadziłem na 3 komputerach: A. C2D E8600 3,33GHz, 4GB RAM, GF 8800GTS 512MB B. Netbook Intel Atom 1.6, 1GB RAM, Intel GMA 500 (na sterownikach alternatywnych do grafiki dynamiczny przydział do 128MB RAMu, na oryginalnych do 8MB ale testy robiłem na alternatywnych) C. Cel 2GHZ, 2GB RAM, GF2 MX 400 (64MB RAM) Dodatkowo włączony vsync (global game settings >> resolution >> drugi haczyk) co może mieć duży wpływ (niekorzystny) na FPS ale nie miało wpływu na samo ładowanie gry i wyświetlanie tła Dla gry z roomem 2500x3000, view 1024x768, grafika tła w jednym dużym kawałku (jpg) zapisana w exe, na ekranie aktywnych raptem 5 obiektów: A. Wszystko działa bez problemów z FPS 60, B. Gra odpala ale zamiast tła jest biały ekran (rysowanie koloru tła wyłączone), fps ok 45-50 C. Gra wcale nie odpala Dla tego samego rooma, tło podzielone na kawałki o wymiarach 2500x800 ładowane po jednym z pliku (dynamicznie nakładana na room w odpowiednich miejscach) A.Bez problemów, B. Odpala ale wciąż brak tła (tym razem jest czarny kolor tła), fps podobnie (45-50) C. Gra odpala, pokazuje się tło ale jakieś 250-300px pod koniec tła (przy prawej krawędzi ekranu) pojawia się "rozmycie" coś jak efekt gdy czasem zawiesi się okno windowsa którym można "malować po ekranie", prędkość 57-60fps. Ten sam room, tło podzielone na kawałki o wymiarach 1250x800, ładowane jako DWA osobne kawałki ładowane z pliku i układane na roomie obok siebie za pomocą 2 różnych backgroundów (na razie oba visible niezależnie czy są już wyświetlane w view czy nie. A. Bez problemów B. Odpala, jest tło wyświetlane prawidłowo, gra działa ale nieco wolniej niż bez tła (35-45 fps) C. Gra działa z prędkością 57-60fps, tło wyświetla się wszędzie prawidłowo. Pozostaje mi jeszcze tylko sprawdzić czy będzie jakaś różnica na niekorzyść jak najpierw zdefiniuje te kawałki tła na stałe i zapisze w exe. Czyli prosty zabieg podzielenia tła na mniejsze kawałki i wyświetlanie tylko tych które są widoczne, powoduje duże oszczędności i wręcz umożliwia samo uruchomienie. Oczywiście jeszcze pytanie kto dziś używa sprzętu typu C ale już sprzęt typu B to popularny netbook (nie mylić z notebookiem) z zeszłego roku.

Ok ale to niekoniecznie wynikało z pierwszego posta. Surfejsami bawiłem się mało ale jeśli można na nich wkleić sprajty transparentne (a przypuszczam, że tak) to stwórz jeden surface który będzie posiadał tylko te kawałki sprajtów które zasłaniać mają postacie (te pod którymi można przejść) i ustaw go w obiekcie rysującym "nad" postaciami a resztę wrzuć do tła albo do drugiego surface i rysuj go "pod" postaciami.

No to jednak robią bo blokują czyli są kolizje. Jeśli te obiekty nie są animowane to ja bym je narysował na tle na stałe i utworzył nowy background a do kolizji użył niewidocznych obiektów o takich samych maskach. Tylko czy to będzie miało wpływ na prędkość? W sumie odpada Draw każdego z obiektów z osobna jak utworzysz z nich zwykły background.

OK. Kolejność eventów mamy już ustaloną ale tak jak napisałem posta wyżej testy pokazują, że instancje tego samego obiektu, parametr depth oraz kolejność tworzenia obiektu w samym edytorze ma ogromne znaczenie i także jest zupełnie inne w zależności od eventu jakiego dotyczy, więc sprawa kolejności wykonywania zdarzeń wcale nie jest tak płytka jak w tym temacie który przytoczyłeś. Pozdrawiam

create w kolejnosci w jakiej sa tworzone obiekty na roomie (ale nie jak w edytorze) draw j.w. begin step - grupuje i wykonuje kopie obiektu ALE WCALE NIE TE O najnizszym ID (TE CO BYLY PIERWSZE W CREATE) ale te co byly pierwsze utworzone w edytorze a potem kolejne obiekty innego typu i jego kopie itd. - u mnie obiekt nr 1 wykonuje sie pierwszy! a utworzony byl w edytorze jako pierwszy ale w create jako drugi (majacy ID wyzszy o 1 od najnizsego) oraz obiekt nr2 utworzony jako drugi w edytorze ale jako pierwszy w create (majacy najnizszy nr ID) step j.w ! kolizje j.w. Masakra. Przy wiekszej ilosci obiektow takze to sie sprawdza czyli decyduje kolejnosc tworzenia obiektow w edytorze. Zmiana kolejnosci obiektwow w edytorze NIE MA WPLYWU na zmiane kolenosci wykonywania (a przy duzej ilosci obiektow zazwyczaj kazdy tworzy sobie podkatalogi na obiekty, usuwa, zamienia, kopiuje itd - i kto by pamietal ktory z tych obiektow byl utworzony w edytorze jako pierwszy!) To jeszcze czy na coś ma wpływ depth. Masakra do kwadratu! Depth ma wpływ ale WYŁĄCZNIE na event DRAW i wyświetla się zawsze grupa obiektów o najwyzszej wartosci depth zaczynajac od najnizszej wartosci ID w danej grupie. No to powodzenia w zapanowaniu nad tym wszystkim :) EDIT: Testowane na GM8

Faktycznie tak działa. Tylko jestem trochę zaskoczony bo już wielokrotnie spotkałem się z opinią że eventy wykonują się w tej kolejności w jakiej pojawiają się w oknie Events: (nieważne co się pierwsze wybierze to i tak kolejność w jakiej ułożą się eventy jest stała). A tutaj event EndStep układa się zaraz PO step ale PRZED kolizjami co obala powyższą teorię! No ale dalej mam dylemat jak to zadziała gdy wiele obiektów będzie odwoływać się do tej samej zmiennej globalnej - czy najpierw lecą wszystkie step potem wszystkie kolizje a potem wszystkie endstep czy leca po kolei "całe" obiekty po obiekcie. No i w jakiej kolejności? A może w steep dać kod sprawdzający kolizje w danym momencie i bezpośrednio po tym wykonać działanie? Tylko że te funkcje (place_meeting(x,y,obj) czy collision_point(x,y,obj,prec,notme)) sprawdzają kolizje punktowo (origin) a to mnie za bardzo nie urządza bo mój obiekt (który by sprawdzał kolizje z innymi obiektami) jest dosyć niekształtny.

Witam! Załóżmy że zmienna "zmienna" jest globalna. Czy jak wpisze w jednym obiekcie w step zmienna=0 i w tym samym obiekcie w evencie kolizji z innym obiektem zmienna=1 to czy wykona mi się kod w step jeśli wpisze w nim na samym końcu if zmienna == 1 then wykonaj_costam()? Pewnie nie bo w tym samym kroku w stepie nadaje zmiennej 0 i oczekuje ze będzie miała za chwile 1 z kolizji. To inaczej, potrzebuje by w momencie gdy jest kolizja, "zmienna" była równa 1 i wykonywał się kod w step ale w momencie gdy już kolizji nie będzie to "zmienna" powracała do wartości 0. Powyższy przykład w step odpada bo na logikę nigdy się nie wykona. W momencie kolizji nadanie zmiennej wartości 1 to nie problem ale jak mam wykryć brak tej kolizji i nadawać ponownie wartość 0? Kolizje wykrywam poprzez dodanie AddEvent->Collision z wybranym obiektem a następnie dodaje kod i w nim w kodzie wpisuje zmienna:=1;, obiekty na razie nie są solid. EDIT: Ok sprawdziłem, że powyższy sposób nie zadziała ale w momencie gdy w step wpisałem najpierw warunek if zmienna==1 then costam a dopiero w kolejnej linii zmienna:=0; to wtedy warunek jest wykonywany. Czyli wychodzi na to, że najpierw leci step obiektu a potem leci kolizja która nadaje wartość 1 i w następnym przejściu w step na dzień dobry mamy wartość 1 i wykonuje warunek a dopiero potem nadaje zmiennej 0. No ok to to mniej więcej działa (z opóźnieniem jednego kroku) ale co w przypadku gdy: kolizja wykrywana będzie w obiekcie1 a warunek postawiony w zupełnie innym obiekcie? Jak tutaj wygląda wykonywanie eventów? Czy najpierw wykonywane są wszystkie warunki jednego typu dla wszystkich obiektow, później kolejne eventy wszystkich obiektow itd. czy najpierw leci cały obiekt ze wszystkimi eventami, potem następny obiekt itd.? No i co decyduje o kolejności wykonywania zdarzeń w danych obiektach tzn. który obiekt wykonuje działania jako pierwszy? Czy to leci wg depth (a co jak obiekty mają tą samą wartość depth) czy może wg tego w jakiej kolejności są definiowane obiekty w edytorze albo w jakiej kolejności są utworzone w grze (no to jak tak to znowu pytanie co leci pierwsze czy obiekty zdefiniowane na roomie już w edytorze czy może w evencie create rooma albo jak)?

A ja dalbym kazdemu klockowi zmienna "energia", pozniej w momencie kolizji gracza z klockiem odejmowal ta energie i podmienial kolejne klatki sprajta klocka na coraz bardziej zniszczone az dojdzie energia do zera i klocek znika. A i jeszcze niszczenie klocka (czyli zmniejszanie energi) wywolywalbym tylko wtedy gdy gracz idzie po klocku a nie stoi (czyli if x<> xprevious then energia-=1). Wystarczy odpowiednio dobrac zmienna energia by gracz mogl 1 czy 2 razy swobodnie przejsc po klocku a za kolejnym razem klocek juz by sie zawalil. Natomiast jesli gracz naskoczylby na klocek (czyli if y> yprevious then instance_destroy) to klocek ulegalby od razu zniszczeniu.

Witam! Czy sprajty mają ograniczoną paletę kolorów do 256 czy można używać truecolor?

Witam! Chcę aby cała gra zawierała się w jednym pliku exe. Jakie są ograniczenia? Czy zdefiniowanie różnego tła i sprajtów wiąże się z tym że od razu przechowuje je pamięć karty graficznej czy dopiero te grafiki trafiają tam w momencie użycia danego podkładu czy obrazu sprajta? Pytam bo na słabszych konfiguracjach (grafika gf mx400 z 64MB pamięci graficznej) gra przestaje działać już w momencie uruchamiania i jest to spowodowane tym że jest zbyt wielkie tło (room 5000x500) ładowane w jednym wielkim kawałku (z mniejszym kawałkiem tła się uruchamia ok). W związku z tym chcę pociąć tło na kawałki 2500 x 1000 czyli w sumie na 10 odrębnych podkładów i używać ich w momencie gdy hero będzie w danym rejonie rooma odpowiednio je pozycjonując. Tylko zastanawiam się czy jak zapiszę je wszystkie od razu w exe a nie będę dogrywał z osobnych plików to czy to mi coś da.

Takiej komendy nie ma w gm8 a w sumie częściowo to by rozwiązało problem. Są background_set_alpha_from_background sprite_set_alpha_from_sprite.

Dawidds: Widok z boku. Dlatego tez od razu w pierwszym poście pisałem że efekty chcę ograniczyć do aktualnie widocznego ekranu bo po co mi się ma przeliczać coś czego aktualnie nie widać na ekranie. Ale wyłączenie obiektów z poza aktualne wyświetlanego widoku to już nie problem. Pytanie jak uzyskać efekty światła najmniej tracąc na wydajności.

Aż tak niezrozumiale napisałem pierwszego posta? Robię coś w rodzaju platformówki, mam rooma 5000x5000, ładuje do niego tło na którym mam narysowany przekrój budynku z poszczególnymi piętrami. Teraz chcę aby: - nadać na każdym piętrze przyciemnienie czyli odpowiednik bacground_alpha na ~0.4 - na zewnątrz budynku nadać background_alpha = 1 czyli bez przyciemniania, - na każdym z pięter jest kilka miejsc gdzie są zamontowane lampy, które mają rozświetlić korytarz po ich załączeniu, - lampy mają działać tylko w ograniczonym zakresie czyli świecić wokoło (promień ok. 100px) ale tak by światło nie przechodziło przez stropy, - na koniec jeszcze może efekty typu cień postaci zbliżającej się do źródeł światła oraz być możę drganie światła (coś jak drgający płomień świecy). Mam nadzieję że teraz jest wszystko jasne.

Witam! Mam dużego rooma (5000x5000) z widokiem 1024x768. Potrzebuje nadać tłu background_alpha[0] = 0.4 ale chcę to zrobić: - po pierwsze tylko na aktualnie widocznym ekranie gry (widok 1024x768) (jeśli będzie to rozwiązane na obiektach to sobie je wyłączę gdy są poza widokiem), - po drugie, co jest sednem pytania, potrzebuje zrobić kilka obszarów na tym ekranie przyciemnionych a kilka jasnych. Ekran gry przedstawia kolejne pietra budynku, na każdym z pieter może być włączone kilka źródeł światła (obiekty: lampa_obj) i właśnie tylko te miejsca powinny być oświetlone (mieć background_alpha[0] = 1) a pozostałe miejsca przyciemnione (background_alpha[0] = 0.4). Załóżmy że lampy świecą w okręgu o promieniu 100px, najlepiej jeszcze gdyby działało to tak, że im bliżej lampy tym jaśniej czyli taki płynny efekt przejścia do cienia. Dodatkowo światło powinno zatrzymywać się na stropach i ścianach (np. na konkretnym obiekcie sciana_obj). Próbowałem coś zrozumień z przykładu "latarka" pobranego z gmclan ale nie bardzo mi się udaje użyć surfejsów i polecenia draw_set_blend_mode_ext( bm_add, bm_subtract ); (oraz innych) i pojawiają mi się dziwne efekty jakbym miał uszkodzoną kartę grafiki albo w najlepszym przypadku czarny ekran. Mógłby mi to ktoś dokładniej wytłumaczyć.

Spróbuj tak GML if (keyboard_check(vk_right)) and (keyboard_check(vk_up)) { x += 4; y -= 4; }

Bardziej uniwersalnie użyć: GML draw_sprite_part(pasek_spr,0,0,0,(energia_chwilowa/energia_max)*100,20,x,y); gdzie sprajt narysowany jako kolorowy pasek energii nie zostaje ściskany a obcinany (wiem że w tym przypadku to bez znaczenia jest bo pasek jest jednokolorowy). W powyższym "przykładzie" zakładam że sprajt ma 100px szerokości i 20 wysokości. EDIT: Kurcze sorki dopiero teraz zauważyłem, że to wątek z przed pół roku.

No to inaczej. Czy takie sprawdzanie nie będzie wolniejsze niż sytuacja jaką mam teraz czyli: - jeden obiekt "hero" - dużo obiektów "przeciwnik" (na razie 10 ale docelowo pewnie 100 albo więcej) Obecnie sprawdzam w każdym obiekcie "przeciwnik" odległość od "hero": if (point_distance(x,y,hero_obj.x,hero_obj.y) < gonic) and (abs(y-hero_obj.y) < 30) then { przeciwnik_atakuje_hero(); } gdzie: gonic - to odległość na jaką reaguje przeciwnik (abs(y-hero_obj.y) < 30) - zakres pionowy czyli interesuje mnie tylko pasek ekranu o wysokości +/- 30px przeciwnik_atakuje_hero() - skrypt który powoduje atak na hero (przyspieszenie przeciwnika w kierunku hero) Czyli za każdym razem w stepie każdego przeciwnika wykonuje się zbędny kod a ja chciałem uzyskać by podobny kod był wykonywany tylko w step jednego obiektu hero bo i tak atakować powinien tylko najbliższy przeciwnik ale nie w okręgu tylko w pasie ekranu o wysokości +/- 30px (a szerokości maksymalnej rooma). Jedyny problem to znalezienie tego najbliższego przeciwnika w danym zakresie (bo często będzie sytuacja gdzie będą przeciwnicy dużo bliżej ale na wyższym/niższym piętrze niż znajduje się hero i oni nie mogą atakować przez sufit/podłogę).